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

Claude Codeのサンドボックスには、確認プロンプトを省くかどうかを切り替えるautoAllowBashIfSandboxedという設定があります。既定値はtrueで、サンドボックス化できたBashコマンドは権限確認なしに実行されます。ただしこの自動承認には4つの例外があり、trueのままでもdenyルールと一部のaskルールは効き続けます。falseへの戻し方と、優先順位の全体像をここで確認します。自動承認がシェル展開で機能しなくなった過去の不具合はこちらにまとめています。

autoAllowBashIfSandboxedがスキップする確認

sandbox.enabledでサンドボックスを有効にすると、Bashコマンドはファイルシステムとネットワークをサンドボックス内に閉じ込めた状態で実行されます。autoAllowBashIfSandboxedは、この状態のコマンドに対する権限確認を省略する設定です。サンドボックス化できないコマンド、たとえば許可されていないホストへの接続が必要なコマンドは対象外で、通常の権限フローに戻ります。Manualモードならここで確認プロンプトが立ちます。

設定はこの形です。

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

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

この自動承認は権限モードの種類とは独立して働きます。唯一の例外がplanモードで、それ以外のモードでは、sedでファイルを書き換えるBashコマンドのような操作も対象になります。Editツールによる同じ書き換えならManualモードで確認が必要ですが、サンドボックス化されたBashコマンド経由なら確認なしで実行されます。

スキップされない4つの条件

trueのままでも、次の4つは確認をスキップしません。

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

最後の項目には版による違いがあります。裸のBashaskルール、あるいは同義のBash(*)は、サンドボックス化されたコマンドに対してだけスキップされ、通常フローに落ちたコマンドには引き続き適用されます。planモードでは、v2.1.212からこのスキップ自体が働かなくなりました。それより前のバージョンでは、planモード中のサンドボックス化コマンドも確認なしで実行されていました。v2.1.212以降は、読み取り専用のコマンドを含めてplanモード中のサンドボックス化されたBashコマンドにも確認が入ります。denyルールとの優先関係の全体像は/permissionsコマンドの記事でも扱っています。

サンドボックス自体がコマンドを実行できないケース(許可されていないホストへの接続など)は、この4条件とは別の経路です。Claude Codeは違反を検知すると、dangerouslyDisableSandboxパラメータでサンドボックス外への再試行を試みます。この再試行は通常の権限フローを通るため、Manualモードでは確認プロンプトが立ちます。再試行そのものを止めたいときはsandbox.allowUnsandboxedCommandsをfalseにします。/sandboxパネルのOverridesタブは、この状態を「Strict sandbox mode」と表示します。止めるところまではせず、auto modeでも再試行のたびに確認だけは残したい場合は、Bash(dangerouslyDisableSandbox:true)を対象にしたaskルールを追加します。permissions.blockReadsOutsideWorkingDirectoriesを有効にしているセッションでは、この再試行が承認を必要とする性質上、auto modeでもプロンプトが立ちます。

excludedCommandsとdangerouslyDisableSandboxは対象外

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

この境界がずれると事故につながります。v2.1.34より前のバージョンには、除外コマンドやdangerouslyDisableSandbox配下のコマンドがautoAllowBashIfSandboxedの自動許可ロジックに紛れ込むバグがありました。本来なら確認が必要なコマンドが、サンドボックス化されたコマンドと誤認されて確認なしに実行されていたのです。修正内容はClaude Code v2.1.34のリリースノートにまとめています。

falseへの戻し方とCLAUDE_CODE_SUBPROCESS_ENV_SCRUBの関係

autoAllowBashIfSandboxedをfalseにすると、サンドボックス化されたコマンドも含めてすべてのBashコマンドが通常の権限フローを通ります。/sandboxのModeタブは、この状態を「regular permissions mode」と呼びます。

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

設定ファイルを書き換えずに、セッション内から/sandboxパネルを開いて切り替えることもできます。

/sandbox

Modeタブでauto-allowとregular permissionsを選べます。分類器なしでプロンプトを減らしたいだけなら、Manualモードのままサンドボックスをauto-allowにする組み合わせで十分です。denyルールと、Bash(git push *)のような内容指定のaskルールはこの組み合わせでも効き続けます。

真偽値のキーは、配列キーのようにスコープをまたいでマージされません。読み込まれた設定の中で最も優先度の高いスコープの値が単独で採用されます。managed設定でautoAllowBashIfSandboxedを指定すれば、プロジェクト設定やユーザー設定で別の値を書いても上書きされません。組織としてサンドボックス化コマンドにも確認を残したい場合は、managed設定側でfalseを固定します。

これはexcludedCommandsのような配列キーとは扱いが違います。配列は読み込んだ全スコープの値を1つに統合するため、開発者はmanaged設定の一覧に自分のエントリを追加できます。真偽値はそうではなく、最も優先度の高いスコープの1つだけが有効になります。

設定を書き換えずに自動承認を止める方法もあります。CLAUDE_CODE_SUBPROCESS_ENV_SCRUB環境変数を設定すると、autoAllowBashIfSandboxedがtrueでも自動承認が働かなくなります。この環境変数は、Bashツール・フック・MCPのstdioサーバーが受け取るサブプロセス環境から認証情報を取り除く機能です。Linuxではさらに、psやkillがホスト側のプロセスを見られない専用のPID名前空間でBashを実行します。厳格な分離を必要とするワークロードでは、autoAllowBashIfSandboxedを個別にfalseへ変更する代わりに、この環境変数1つで自動承認とプロセス隔離をまとめて締められます。

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

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

autoAllowBashIfSandboxedは、サンドボックスの境界がコマンドを閉じ込めていることを根拠に確認を省略します。一方でauto modeは、分類器がコマンドの内容を審査してから承認するかどうかを判断します。境界に頼るか、判断に頼るかという前提が違うため、片方だけを有効にすることも、両方を組み合わせることもできます。denyルールはどちらの仕組みよりも先に評価されるため、auto modeの分類器が安全と判定してもdenyルールがあれば拒否されます。auto modeの分類器が判定不能になったときの挙動はauto mode安全性判断エラーにまとめています。

使い分け早見表

ファイルシステム分離を切った状態でautoAllowBashIfSandboxedをtrueのままにする組み合わせは避けたい構成です。サンドボックス化されたコマンドがシェルの起動ファイルや~/.claude/settings.jsonを書き換えられるようになり、確認なしで実行され続けます。分離を切る設定の詳しい範囲はsandbox.filesystem.disabledの記事にまとめています。

よくある質問

サンドボックスが無効なときautoAllowBashIfSandboxedは何をしますか

何もしません。この設定はコマンドがサンドボックス化されている場合にだけ働きます。sandbox.enabledを有効にしていないセッションでは、Bashコマンドはそもそもサンドボックス化されないため効果がありません。

auto modeを使っていてもautoAllowBashIfSandboxedをtrueにする意味はありますか

あります。auto modeの分類器は個々のアクションの内容を審査するのに対し、autoAllowBashIfSandboxedはOSレベルのサンドボックス境界を根拠に確認を省略します。両方を有効にしておくと、分類器の判定に取りこぼしがあってもサンドボックスの境界が保険として残ります。

falseにするとサンドボックスによるファイル・ネットワーク制限も外れますか

外れません。autoAllowBashIfSandboxedが切り替えるのは確認フローだけで、ファイルシステムとネットワークの制限は別の層が担います。falseにしても、コマンドは引き続きサンドボックスの境界内で実行され、確認の手間が増えるだけです。

まとめ

autoAllowBashIfSandboxedは既定でtrueですが、確認を省くのはサンドボックス化できたコマンドに限られ、denyルール・rm/rmdirの重要パス・範囲付きaskルール・planモード中の裸のBashaskルールという4つの条件はスキップの対象外です。falseに戻すかCLAUDE_CODE_SUBPROCESS_ENV_SCRUBを使うかは、確認を残したい範囲がサンドボックス設定だけなのか、認証情報の取り扱いまで含むのかで選び分けます。