autoAllowBashIfSandboxedでBash確認をスキップする条件と無効化

Claude Codeのサンドボックスには、確認プロンプトを省くかどうかを切り替えるautoAllowBashIfSandboxedという設定があります。既定値はtrueで、サンドボックス化できたBashコマンドは権限確認なしに実行されます。ただしtrueのままでもdenyルールと一部のaskルールは効き続け、planモードや分類器が絡む場面では承認の仕方が変わります。自動承認がシェル展開で機能しなくなった過去の不具合はこちらにまとめています。

autoAllowBashIfSandboxedがスキップする確認

sandbox.enabledでサンドボックスを有効にすると、Bashコマンドはファイルシステムとネットワークをサンドボックス内に閉じ込めた状態で実行されます。autoAllowBashIfSandboxedは、この状態のコマンドに対する権限確認を省略する設定です。

サンドボックス化できないコマンドは対象外で、通常の権限フローに戻ります。許可していないホストへ接続するコマンドは、サンドボックス内にとどまったまま接続が止められます。

設定はこの形です。

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true
  }
}

スコープはAny fileで、ユーザー設定・プロジェクト設定・ローカル設定・managed設定のどこからでも指定できます。省略時の既定値はtrueなので、サンドボックスさえ有効にすれば確認は最初から省かれます。

この自動承認は、権限モードの設定とは基本的に独立して働きます。Editツールによる書き換えならManualモードで確認が必要ですが、サンドボックス化されたsedでファイルを書き換えるBashコマンドなら、確認なしで実行されます。独立しない例外は次の3つです。

• planモード
• auto modeで、コマンドごとの許可ドメイン(per-command allowed domains)を伴うコマンド
• auto modeで、サーバー側の分類器レビューを受けるサンドボックス化コマンド

つまり、ファイル編集だけは確認が要るはずのManualモードでも、Bashを経由すれば編集が通ります。確認を省くことは、境界の内側なら何をしてもよいという取り決めになります。

確認が出たときの切り分け方

trueのままで確認が出る、あるいは出てほしいのに出ない場合は、上から順に当てはめると原因が絞れます。

rm・rmdirの重要パスと裸のBashルール

rm/rmdirの重要パスは具体的に決まっています。ファイルシステムのルート、/usrや/etcのようなルート直下のディレクトリ、ホームディレクトリ、Windowsのドライブルートとその直下、作業ディレクトリとその親が対象です。--add-dirで追加したディレクトリとその親は、配下へのワイルドカード削除(rm -rf <dir>/*)のときだけ対象です。rm -rf <dir>のようにディレクトリそのものを指定する形は、この扱いになりません。

この重要パスの判定は、allowルールやPreToolUseフックの"allow"でも覆せない設計です。rm -rf "$DIR"/*のように、変数が空だとルートからの削除になる形も重要パスとして扱われます。

裸のBashaskルール、あるいは同義のBash(*)は、サンドボックス化されたコマンドに対してだけスキップされます。通常フローに落ちたコマンドには引き続き適用されます。planモードではこのスキップが働かず、読み取り専用のコマンドを含めて確認が入ります。

planモードの扱いは版で変わりました。v2.1.212では「planモードがファイルを書き換えるBashコマンド(touchやrmなど)を確認なしで自動実行していた」不具合が修正されています。denyルールとの優先関係の全体像は/permissionsコマンドの記事でも扱っています。

サンドボックスが実行を拒んだときの再試行

サンドボックス自体がコマンドを実行できないケース(許可されていないホストへの接続など)は、上の切り分けとは別の経路です。Claude Codeは拒否されたホストを結果に残し、dangerouslyDisableSandboxパラメータでサンドボックス外への再試行を試みることがあります。

この再試行を誰が承認するかは、権限モードで変わります。

注意したいのは、allowルールが再試行も承認してしまう点です。Bash(curl *)のようなallowルールがコマンドに合致していれば、再試行も確認なしでサンドボックス外で動きます。再試行のたびに確認を残したいときは、Bash(dangerouslyDisableSandbox:true)を対象にしたaskルールを足します。このaskルールはauto modeやbypassPermissionsでもプロンプトを出し、合致するallowルールより優先されます。

再試行そのものを止めるなら、sandbox.allowUnsandboxedCommandsをfalseにします。/sandboxパネルのOverridesタブはこの状態を「Strict sandbox mode」と表示します。permissions.blockReadsOutsideWorkingDirectoriesを有効にしたセッションでは、承認が要る再試行はauto modeでもプロンプトが立ちます。v2.1.257以降の挙動です。

excludedCommandsとdangerouslyDisableSandboxは対象外

sandbox.excludedCommandsに登録したコマンドは、そもそもサンドボックスの外で実行されます。autoAllowBashIfSandboxedはサンドボックス化されたコマンドだけを対象にする設定なので、除外コマンドは常に通常の権限フローを通ります。dangerouslyDisableSandboxで再試行されたコマンドも同じ扱いです。

この境界がずれると事故につながります。v2.1.34より前のバージョンには、除外コマンドやdangerouslyDisableSandbox配下のコマンドが、Bashのaskルールを回避できてしまうバグがありました。autoAllowBashIfSandboxedが有効なとき、askルールがあっても、確認なしで通ってしまう状態でした。修正内容はClaude Code v2.1.34のリリースノートにまとめています。

falseへの戻し方と、設定が上書きされる条件

autoAllowBashIfSandboxedをfalseにすると、サンドボックス化されたコマンドも含めてすべてのBashコマンドが通常の権限フローを通ります。allowルールと権限モードで承認が決まる状態で、/sandboxのModeタブは「regular permissions mode」と呼びます。ファイルとネットワークの制限は、falseでも変わりません。

ファイルに書く場合はこの形です。

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": false
  }
}

設定ファイルを書き換えたくないときは、--settingsにJSON文字列を渡して、そのセッションだけ値を変える手もあります。v2.1.287のclaude --helpでは、--settingsは「設定JSONのファイルパスまたはJSON文字列」を受け取ると表示されます。

claude --settings '{"sandbox": {"enabled": true, "autoAllowBashIfSandboxed": false}}'

セッション内から切り替えるなら、/sandboxパネルのModeタブでauto-allowとregular permissionsを選びます。分類器なしでプロンプトを減らしたいだけなら、Manualモードのままサンドボックスをauto-allowにする組み合わせで足ります。

上位の設定が値を固定するとき

真偽値のキーは、配列キーのようにスコープをまたいでマージされません。優先度の高いスコープの値が単独で採用されます。managed設定でautoAllowBashIfSandboxedを指定すれば、プロジェクト設定やユーザー設定で別の値を書いても上書きされません。

allowUnsandboxedCommandsをmanaged設定か--settingsでfalseにすると、サンドボックスが「admin-required」になります。ただし、リポジトリ側の設定ファイルにあるdenyエントリとautoAllowBashIfSandboxedの値は、admin-requiredでも引き続き効きます。リポジトリに値を変えさせたくないなら、managed設定でautoAllowBashIfSandboxed自体を指定します。組織としてサンドボックス化コマンドにも確認を残したいなら、managed設定側でfalseを固定します。

/sandboxパネルが開かず、Error: Sandbox settings are overridden by a higher-priority configuration and cannot be changed locally.と出ることがあります。

原因は、上位の設定レベルがsandbox.enabled・sandbox.autoAllowBashIfSandboxed・sandbox.allowUnsandboxedCommandsのどれかを決めていることです。パネルの変更は.claude/settings.local.jsonに保存されるため、上位の値は上書きできません。どの設定を読み込んでいるかは/statusのSetting sources行で確認できます。

CLAUDE_CODE_SUBPROCESS_ENV_SCRUBを設定した場合

設定を書き換えずに自動承認を止める方法もあります。CLAUDE_CODE_SUBPROCESS_ENV_SCRUBを1にすると、autoAllowBashIfSandboxedがtrueでも自動承認が働かなくなります。

この環境変数は、Bashツール・フック・MCPのstdioサーバーが受け取るサブプロセス環境から認証情報を取り除きます。Linuxではさらに、psやkillがホスト側のプロセスを見られない専用のPID名前空間でBashを実行します。厳格な分離が要るワークロードでは、この1つで自動承認と認証情報の分離をまとめて締められます。

サンドボックスのauto-allowとauto modeは別物

名前が紛らわしいため、混同されやすい設定がもう一つあります。Bashコマンドの確認を自動化する仕組みには、autoAllowBashIfSandboxedのほかにClaude Codeのauto modeがあります。

autoAllowBashIfSandboxedは、サンドボックスの境界がコマンドを閉じ込めていることを根拠に確認を省略します。auto modeは、分類器がコマンドの内容を審査して承認を判断します。境界に頼るか、判断に頼るかという前提が違います。

両方を有効にもできますが、重なる部分は単純な足し算になりません。サーバー側の分類器レビューが有効なセッションでは、サンドボックス化されたシェルコマンドもそのレビューを待ち、フラグが立てばブロックされます。ホストを名指ししたコマンドは、allowルールやauto-allowではなく分類器に回ります。

denyルールはどちらの仕組みよりも強く、安全と判定されても拒否されます。分類器が判定不能になったときの挙動はauto mode安全性判断エラーにまとめています。

使い分け早見表

ファイルシステム分離を切った状態でautoAllowBashIfSandboxedをtrueのままにする組み合わせは、避けたい構成です。分離を切っても既定値のtrueは変わらず、確認が省かれ続けます。すると、サンドボックス化されたコマンドが、シェルの起動ファイルや$PATH上の実行ファイル、~/.claude/settings.jsonのような後続のコマンドが読むファイルを書き換えられます。書き換えたファイルを使って、次の実行で自分のアクセスを広げられるわけです。確認を残したいなら、falseにします。分離を切る設定の詳しい範囲はsandbox.filesystem.disabledの記事にまとめています。

まとめ

autoAllowBashIfSandboxedは、サンドボックスの境界を根拠に確認を省く設定です。確認を残す範囲は、falseにするか、allowUnsandboxedCommandsで再試行を止めるかで決まります。個人環境ならプロンプトの削減、組織運用ならmanaged設定での固定という使い分けが基本です。