Claude CodeでSandbox is requiredと拒否される原因と直し方

Sandbox is requiredは「起動後にサンドボックスが壊れた」合図

Sandbox is requiredは、Claude Codeでsandbox.failIfUnavailableを使っているセッションが、起動後にサンドボックスを使えなくなったときに、Claudeが実行したコマンドへ返すメッセージです。セッション自体は止まりません。拒否されるのはコマンドだけで、隔離なしでの代替実行もされません。

つまり「設定は効いている。ただ、今のセッションでは隔離が成立しないので実行を断っている」という状態です。サンドボックスが原因で動かないだけなので、直す対象はfailIfUnavailableではなく、サンドボックスが使えなくなった理由の側にあります。

failIfUnavailableそのものの役割(起動時に止める設定)は、sandbox.failIfUnavailableの解説にあります。この記事は、起動を通り抜けたあとに出る拒否に絞ります。

拒否メッセージは2種類ある

公式のトラブルシューティングが挙げるメッセージは2つです。どちらも<reason>の部分に具体的な理由が入ります。

2つ目の文言には(sandbox.failIfUnavailable)と設定名が入っています。ここから、どの設定が拒否を引き起こしているかをメッセージだけで特定できます。「stopped being available」はLinuxとWSL2向けの説明です。

failed to initializeは「設定か初期化」の問題

1つ目は、起動時の検査は通ったのに、実際の初期化で失敗した場合です。公式は直し方を2通り示しています。

• Restart to retry.と出たら、Claude Codeを再起動する
• Fix the sandbox settings to retryと出たら、サンドボックスの設定を直してから再試行する

<reason>の中身は状況ごとに変わるため、実際に出た文字列をそのまま読むのが確実です。設定の誤りなら、sandboxブロックの書き方、bwrapPathやsocatPathで指定したパスなどが見直しの入口になります。

stopped being availableは「依存の消失」の問題

2つ目は、Linux・WSL2の依存が実行中に見つからなくなったケースです。Linux・WSL2のサンドボックスはbubblewrapとsocatを使います。Ubuntu/Debianなら次のコマンドで入れ直せます。

sudo apt-get install bubblewrap socat

<reason>が欠けている依存を名指ししているはずなので、それを入れ、Claude Codeを再起動します。再起動の前に/sandboxを実行すると、サンドボックスが有効かどうかと、依存が入っているかを確認できます。インストール全般はUbuntuのインストール解説にもまとまっています。

拒否されるものと、拒否されないもの

拒否の対象は「Claudeが実行するサンドボックス下のコマンド」です。次の2つは拒否されずに動き、3つ目は通常なら通る抜け道が閉じています。

3つ目の抜け道が閉じている点は見落としやすいところです。通常のサンドボックス運用では、コマンドが隔離下で失敗するとClaudeがdangerouslyDisableSandboxで隔離なしの再実行を求め、権限モードによっては承認すると通ります。Sandbox is requiredの状態ではその抜け道が閉じています。Claudeに「隔離を外して」と頼み直しても通らないので、原因を直すほうが早く片づきます。抜け道の仕組みはallowUnsandboxedCommandsの解説にあります。

excludedCommandsに一致するコマンドは拒否されずに通る

隔離できない状況でもexcludedCommandsのコマンドが通るのは、設計上の挙動です。公式は、管理者必須のサンドボックス(admin-required)では、リポジトリ側の設定にあるexcludedCommandsの項目を無視するとも書いています。リポジトリを開いただけで外部コマンドが除外される状況は、管理者が必須にしている環境では起きません。

パターンの書き方には癖があります。ワイルドカードを含まないdockerは引数なしのdockerだけに一致し、docker *と書くと引数付きにも一致します。npm ci && docker compose buildのようにコマンドを連ねた呼び出しは、すべてのコマンドが一致しない限り隔離下のままです。したがって、サンドボックスが壊れたセッションでは、この連ねた呼び出しはexcludedCommandsにdocker *があっても拒否されます。詳しくはsandbox.excludedCommandsの解説にあります。

!プロンプトはバックグラウンドセッションでは別扱い

!で打ったコマンドが動くのは通常のセッションです。バックグラウンドセッションでは、シェルモードのコマンドも拒否されます。バックグラウンドセッションで!が通らないときは、バグではなくこの仕様です。

CLAUDE_CODE_SUBPROCESS_ENV_SCRUBがあるとLinuxでは例外が消える

CLAUDE_CODE_SUBPROCESS_ENV_SCRUBを設定したLinuxのセッションでは、すべてのコマンドが隔離下で動きます。このため、上の例外がなくなります。

• excludedCommandsに一致するコマンドも拒否される
• !で自分が打つコマンドも拒否される

この環境変数は、Bashコマンドやフック、stdioのMCPサーバーといったサブプロセスの環境から認証情報を取り除くためのものです(値は1)。claude-code-actionがallowed_non_write_usersを設定したときに自動で設定する、とも説明されています。「手で打てば動くはず」と考えて詰まるのは、この組み合わせのときです。

起動時の終了とどう違うか

failIfUnavailableがtrueのとき、起動の段階でサンドボックスを使えなければClaude Codeは終了します。設定リファレンスはその続きも書いています。起動時の検査を通ったあとに初期化が失敗した場合は、セッションが続き、Claude Codeがサンドボックス下のコマンドを1つずつ拒否します。

「起動はしたのに何も実行できない」と見えるのは、2行目と3行目です。終了もしないので、サンドボックスの問題だと気づきにくい点に注意してください。コマンドの拒否文にsandbox.failIfUnavailableの名前が入っていれば、この設定が原因だと分かります。

直し方の順番

急ぎで1コマンドだけ通したいときは、!で自分が打つか、信頼できるコマンドをexcludedCommandsに載せる方法があります。ただし、どちらも隔離の外で動かす操作になります。組織がサンドボックスを必須にしている環境では、failIfUnavailableの趣旨に反する回避になるので、管理者に確認してからにします。

組織で配るときに押さえること

managed設定でenabled・failIfUnavailable・allowUnsandboxedCommands: falseを組で配っている組織では、この拒否は「ゲートが働いた結果」として出ます。開発者が自分の設定でfailIfUnavailableをfalseにして回避することはできません。managed設定で指定されたBooleanキーは、開発者のローカルの値を上書きするためです。配り方はmanaged settingsの組織管理ガイドを参照してください。

問い合わせを減らす観点では、サポート窓口の案内に次の2点を載せておくと切り分けが速くなります。

• 拒否文のどちらの形式か(failed to initializeかstopped being availableか)
• Linuxの場合、CLAUDE_CODE_SUBPROCESS_ENV_SCRUBを設定しているか

まとめ

Sandbox is requiredは、failIfUnavailableを有効にしたまま起動後にサンドボックスが使えなくなったときの、コマンド単位の拒否です。セッションは落ちないため、メッセージの文言で初期化失敗か依存の消失かを見分け、後者ならLinux・WSL2のbubblewrapとsocatを確かめてから再起動します。dangerouslyDisableSandboxで押し切れない点と、ENV_SCRUBのあるLinuxではexcludedCommandsと!も止まる点が、この拒否に特有の挙動です。