Claude Media
Claude Codeのrm安全プロンプトを環境変数で無効化する方法
Claude CodeTips

Claude Codeのrm安全プロンプトを環境変数で無効化する方法

critical-path削除・PowerShellのcmd削除・コマンド置換由来のrmという3つの安全プロンプトを、環境変数で局面別に無効化する方法を紹介します。

読了目安 約9分

Claude Codeのrm安全プロンプトとは

Claude Codeは、ファイルシステムのルートやホームディレクトリなど「critical path(重要パス)」を対象にしたrm・rmdirは、許可ルールやPreToolUseフックの"allow"があっても自動承認しません。モデルの誤りに備えるサーキットブレーカーとして、常に確認を挟む設計です。

この確認は3つの別々の局面で発生します。

  1. critical-path削除そのものへの時間制限付き確認(auto / bypassPermissionsモード)
  2. PowerShellのcmdビルトイン(rd / rmdir / del / erase)がシステムパスを対象にしたときの拒否
  3. コマンド置換の出力だけがrmの対象になっているとき(rm -rf "$(pwd)"など)の確認

それぞれに対応する環境変数が用意されており、局面ごとに個別へ無効化できます。ただし挙動は「確認を省略する」のではなく「別の扱いに切り替える」または「その1チェックだけ止める」であり、3つとも設定できる場所に共通の制約があります。

critical pathとして扱われる対象

Claude Codeはrm・rmdirの削除対象が次のいずれかに当てはまるとき、critical-path削除として扱います。

  • ファイルシステムのルート
  • ルート直下のトップレベルディレクトリ(/usr、/etc、/dataなど)
  • ホームディレクトリ
  • Windowsのドライブルートとその直下(C:\、C:\Windowsなど)
  • 作業ディレクトリとその親ディレクトリ
  • 追加の作業ディレクトリの親ディレクトリ(そのディレクトリ自体へのrm -rf <dir>は対象外で、<dir>/*のようにグロブで直下を狙う場合のみ)

さらに、シェル変数の直下にグロブや末尾スラッシュが付く形(rm -rf "$DIR"/*など)も、変数が空になったときにルート削除へ化けるためcritical-path扱いです。変数がガードされていない限り、$TMPDIR/mntのようにトップレベル名が続く形や、同じコマンド内で$(pwd)やgit rev-parse --show-toplevelから代入された変数を対象にする形も同様に検出されます。サブシェルやコマンド置換の中に隠しても、この判定は素通りしません。

この一覧を押さえておくと、3つの環境変数が「何を無効化していないか」の輪郭がはっきりします。次の各節で見るとおり、いずれの変数も、この判定ロジック自体を止めるものではありません。

モードごとのcritical-path削除への既定の反応

3つの環境変数がどこに効くかは、パーミッションモードごとの既定の反応を先に押さえておくと見通しやすくなります。

モードcritical-path削除への既定の反応
default / acceptEditscritical-path削除への既定の反応時間制限なしで確認を求める
plancritical-path削除への既定の反応確認を求める(auto modeのクラシファイアがplan中のコマンドを審査する設定で、bypassPermissionsが使えない場合はautoモードと同じ扱いになる)
autocritical-path削除への既定の反応ターミナルでは時間制限付きで確認、それ以外の場所では拒否
dontAskcritical-path削除への既定の反応拒否
bypassPermissionscritical-path削除への既定の反応ターミナルでは時間制限付きで確認

2分のカウントダウンが付くのはautoとbypassPermissionsの2モードだけです。CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUTがこの2モードにしか関係しないのは、そもそも時間制限があるのがこの2モードだけだからです。

3つの環境変数と対象の違い

環境変数無効化する対象必要バージョン
CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT無効化する対象critical-path削除の確認プロンプトにある2分のカウントダウン必要バージョンv2.1.281以降
CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT無効化する対象再帰的なrmの対象がコマンド置換の出力だけになっているときの確認必要バージョンv2.1.281以降
CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY無効化する対象PowerShellツール経由のcmdビルトイン(rd / rmdir / del / erase)がシステムパスを対象にしたときの拒否必要バージョンv2.1.283以降

CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT — critical-path削除の時間制限を外す

autoモードとbypassPermissionsモードでは、critical-path削除の確認プロンプトに2分のカウントダウンが付きます。時間内に応答しないとClaude Codeはコマンドを拒否し、削除を諦めて別の対応に切り替えます。

2分のカウントダウン中にキーを押すと、カウントダウンだけが止まり確認プロンプトはあなたの回答を待ち続けます。応答せずに3回タイムアウトが重なると、Claude Codeはそのセッションで以降の確認プロンプト自体を出さなくなり、critical-path削除は即座に拒否されるようになります。この状態は新しいメッセージを送ると解除され、カウントはまたゼロから始まります。

CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1を設定すると、この時間制限だけが外れます。無効化後の挙動はモードによって分かれます。

  • autoモード: critical-path削除がプロンプトの代わりにクラシファイア(分類器)へ送られる
  • bypassPermissionsモード: 確認プロンプト自体は残るが、時間制限なしであなたの回答を待つ

つまりこの変数は「確認を消す」設定ではなく、「時間切れで自動拒否される代わりにクラシファイア判定か、無期限の確認待ちに回す」設定です。defaultモードとacceptEditsモードにはもともと時間制限が無いため、この変数は影響しません。

CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT — コマンド置換由来のrm対象への確認を外す

rm -rf "$(pwd)"のように、削除対象がまるごとコマンド置換の出力になっている再帰的なrmは、Claude Codeが実行前に対象パスを検証できません。そのため実行前に確認を求め、Claudeへは「まず置換を単独で実行し、出力された具体的なパスを使って削除し直す」よう指示します。

CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1はこの1チェックだけを止めます。他のcritical-pathチェック(ルートディレクトリ、ホームディレクトリ、作業ディレクトリの親など)は無効化後も引き続き動作します。

CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY — PowerShell経由cmdの拒否を外す

PowerShellツールを有効にしている環境では、Claude Codeはcmdビルトインのrd / rmdir / del / eraseがシステムパス(ファイルシステムのルート、ドライブルートとその直下、ホームディレクトリなど)を対象にしたとき、モードを問わず確認なしで拒否します。cmd /c rd /s /q C:\Usersのような呼び出しが対象です。

CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY=1はこの拒否を止めます。ただしRemove-Itemによるシステムパスへの削除は、この変数を設定しても引き続き拒否されます。無効化されるのはcmd経由のrd / rmdir / del / eraseだけです。

PowerShellツール経由の削除は、対象の種類によって扱いが3段階に分かれます。ワイルドカード(裸の*、/*や\*で終わる対象)へのRemove-Itemは、モードを問わずクラシファイアより前段で拒否され、この環境変数でも変わりません。作業ディレクトリやその親を-Recurse付きで対象にするRemove-Itemは、通常の承認が必要なコマンドと同じ扱いになり、モードに応じて確認・クラシファイア送り・拒否のいずれかになります。ただしbypassPermissionsモードでは、このチェック自体が働きません。システムパスへのRemove-Itemだけが、モードを問わず常に拒否される最も厳しい扱いです。cmdビルトインの拒否はこの3段階のうち「システムパス」に相当する部分だけを対象にしており、CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENYが緩めるのもそこに限られます。

3つに共通する落とし穴 — settingsのenvブロックからは効かない

3つの変数はいずれも、claudeを起動するシェルなど「起動環境」で設定する必要があります。settingsファイルのenvブロックに書いても、Claude Codeはそのコピーを無視します。

# 効く: 起動前にシェルでexport
export CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1
claude

効かない例(settings.jsonのenvブロック):

{
  "env": {
    "CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT": "1"
  }
}

CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENYも公式ドキュメントで同じ制約が明記されています。設定したつもりで効かないときは、まずsettingsファイルではなくシェルのexportやCI環境変数として渡しているかを確認してください。

CI・コンテナのように毎回新しいプロセスからclaudeを起動する環境なら、起動スクリプトやDockerfileのENV、CIのjob設定でこれらの変数をエクスポートすれば反映されます。settingsファイルのenvブロックに書いた値は、次回以降の起動でも反映されません。

無効化しても残るチェック

3つの環境変数はいずれも1つのチェックだけを無効化し、critical-pathの判定ロジック全体を止めるものではありません。次はいずれの変数を設定しても残ります。

  • 許可ルールやPreToolUseフックの"allow"がcritical-path削除を承認することはない(サーキットブレーカー自体は無効化できません)
  • 明示的な拒否ルールが一致した削除は、どの変数を設定しても拒否されたままです
  • Remove-Itemによるシステムパスへの削除は、CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENYを設定しても拒否が続きます
  • ワイルドカード(*、/*、\*で終わる対象)へのRemove-Itemは、モードを問わずクラシファイアより前段で拒否されます

CI・コンテナなど非対話環境でこれらの変数を検討する場合も、拒否そのものをなくす手段ではない点に注意が必要です。特にautoモードでは、ターミナルで確認プロンプトを出せない実行(非対話モードの-p、Agent SDKセッション、VS Code拡張のチャットパネルなど)ではcritical-path削除は即座に拒否され、Claudeには「削除したかった対象を報告し、削除自体はユーザーに委ねる」よう指示が返ります。

言い換えると、これら3つの環境変数は「事前チェックの通過方法」を変えるものであって、「危険な削除を実行可能にする」ものではありません。悪意ある入力やモデルの誤りに対する最終防波堤(明示的な拒否ルールとサーキットブレーカー)は、どの組み合わせでも動き続けます。

使い分けの目安

状況向き理由
対話的なターミナルで作業ログを見ながら使う向き設定は不要理由時間制限内に人が応答できるため、そもそも詰まりにくい
完全非対話のCI/CDジョブで-p実行する向き慎重に検討理由autoモードでは元々ターミナル確認自体が出せず即座に拒否される。critical-path対象のパスをそもそも作らない設計の方が安全
隔離済みの使い捨てコンテナでバッチ処理を回す向き検討の余地あり理由誤削除の影響範囲がコンテナ内に閉じるなら、時間制限やコマンド置換チェックの緩和が現実的な選択肢になる
本番ホストや共有マシンで直接作業する向き影響が大きい理由critical-pathチェックは人為ミスに対するサーキットブレーカーであり、外すほど誤削除の防波堤が薄くなる

いずれの場合も、無効化するのは3つのうち必要な1つだけに絞り、残り2つのチェックは有効なままにしておく方が、削除の影響範囲を狭く保てます。設定した変数は、用途が終わったら起動環境から外せば、チェックが元の状態に戻ります。

まとめ

CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUTはcritical-path削除の時間制限、CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPTはコマンド置換由来のrm対象への確認、CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENYはPowerShell経由のcmd削除拒否と、それぞれ対象が異なります。3つともsettingsファイルのenvブロックからは効かず、claudeを起動する環境変数として設定する必要がある点が共通の落とし穴です。無効化はいずれも1チェック単位で、critical-pathの判定ロジックそのものを止めるものではありません。運用に組み込む前に、破壊的操作を確認させるプロンプト設計やauto modeの安全確認の強化内容も合わせて確認しておくと、意図しない削除を避けやすくなります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →