Claude Codeのサンドボックス使い方｜/sandboxの設定と許可リスト

Claude Codeのサンドボックスとは、Claudeが実行するシェルコマンドを、OSが強制する境界の内側に閉じ込める機能です。結論から言うと、ビルドやテストのようにコマンドを何度も実行させたい場面で、書き込めるフォルダと接続できるドメインをあらかじめ絞っておけば、毎回の承認を減らしながら影響範囲も限定できます。公式ドキュメントは、この機能を「Configure the sandboxed Bash tool」というページで説明しており、既定ではオフで、/sandboxコマンドかsandbox.enabledの設定で有効にします。

この記事では、公式ページの記述だけを根拠に、何を制限するのか、対応OSと前提、有効化の手順、2つのモードの違い、許可リストの書き方、権限設定（permissions）との違い、使う場面と注意点を順に整理します。内容は2026年10月6日に確認した英語版の公式ページに基づきます。Claude Code自体の入門はClaude Codeの基本的な使い方で先に押さえておくと、設定ファイルの話がつながりやすくなります。

Claude Codeのサンドボックスとは何か｜シェルコマンドを囲むOS側の境界

Claude Codeのサンドボックスとは、Claudeが実行するBash・PowerShell・Monitorのコマンドと、そこから起動するプロセスに対して、触れるファイルと接続できるドメインの範囲をOSの仕組みで制限する機能です。

公式ページは、サンドボックスを、Claudeがあなたのマシン上で実行するシェルコマンドの周りにOSが強制する境界として説明しています。制限はBash、PowerShell、Monitorのコマンドと、それらが起動するプロセスに及びます。OSが実行中に制限を適用するため、Claude Codeは承認を毎回求めずにサンドボックス内のコマンドを実行できる、とも書かれています（公式: Configure the sandboxed Bash tool）。

ここで押さえておきたい点が2つあります。1つ目は、対象がシェルコマンドだけだという点です。公式ページは「The sandbox covers shell commands only」と明記し、Claudeのファイルツール、MCPサーバー、フックはサンドボックスの外で動くとしています。2つ目は、既定ではオフだという点です。公式ページには「The sandbox is off by default」とあり、設定ファイルのsandboxキーも既定は未設定で、その場合Claude Codeはサンドボックスなしでコマンドを実行すると設定リファレンスに書かれています。

サンドボックスの土台は、オープンソースの@anthropic-ai/sandbox-runtimeパッケージです。公式ページによると、Claude Codeはこのパッケージの上にサンドボックスを構築しています。つまり「Claudeがおとなしく振る舞うことを期待する」仕組みではなく、コマンドが実際に何をできるかをOS側で絞る仕組みです。この違いが、後で説明する権限設定との関係を理解する鍵になります。

サンドボックスが制限するもの｜書き込み・読み取り・ネットワーク・環境変数

サンドボックスが既定で許すのは、作業ディレクトリと一時ディレクトリへの書き込み、マシンの大半の読み取り、許可ドメインへのプロキシ経由の通信です。環境変数は既定ではそのまま引き継がれます。

公式ページは、サンドボックス内のコマンドが既定で何に届くかを表にまとめています。次の表はその内容を、変更に使う設定キーとあわせて整理したものです（公式: What the sandbox restricts）。

アクセス	サンドボックス内の既定	変更に使う設定
書き込み	作業ディレクトリ、ユーザーごとの一時ディレクトリ、追加したディレクトリ。保護パスは書き込み禁止のまま	filesystem.allowWrite、filesystem.denyWrite
読み取り	マシンの大半。~/.sshや~/.aws/credentialsなどの認証情報ファイルも含む	filesystem.denyRead、credentials
ネットワーク	直接の経路なし。マシン上のプロキシが許可ドメインと照合し、許可ドメインは空から始まる	network.allowedDomains、network.deniedDomains
環境変数	Claude Codeから引き継ぐ。環境内の秘密情報も含む	credentials、CLAUDE_CODE_SUBPROCESS_ENV_SCRUB

表の読み取りの行に注意してください。公式ページが示す既定の読み取りは「マシンの大半」で、認証情報ファイルも含まれます。公式ページも、この既定では認証情報を読めてしまうので、読ませたくないものは自分で保護するよう案内しています。サンドボックスを有効にしただけで、秘密情報の読み取りまで自動的に止まるわけではありません。

書き込みについては、作業ディレクトリとその配下、--add-dir、/add-dir、permissions.additionalDirectoriesで追加したディレクトリ、そして$TMPDIRが指すユーザーごとの一時ディレクトリが対象です（公式: Filesystem isolation）。それ以外の場所への書き込みは、許可を足さない限り失敗します。

対応OSと前提｜macOS・Linux・WSL2で動き、ネイティブWindowsでは動かない

サンドボックスはmacOS、Linux、WSL2で動作します。ネイティブWindowsではサンドボックスなしでコマンドが実行されるため、Windowsで使うにはWSL2のディストリビューション内でClaude Codeを動かします。

公式ページの記述では、サンドボックスが動くのはmacOS、Linux、WSL2です。ネイティブWindowsではClaude Codeがコマンドをサンドボックスなしで実行するため、Windowsマシンで使う場合はWSL2のディストリビューションの中でClaude Codeを動かす、と案内されています（公式ページの冒頭）。OSごとの仕組みと事前準備は次のとおりです。

環境	使われる仕組み	事前に必要なもの
macOS	組み込みのSeatbeltフレームワーク	追加インストールなしで/sandboxに進める
Linux	bubblewrapによる隔離	bubblewrapとsocatを導入する
WSL2	Linuxと同じくbubblewrap	bubblewrapとsocatを導入する。WSL1は不可
ネイティブWindows	サンドボックスなしで実行	WSL2内でClaude Codeを動かす

LinuxとWSL2では、ファイルシステムの隔離を担うbubblewrapと、ネットワーク通信をサンドボックスのプロキシへ中継するsocatが必要です。公式ページのインストール例は、Ubuntu/Debianならsudo apt-get install bubblewrap socat、Fedoraならsudo dnf install bubblewrap socatです。依存関係の確認は起動時に行われるため、導入後はClaude Codeを再起動してから/sandboxを開き直します（公式: Set up Linux and WSL2）。

公式ページには、Ubuntu 24.04以降でAppArmorの設定が必要になる場合や、WSL1だと「Sandboxing requires WSL2」と表示される場合の説明もあります。自分の環境がこれらに当たるかは、公式ページの該当部分で確認してください。

ここで見落としやすいのが、依存関係が足りないときの挙動です。公式ページの警告によると、依存関係の欠落やプラットフォーム非対応でサンドボックスを起動できない場合、既定ではClaude Codeがサンドボックスなしでコマンドを実行します。起動時に終了させたいなら、sandbox.failIfUnavailableをtrueにします。「有効にしたつもりで実は動いていなかった」を避けるために、後述の動作確認と合わせて覚えておく価値があります。

有効化の手順｜/sandboxパネルでモードを選び、設定ファイルへ保存する

有効化は、セッション内で/sandboxを実行してモードを選ぶ方法と、設定ファイルでsandbox.enabledをtrueにする方法の2通りです。

公式ページが示す手順は次の流れです（公式: Get started）。

1. Claude Codeのセッションを開始し、/sandboxを実行します。サンドボックスのパネルが開きます。
2. パネルのModeタブで、auto-allowかregular permissionsのどちらかを選びます。
3. Claudeにビルドやテストなどのコマンドを実行させます。新しいネットワークドメインが必要になった最初の場面で、承認を求めるプロンプトが出ます。

パネルには、Mode、Overrides、Configの3つのタブがあります。Modeは承認の方式を選ぶタブ、Overridesはサンドボックス内で失敗したコマンドをサンドボックス外で再試行できるかを選ぶタブ、Configは解決済みのサンドボックス設定を表示するタブです。Linuxで任意のseccompフィルターが無い場合はDependenciesタブも加わります。必須の依存関係が無い場合はDependenciesタブだけが表示され、導入と再起動が先に必要になります。

モードをパネルで選ぶと、Claude Codeはその設定をプロジェクトのローカル設定である.claude/settings.local.jsonに保存します（設定リファレンス: sandbox.enabled）。すべてのプロジェクトでサンドボックスを使いたいときは、ユーザー設定の~/.claude/settings.jsonでsandbox.enabledをtrueにします。組織で全開発者に強制したい場合は管理設定を使います。1回のセッションだけ変えたいときは、設定ファイルを書き換えずに--settingsで渡せます。公式ページの例は次のとおりです。

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

この例は、サンドボックスを有効にしたうえで、ブロックされたコマンドをClaudeがサンドボックス外で再試行できないようにするものです。再試行の仕組みは後の節で説明します。

動作確認｜touchとcurlで境界を試す

サンドボックスが本当に効いているかは、Claudeに次の2つのコマンドを実行させて確かめます。公式ページが示す期待結果は次のとおりです（公式: Confirm commands run inside the sandbox）。

実行させるコマンド	サンドボックス内での結果
touch ~/sandbox-probe	macOSではOperation not permitted、LinuxとWSL2ではRead-only file systemで失敗する
curl --noproxy '*' https://example.com	サンドボックスのプロキシを迂回する経路が無いため、Could not resolve hostで失敗する
/sandboxのConfigタブを開く	解決済みのサンドボックス設定が表示される

確認のコツは、自分でターミナルに打たずにClaudeに実行させることです。!のシェルモードで自分が入力したコマンドは、通常サンドボックスの外で動くため、境界の確認になりません。また、Claudeが失敗したコマンドをサンドボックス外で再試行しようとしたら、確認のためには断ります。もしtouchが成功し、ホームディレクトリが書き込み許可の対象でないなら、~/sandbox-probeを削除したうえで/sandboxを開き、サンドボックスが有効か、依存関係が入っているかを確かめます。

2つのモード｜auto-allowとregular permissionsで承認の方式が変わる

サンドボックスのモードは、サンドボックス内のコマンドを自動承認するauto-allowと、通常の権限確認を維持するregular permissionsの2つです。どちらでもファイルとネットワークの制限は同じです。

公式ページは、2つのモードの違いを「承認の方式だけ」と説明しています。auto-allowモードでは、サンドボックス内で動くコマンドをClaude Codeが確認なしで承認します。regular permissionsモードでは、サンドボックス内であってもすべてのBashコマンドが通常の権限フローを通り、制御は増える反面、承認の回数も増えます（公式: Sandbox modes）。設定キーでいえば、sandbox.autoAllowBashIfSandboxedがtrueならauto-allow、falseならregular permissionsで、既定はtrueです（設定リファレンス）。

auto-allowでも、止まる場面は残っています。公式ページが挙げているのは次のとおりです。

• 明示的なdenyルールは常に尊重されます
• 重要なパスを対象にしたrmやrmdirは、通常の権限フローを通ります
• Bash(git push *)のように内容を指定したaskルールは、サンドボックス内のコマンドでもプロンプトを出させます

auto-allowは、権限モードの設定とは独立して働きます。公式ページには、Manualモードのようにファイル編集ツールがプロンプトを出す状況でも、サンドボックスの境界内でファイルを変更するBashコマンドは確認なしで実行される、と書かれています。例外はプランモードなどの一部の場面です。プランモードでauto-allowが承認を広げない点は、公式の権限モードのページで確認できます。

なお、auto-allowはClaude Codeの「auto mode」とは別物です。公式ページは、auto-allowが「サンドボックスの境界に収まっているからBashコマンドを承認する」仕組みなのに対し、auto modeは「分類器がアクションを審査する」仕組みだと区別しています。2つは独立して動き、組み合わせることもできます。

ファイルシステムの設定｜allowWrite・denyWrite・denyRead・allowRead

ファイルシステムの許可は、sandbox.filesystemのallowWrite、denyWrite、denyRead、allowReadで調整します。同じ配列を複数のスコープに書くと、置き換えではなく統合されます。

サンドボックス内のコマンドは、既定では作業ディレクトリなどにしか書き込めません。kubectl、terraform、npmのようなツールが別の場所へ書き込む必要があるときは、sandbox.filesystem.allowWriteで特定のパスだけを許可します。公式ページの例は次のとおりです（公式: Configure sandboxing）。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"]
    }
  }
}

公式ページは、ツールが特定の場所への書き込みを必要とするときは、excludedCommandsでそのツールをサンドボックスから外すより、この方法を勧めています。パスはOSレベルで強制されるため、サンドボックス内のすべてのコマンドとその子プロセスに効きます。

パスの書き方には注意が必要です。サンドボックスのファイルシステム設定は標準的な表記で、/tmp/buildは絶対パス、~/.kubeはホームからの相対パスです。これは、ReadとEditの権限ルールが絶対パスに//path、プロジェクト相対に/pathを使うのとは異なります。権限ルールの感覚で/pathと書くと意図とずれるので、サンドボックス側では標準表記で書きます。

読み取りの制御にはdenyReadとallowReadを使います。allowReadは、denyReadで塞いだ領域の中で特定のパスだけを再び開けるためのものです。ルールが重なったときは、より狭いパスのルールが優先されます。公式ページの整理を表にまとめます。

書き方	結果
denyRead: ["~/"]とallowRead: ["~/projects"]	~/projectsだけが読め、ホームの残りは読めない。狭いallowが拒否領域の一部を開き直す
allowRead: ["~/"]とdenyRead: ["~/.env"]	~/.envは読めないまま、ホームの残りは読める。広いallowが秘密を再公開することはない
allowRead: ["~/"]とdenyRead: ["~/**/.env"]	ホーム配下のすべての.envが読めないまま、残りは読める

ホーム全体の読み取りを止めつつ、今のプロジェクトだけ読ませる例も公式ページにあります。denyReadに["~/"]、allowReadに["."]を指定する設定で、プロジェクトの.claude/settings.jsonに置くと.がプロジェクトルートを指します。同じ内容を~/.claude/settings.jsonに置くと.は~/.claudeを指してしまい、プロジェクトのファイルはdenyReadに塞がれたままになります。どの設定ファイルに書くかで意味が変わる点は、この設定で最も間違えやすいところです。

設定を編集すると、実行中のセッションにもその変更が反映され、次のサンドボックス内コマンドから新しいパスで動きます。複数のスコープに同じ配列を書いた場合は、置き換えではなくパスが統合されます（公式: Settings precedence）。

保護パスと認証情報の守り方

書き込みを許可したディレクトリの中でも、Claude Codeが設定やコードを読み込むファイルへの書き込みは拒否されます。公式ページは、そうしたファイルを書き換えられると、コマンドが自分に権限を与えたり、サンドボックス外で動くフックやMCPサーバーを追加したりできてしまうためだと説明しています。対象には、.claudeの設定ファイル、.claude/skills、.claude/agents、.claude/commands、.claude/hooksの各ディレクトリ、.mcp.jsonが含まれます。作業ディレクトリでは、.bashrcや.zshrcなどのシェル起動ファイル、.gitconfigなども保護されます（公式: Protected paths）。

この保護には例外がありません。allowWriteの項目やEditのallowルールで該当パスを指定しても、保護は外れません。外す方法は、ファイルシステム隔離そのものを止めるfilesystem.disabledだけで、その場合は全パスの隔離が止まります。ファイル隔離だけを止めてネットワーク隔離を残す設定ですが、公式ページは、コマンドが自分の権限を広げないと信頼できる作業にだけ使うよう警告しています。

認証情報にはsandbox.credentialsを使います。公式ページによると、ファイルのパスと環境変数名ごとにmodeを指定し、denyならファイルの読み取りを拒否し、環境変数はコマンド実行前に解除します。公式ページの例は次のとおりです。

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

公式ページは、組み込みの認証情報denyリストは存在しない、と明記しています。保護されるのは、自分が列挙したファイルと変数だけです。またmodeにはmaskもあり、サンドボックス内のコマンドには代替の値を見せ、許可したホストへの送信時にプロキシが本物の値へ差し替えます。ただしmaskにはTLS終端の設定などの前提があるため、使う場合は公式ページの該当節を読んでから設定してください。

作業ディレクトリがgit worktreeのときは、メインリポジトリの共有.gitディレクトリにもサンドボックスが書き込みを許すため、git commitでrefsやインデックスを更新できます。ただし、その中のhooks/とconfigへの書き込みは拒否されたままです。

ネットワークの許可リスト｜プロキシがドメインを照合し、許可は空から始まる

サンドボックス内のコマンドには外への直接の経路がなく、マシン上のプロキシが接続先のホスト名を許可ドメインと照合します。許可ドメインは空から始まるため、必要なものを自分で足します。

公式ページによると、Linux・WSL2ではコマンドが別のネットワーク名前空間で動き、自分のネットワークへの接続を持ちません。macOSでは、Seatbeltが既定でサンドボックスのプロキシ以外への接続をブロックします。Claude Codeはサンドボックスの外でプロキシを動かし、HTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数でコマンドをそこへ誘導します（公式: Network isolation）。

ここから、どのツールが動くかが決まります。プロキシの環境変数を読むツール、たとえばcurl、npm、HTTPS経由のgitは、ホストが許可されれば接続できます。ポート指定のないallowedDomainsの項目は、そのホストの全ポートを許可します。一方、プロキシ変数を無視するツール、たとえばSSHを直接使うものや大半のデータベースドライバは、許可済みのホストにも接続できません。UDP、QUIC上のHTTP/3、pingのようなICMPのツールなど、TCP以外の通信もサンドボックスの外へ出られません。

許可ドメインの設定例は、ファイル隔離を止めてネットワーク隔離だけ使う形で公式ページに載っています。network.allowedDomainsに["github.com", "*.npmjs.org"]のように書きます。拒否したいドメインにはnetwork.deniedDomainsを使い、広いワイルドカードで許可した中の特定ドメインを塞げます。

許可リストにないホストへコマンドが接続しようとしたときは、コマンドはサンドボックス内にとどまり、判断を待ちます。その判断は権限モードによって変わります。公式ページの対応を表にします（公式: Hosts outside your allowed domains）。

権限モード	許可リスト外ホストへの接続
bypassPermissionsモード	プロンプトなしで許可される
Manualモード、acceptEditsモード	プロンプトが出る
autoモード	コマンドがホストを列挙し、分類器が承認した場合を除いて拒否される
dontAskモード	拒否される

プロンプトで「Yes」を選ぶと、そのホストは現在のセッションの間だけ許可されます。「Yes, and don’t ask again」を選ぶと、Claude CodeはWebFetch(domain:...)のallowルールをローカル設定に保存し、以降のセッションでも許可されます。許可を完全に固定したいときはstrictAllowlistを使います。ユーザー設定、管理設定、--settingsのいずれかでtrueにすると、プロンプトを出さず、許可リスト外のホストを拒否します。この設定はv2.1.219以降が必要で、リポジトリの.claude/settings.jsonに書いても効きません。

ネットワーク制限で見落としやすい注意が2つあります。1つ目は、プロキシがホスト名だけで許可を判断し、既定ではTLSの中身を検査しない点です。2つ目は、許可したホスト名が解決の結果ローカルアドレスだけを指す場合、プロキシが接続を拒否する点です。ループバックやクラウドのメタデータ用アドレスなどが該当します。社内のホスト名が10.0.0.0/8のようなプライベート範囲に解決されるだけなら、許可されていれば接続できます。

権限設定（permissions）との違い｜実行前の判断とOSによる強制は別の層

権限設定はツールの使用可否を実行前に判断する仕組みで、サンドボックスはシェルコマンドが実行中に触れる範囲をOSが制限する仕組みです。2つは補い合う別の層として併用します。

公式ページは、権限ルールとサンドボックスを「別のものを制御する」と整理しています。権限ルールは、どのツールをClaude Codeが使えるかを制御し、ツールが動く前に評価されます。BashだけでなくRead、Edit、WebFetch、MCPなどすべてのツールに適用されます。サンドボックスは、シェルコマンドがファイルシステムとネットワークで何に触れるかをOSレベルで制限し、適用されるのはBash、PowerShell、Monitorのコマンドとその子プロセスだけです（公式: Permission rules）。

観点	権限設定（permissions）	サンドボックス
制御するもの	どのツールを使えるか	シェルコマンドが触れるファイルとドメイン
判断のタイミング	コマンドを実行する前	コマンドの実行中
強制の方法	コマンド文字列や分類器の判断に基づく	OSが実行中のプロセスに境界を適用する
対象	Bash、Read、Edit、WebFetch、MCPなど全ツール	Bash、PowerShell、Monitorとその子プロセス

強制の仕方の違いは重要です。公式ページによると、権限の判断はコマンドが動く前に、コマンドの文字列とauto modeでは別の分類器の判断に基づいて行われます。これに対しサンドボックスは、OSが実行中のプロセスに境界を課すため、モデルが何を実行しようと、許可されたコマンドが名前以上のことをしようと、境界は保たれます。

両者の設定は重なる部分もあります。Editのallowルールはsandbox.filesystem.allowWriteと同じく書き込みアクセスを与え、ReadとEditのdenyルールは特定のファイルやディレクトリへのアクセスを塞ぎます。WebFetch(domain:...)のallow・denyルールはドメインを制御し、サンドボックスのallowedDomainsはBashコマンドが届くドメインを制御します。公式ページは、サンドボックス設定と権限ルールの両方のパスとドメインが、最終的なサンドボックス設定に統合されると説明しています。権限ルールの書き方そのものは、権限設定（permissions）の使い方の記事で詳しく扱っています。

混同しやすい点として、/sandboxは権限モードではありません。公式ページは、権限モードはツール呼び出しが実行されるか、事前にプロンプトが出るかを決めるもので、サンドボックスはBashコマンドが実行後に何へアクセスできるかを制限するものだと分けています。プロンプトの代わりになるものも違い、/sandboxのauto-allowではサンドボックスの境界そのものが、auto modeでは分類器が、それぞれ代わりを務めます。

サンドボックスの外で動くもの｜excludedCommandsと再試行の仕組み

サンドボックスの外では、ファイル・Web系ツール、フック、ローカルのMCPサーバー、自分で入力したコマンド、excludedCommandsに一致するコマンド、承認された再試行が動きます。

サンドボックスで守られると思い込みやすい範囲を、先に整理しておきます。公式ページによると、Read、Edit、Write、WebFetch、WebSearchなどの組み込みファイル・Webツールは、サンドボックスではなく権限ルールに従います。そのため、denyReadの項目はReadツールを止めず、allowedDomainsはWebFetchを制限しません。さらに、コマンド型のフック、ローカルのMCPサーバー、プラグインのモニター、LSPサーバー、ステータスラインのコマンドやapiKeyHelperのような補助コマンドは、あなたの完全なアクセス権で動きます（公式: What runs outside the sandbox）。

シェルコマンドの中にも、設定次第でサンドボックス外で動くものがあります。!のシェルモードで自分が入力したコマンドは、ほとんどのセッションでサンドボックスなしで動きます。excludedCommandsに一致するコマンドも外で動きます。そして、サンドボックス内で失敗したコマンドをClaudeが再試行する場合も外で動きます。

excludedCommandsで特定のコマンドを外す

sandbox.excludedCommandsにコマンドのパターンを書くと、一致するコマンドはサンドボックスの外で実行され、ファイルの制限もネットワークプロキシも受けません。公式ページの例は"excludedCommands": ["docker compose *"]です。公式ページはトラブルシューティングでdockerがサンドボックスと非互換だと述べ、必要なコマンドだけをこの方法で外す手順を示しています。

書き方のルールは、Bash(...)の権限ルールと同じ構文です。ワイルドカードのないパターンは完全一致なので、dockerは引数なしのdockerだけに一致し、docker *は引数の有無を問わず一致します。1回の呼び出しに複数のコマンドをつないだ場合は、すべてのコマンドが一致しなければサンドボックスに残ります。たとえばnpm ci && docker compose buildは、npm ciをカバーする別の項目がない限りサンドボックス内のままです。

外したコマンドは、あなたの完全なアクセス権で動くと公式ページは警告しています（公式: excludedCommands）。広い項目を書くと、そのツールにできることすべてが対象になります。必要なのが1つのディレクトリや1つのホストだけなら、allowWriteやallowedDomainsで足りることが多く、その場合はコマンドをサンドボックスに残せます。

サンドボックス外での再試行とStrict sandbox mode

サンドボックスと非互換なツールのために、再試行の逃げ道があります。コマンドがサンドボックス内で失敗すると、Claudeは失敗を分析し、dangerouslyDisableSandboxパラメータ付きで再試行することがあります。承認の扱いは権限モードで変わります（公式: The unsandboxed retry escape hatch）。

権限モード	再試行の扱い
bypassPermissions	プロンプトなしで実行される
Manual、acceptEdits	「Bash command (unsandboxed)」というプロンプトが出る
auto mode	別の分類器が元のコマンドを評価する
dontAsk	拒否される

注意したいのは、Bash(curl *)のようなallowルールがコマンドに一致すると、そのルールが再試行も承認してしまい、プロンプトなしでサンドボックス外で動く点です。再試行にプロンプトを出させたいなら、Bash(dangerouslyDisableSandbox:true)のaskルールを足します。

再試行そのものを禁止するには、sandbox設定で"allowUnsandboxedCommands": falseにします。するとdangerouslyDisableSandboxは無視され、サンドボックスが動いている間は、excludedCommandsに一致しない限りClaudeのコマンドはサンドボックス内で動きます。/sandboxのOverridesタブでは、この設定がStrict sandbox modeとして表示されます。サンドボックスを起動できないときに外で動かしたくない場合は、failIfUnavailableも併せて設定します。

使う場面と運用の考え方｜仮の例で見る設定の作り方

サンドボックスが向くのは、ビルドやテストなど同じ種類のコマンドを繰り返し実行させる場面です。作業範囲を先に絞るほど、承認の回数を減らしても影響範囲を限定できます。

ここからは、公式ページに書かれた機能を使った設定の組み立て方を、仮の例で示します。実在の事例や成果ではなく、設定の考え方を示すための想定です。

仮の例として、Node.jsのプロジェクトでnpm installとテストの実行をClaudeに任せたいとします。手順は次の順です。まず/sandboxを開いてauto-allowを選びます。次に、npmが使うレジストリのドメインをnetwork.allowedDomainsに追加し、プロンプトの回数を減らします。ビルドの成果物を作業ディレクトリの外へ出す必要があれば、そのパスだけをfilesystem.allowWriteに足します。最後に、~/.sshと~/.aws/credentialsなどをcredentialsのdenyに入れ、読ませたくないものを塞ぎます。この例で外へ出すものは、レジストリへの通信と指定した1つの出力先だけで、ほかは境界の内側のままです。

仮の例をもう1つ挙げます。テスト実行中にだけdocker composeが必要なプロジェクトなら、excludedCommandsにdocker compose *のように範囲を絞って書きます。docker *のように広く書くと、そのツールにできることすべてがサンドボックス外になるため、できるだけ狭いパターンにするのが公式ページの考え方に沿っています。

非対話での自動実行にも相性があります。claude -pで動かすヘッドレスモードのように、人がプロンプトに答えない場面では、承認待ちで止まらないことが重要です。公式ページは、無人の実行で隔離の境界を選ぶ話を別ページ（Sandbox environments）に分けて説明しています。そこでは、組み込みのサンドボックスとdev container、コンテナ、仮想マシンの比較も扱われています。

複数のエージェントを使う場合は、サブエージェントの扱いも知っておくと安心です。公式ページによると、サブエージェントは親セッションと同じプロセスで動き、同じサンドボックス設定を使います。親でサンドボックスが有効なら、サブエージェント内のBashコマンドもサンドボックス内で動きます。

組織で強制したい場合の設定も公式ページにあります。管理設定でenabledをtrue、failIfUnavailableをtrue、allowUnsandboxedCommandsをfalseにする例です。サンドボックスが動かない環境では起動を止め、サンドボックス外での再試行を無効にします。ただしネイティブWindowsではサンドボックスが動かないため、failIfUnavailableを有効にするとClaude Codeが起動時に終了します。Windowsを含む環境では、OSごとに設定を配布するか、WSL2やコンテナへ移す選択肢が示されています。

つまずきやすい点と対処｜よく出る症状の確認先

サンドボックスで失敗するコマンドには、ホスト未許可、ツールの非互換、プロキシを使わない通信などの原因があります。症状ごとに公式ページの対処を確認します。

公式ページのトラブルシューティングには、症状ごとの対処が並んでいます。代表的なものを、原因と対処の対応で整理します（公式: Troubleshooting）。

症状	公式ページが示す原因と対処
host-not-allowedのエラーで失敗する	多くのCLIツールは特定のホストに届く必要がある。プロンプトで承認するかallowedDomainsに追加する。組織がallowManagedDomainsOnlyで固定している場合は管理者に依頼する
jestが止まる、または失敗する	watchmanがサンドボックスと非互換。jest --no-watchmanで実行する
dockerが失敗する	サンドボックスと非互換。docker compose *のようなパターンをexcludedCommandsに入れる
macOSでopenやosascriptが-600で失敗する	Apple Eventsが既定でブロックされている。allowAppleEventsで許可できるが、コード実行の隔離が外れる
gitのunable to unlink oldエラー	保護パス、denyWriteの項目、書き込み許可の外にあるファイルを置き換えようとしている
コンテナ内でbubblewrapが起動しない	enableWeakerNestedSandboxをtrueにする。ただし外側のコンテナが必要な隔離を提供している場合に限る

設定の反映先にも注意が必要です。公式ページによると、組織のサンドボックスが「admin-required」の状態では、プロジェクトの設定ファイルにある対処用の設定をClaude Codeが無視します。その場合は~/.claude/settings.jsonに保存します。それでも効かなければ、管理設定が同じキーを設定している可能性があります。

macOSでSSH経由のgitが失敗する点も、公式ページが明記しています（公式: git over SSH fails）。macOSではSSHリモートへのgit fetch、git pull、git pushが、ホストを許可してもサンドボックス内で失敗します。LinuxとWSL2では、ホストを許可すれば動きます。macOSでは、リモートをHTTPSへ切り替える方法が案内されています。

設定の状態確認にはclaude doctorが使えます（公式: 0-byte read-only files）。公式ページは、IPv6アドレスの曖昧な書き方や、LinuxのサンドボックスがKillされたセッションの後に残した0バイトのプレースホルダーファイルなど、複数の問題をこのコマンドで検出できると説明しています。

限界と注意点｜サンドボックスは完全な隔離境界ではない

サンドボックスはリスクを減らす仕組みであり、完全な隔離境界ではありません。公式ページの限界を理解したうえで、許可リストを信頼できる範囲に絞る必要があります。

公式ページはまず、サンドボックスがリスクを下げるもので、完全な隔離境界ではないと明記しています。ハードなセキュリティ制御として頼る前に、限界を確認するよう求めています（公式: Limitations）。主な注意点は次のとおりです。

• ネットワークの絞り込み: 既定ではプロキシがTLSを終端も検査もしないため、暗号化された通信の中身は調べられません。信頼できるドメインだけを許可する責任は利用者にあります
• 広いドメインの許可: github.comのような広いドメインを許可すると、データ持ち出しの経路になり得ます。ドメインフロンティングなどの手法で、許可リスト外のホストへ届く可能性もあります。より強い保証が必要な場合は、TLSを終端して検査するカスタムプロキシを設定します
• Unixソケット: allowUnixSocketsの設定が、システムサービスへのアクセスを意図せず許し、サンドボックスの回避につながることがあります
• 広すぎる書き込み許可: $PATH上の実行ファイルがあるディレクトリや、.bashrcなどのシェル設定ファイルへの書き込みを許すと、権限昇格につながり得ます
• Linuxの弱いネストモード: enableWeakerNestedSandboxはDockerなどの環境で動かすためのもので、セキュリティを大きく弱めます。ほかの隔離が別に効いている場合に限って使います
• Apple Events: allowAppleEventsを有効にすると、サンドボックス内のコマンドが、ほかのアプリケーションをサンドボックスなしで起動できるようになります

最後の警告として、公式ページは効果的なサンドボックスにはファイルシステムとネットワークの両方の隔離が必要だと述べています。ネットワークの隔離がなければ、侵害されたエージェントがSSH鍵などを外へ送れます。ファイルシステムの隔離がなければ、システム資源に細工してネットワークへ出る手段を得られます。既定を広げるときは、allowWriteのパス、広いallowedDomainsの項目、excludedCommandsの例外のどれもが、反対側の制限を打ち消さないか確認する、という確認の観点が示されています。

範囲の面では、Computer useも対象外です。Claudeがアプリを開いて画面を操作するときは、隔離された環境ではなく実際のデスクトップ上で動き、アプリごとの権限プロンプトで制御されます。サンドボックスの有無にかかわらず、この点は別に判断してください。

よくある質問（FAQ）

Q1. Claude Codeのサンドボックスは最初から有効ですか。

いいえ。公式ページには既定ではオフと書かれています。セッション内で/sandboxを実行するか、設定ファイルでsandbox.enabledをtrueにして有効化します（公式: Get started）。

Q2. Windowsでも使えますか。

ネイティブWindowsではサンドボックスなしでコマンドが実行されます。対応するのはmacOS、Linux、WSL2です。Windowsマシンで使うなら、WSL2のディストリビューション内でClaude Codeを動かします。WSL1では「Sandboxing requires WSL2」と表示されます（公式: Configure the sandboxed Bash tool）。

Q3. サンドボックスと権限設定はどちらか一方を選ぶものですか。

いいえ。公式ページは、サンドボックス、権限ルール、権限モードを補い合う層と説明しています。権限ルールは全ツールに実行前の判断を行い、サンドボックスはシェルコマンドの実行中の範囲をOSが制限します。両方の設定は最終的なサンドボックス設定に統合されます（公式: How sandboxing relates to permissions and permission modes）。

Q4. サンドボックスを有効にすれば、ReadツールやWebFetchも制限されますか。

制限されません。公式ページによると、Read、Edit、Write、WebFetch、WebSearchは権限ルールに従い、denyReadはReadツールを止めず、allowedDomainsはWebFetchを制限しません。これらを止めたいときは権限ルールで設定します（公式: What runs outside the sandbox）。

Q5. 許可していないドメインに接続しようとするとどうなりますか。

コマンドはサンドボックス内にとどまり、権限モードに応じた判断を待ちます。ManualモードやacceptEditsモードではプロンプトが出て、dontAskモードでは拒否されます。strictAllowlistやallowManagedDomainsOnlyを設定していると、どのモードでも拒否されます（公式: Hosts outside your allowed domains）。

Q6. dockerが動かないときはどうすればよいですか。

公式ページは、dockerがサンドボックスと非互換だとしています。必要なコマンドだけをexcludedCommandsにdocker compose *のようなパターンで入れてサンドボックスから外します。外したコマンドは完全なアクセス権で動くため、パターンはできるだけ狭くします（公式: docker commands fail）。

Q7. サンドボックスが動いているかはどう確かめますか。

Claudeにtouch ~/sandbox-probeとcurl --noproxy '*' https://example.comを実行させます。どちらもサンドボックス内では失敗するのが正しい状態です。自分で!から打つと通常はサンドボックス外で動くため、確認になりません（公式: Confirm commands run inside the sandbox）。

まとめ｜範囲を絞って任せるための設定の順番

Claude Codeのサンドボックスは、シェルコマンドが触れるファイルと接続先をOSが制限する機能で、既定ではオフです。macOS、Linux、WSL2で動き、ネイティブWindowsでは動きません。有効化は/sandboxから始め、auto-allowかregular permissionsを選び、触れる範囲をfilesystemとnetworkの設定で調整します。権限設定とは別の層で、実行前の判断と実行中の境界を併用するのが公式ページの位置づけです。次の順で進めると、設定のずれを減らせます。

1. 対応OSと依存関係を確認し、/sandboxで有効にします
2. Claudeにtouchとcurlを実行させて、境界が効いているか確かめます
3. 必要な書き込み先をallowWrite、必要なドメインをallowedDomainsに最小限で足します
4. credentialsで、読ませたくない認証情報と環境変数を塞ぎます
5. 外したいコマンドはexcludedCommandsに狭いパターンで書き、再試行を許すかをallowUnsandboxedCommandsで決めます

サンドボックスの外で動くツールや、広い許可リストが残す余地は、公式ページの限界の節で確認してください。権限設定の細かいルールは権限設定（permissions）の使い方、プロジェクトの方針を伝える書き方はCLAUDE.mdの書き方の記事が参考になります。