Claude Codeに頼むだけで、サンドボックスの安全設定はどこまでできる?
公開 2026-04-25 更新 2026-09-20

関連テーマ:権限と実行範囲を確認する
Claude Codeのサンドボックスは、Bashツールのファイルシステムとネットワークを隔離し、確認を減らしながら範囲を制限するための機能です。現行の仕様と制約はConfigure the sandboxed Bash toolを確認してください。実機での動作を見ていない環境を「設定済み」「安全と確認済み」とは書けません。
権限モードとの違い
二つを組み合わせるときも、役割は分けて確認します。
- 権限モード操作の前に確認を求めるかを扱う。
- 内蔵サンドボックス対象のBashツールが触れるファイル・ネットワークを制限する。
すべてのツールやホスト全体を一括で保護する図ではありません。対応OS、依存関係、未隔離での再試行条件を本文で確認します。
Default、Plan、Accept Edits、Auto、Bypassは承認フローを調整します。サンドボックスはBashが触れるファイルや接続できるネットワークを制限します。別の層なので、Autoにしただけで隔離されることも、サンドボックスだけでClaude Code全体が無害になることもありません。環境全体を分けたい場合は、Sandbox environmentsで内蔵サンドボックス、Dev Container、Docker、VMを比較します。
導入前に決めること
プロジェクトのルート、書き込みが必要な生成物、接続が必要なパッケージレジストリなどを列挙します。.env、SSH鍵、本番資格情報を作業環境に置かず、ネットワーク許可を広くしません。設定キーや起動フラグはバージョンで変わるため、古いブログの例ではなく公式ページの現行例を使います。
確認のため、最初は「このファイルを読み、内容だけ説明して」と依頼し、次にテスト用ファイルへ限定した書き込みを行います。書き込み先、ネットワークエラー、拒否された操作を記録し、終了後はgit diffと生成物を確認します。サンドボックスの有効表示だけを根拠に秘密情報の保護や本番影響がないと判断しません。
通信が拒否されたときは、まず「そのコマンドだけの許可」と「設定に保存された許可」を分けます。2026年9月20日に公式のネットワーク説明と設定資料を照合した要点です。
| 仕組み | 許可の範囲と確認点 |
|---|---|
| Autoのコマンド単位の接続先 | v2.1.271以降。コマンドと接続先を一緒に判定し、その実行中だけ許可します。セッションや設定の許可先には追加しません。 |
sandbox.network.deniedDomains |
明示的な拒否は、コマンド単位の追加許可でも解除されません。 |
sandbox.network.strictAllowlist |
有効なら許可一覧外への通信を拒否します。プロジェクトの設定に書いても効かないため、設定元も確認します。 |
sandbox.network.allowManagedDomainsOnly |
管理設定で有効にすると、管理設定の許可先だけを採用します。 |
許可一覧をstrictAllowlistまたはallowManagedDomainsOnlyで固定している場合、コマンド単位の追加許可は使えません。たとえばパッケージ取得が拒否されたら、結果に示された接続先と/sandboxのConfig、設定元を照合します。エラーを消すためだけに拒否設定を外さず、必要な接続先か確認してください。これらはサンドボックス内の通信の説明で、WebFetchなどの権限や未隔離での再試行は別に確認します。各環境での実機検証はしていません。
/sandboxを開いてWSL2で確認する
Claude Codeのセッションで次を入力すると、Mode、Overrides、Configのパネルが開きます。
/sandbox
Modeでは、サンドボックス内のBashを自動許可するAuto-allowと、通常の権限確認を残すRegular permissionsを選べます。Overridesではサンドボックスで失敗したコマンドを未隔離で再試行できるか(allowUnsandboxedCommands)を確認します。全プロジェクトで有効にする場合はユーザー設定の~/.claude/settings.jsonに次のように書きます。
{
"sandbox": {
"enabled": true
}
}
Windowsのネイティブ環境は内蔵サンドボックスに対応していません。PowerShellからwsl -l -vを実行し、対象ディストリビューションがVersion 2であることを確認して、そのWSL2側でclaudeを起動します。WSL1ではSandboxing requires WSL2になり、Linux/WSL2の依存パッケージとしてbubblewrapとsocatが必要です。WSL2からcmd.exe、powershell.exe、/mnt/c/配下のWindows実行ファイルを起動する挙動はUnixソケットを介してホストへ渡るため、必要性を確認して許可範囲を決めます。
依存関係がない場合、既定では警告後に未隔離で実行されます。サンドボックスを必須の境界にする管理環境では、sandbox.failIfUnavailableをtrueにして、未対応環境で処理を続けない構成を検討します。
WindowsではネイティブとWSL2でシェル、パス、設定が分かれます。WindowsのAuto ModeとDev Containerも読み、実際に起動した環境に対してルールを設定してください。
このテーマを続けて読む
モードを比較し、計画と実装、WindowsとWSL2の違いを整理します。
権限と実行範囲を確認するの記事をまとめて見る