Claude Code Sandboxの使い方｜安全にコマンドを自動実行する設定

公開: 2026年8月3日 / 更新: 2026年8月11日・読了目安8分

先に結論: SandboxはOSの標準機能でBashコマンドが触れるファイル・ネットワーク接続先を制限し、範囲内なら権限確認なしで自動実行できる機能です。macOSは追加インストール不要ですが、Windowsで使うにはWSL2上での実行が必要です。

Claude Codeにファイル編集やコマンド実行を任せていると、実行のたびに表示される権限確認プロンプトが煩わしく感じられることがあります。

Sandbox機能を使えば、OSの標準機能でBashコマンドが触れられるファイルとネットワーク接続先をあらかじめ制限し、その範囲内なら確認なしで自動実行できます。

本記事では2026年8月時点の公式ドキュメント(code.claude.com/docs)の仕様に基づき、仕組みの理解から設定方法、対応OS、他の隔離手段との使い分けまで解説します。

基本的な使い方は「Claude Codeの使い方完全ガイド」もあわせてご覧ください。

この記事の要点

Sandboxはファイルシステム隔離とネットワーク隔離の2層で、Bashコマンドの動作範囲をOSレベルに制限します。

macOSは追加インストール不要ですが、Linux・WSL2はbubblewrapとsocatが必要です。

WSL1・ネイティブWindowsは非対応で、Windowsで使うにはWSL2上での実行が必要です。

/sandboxコマンドでMode(auto-allow/regular permissions)を設定でき、auto-allowなら確認なしで自動実行されます。

ネットワークプロキシは既定でTLSを終端・検査しないため、通信内容までは検証されません。

前提・動作環境

Sandbox機能はClaude Codeに組み込まれており、追加のライセンスやサービス登録は不要です。動作環境は次のとおりです。

macOS: 追加インストール不要。標準搭載のSeatbeltフレームワークを使用
Linux: bubblewrapとsocatが必要
WSL2: Linuxと同様にbubblewrap・socatが必要
WSL1・ネイティブWindows: 非対応。WSL2上でClaude Codeを実行する必要があります

セッション中に/sandboxコマンドを実行すると、依存パッケージの不足をパネルが自動判定するため、事前に手動確認する必要はありません。

Sandboxの仕組み(ファイル・ネットワーク隔離)

Sandboxはファイルシステム隔離とネットワーク隔離という2つの独立したレイヤーで構成されています。ファイルとネットワークを二重に隔離する仕組みになっており、どちらか一方の制限を緩めても、もう一方が保護を続けます。

Sandboxはファイルシステム隔離とネットワーク隔離という独立した2層で構成され、どちらか一方の制限を緩めても、もう一方が保護を続けることを示す図

ファイルシステム隔離では、既定でBashコマンドの書き込み先が「カレントの作業ディレクトリ」と「セッションの一時ディレクトリ($TMPDIR)」に限定されます。

読み取りはコンピュータ全体が対象ですが、~/.claude/settings.jsonなど設定ファイル自体への書き込みは常に拒否され、サンドボックス化されたコマンドが自分自身のポリシーを書き換えることはできません。

ネットワーク隔離は、サンドボックスの外側で動くプロキシサーバーが担います。既定では許可済みドメインはゼロで、新しい接続先が必要になったタイミングで確認プロンプトが表示されます。この制限は子プロセスすべてに及ぶため、npm installのpostinstallスクリプトのような間接的な処理も同じ境界の中に収まります。

これらはmacOSのSeatbelt、LinuxとWSL2のbubblewrapが強制します。適用範囲はBashツールとその子プロセスに限られ、Read・Edit・Writeは別の権限システムで制御される点に注意してください。

権限管理全体は「権限管理の仕組みと設定方法」で解説しています。

有効化する設定方法

Sandboxを有効にする最も手軽な方法は、セッション中に/sandboxコマンドを実行することです。

/sandbox

パネルが開き、「Mode」「Overrides」「Config」の3タブ(Linuxで依存パッケージ不足時はDependenciesタブも)が表示されます。「auto-allow」ならサンドボックス化できるコマンドは確認なしで自動実行され、「regular permissions」なら通常の権限確認が続きます。

ここで選んだ設定はプロジェクトの.claude/settings.local.jsonに保存され、そのプロジェクトだけに適用されます。すべてのプロジェクトで有効にしたい場合は、ユーザー設定~/.claude/settings.jsonに直接記述します。

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

allowWriteはkubectlやterraformのように作業ディレクトリ外への書き込みが必要なツールのために、追加の書き込み許可パスを指定する設定です。パスはOSレベルで強制され、子プロセスにも適用されます。ネットワーク側はnetwork.allowedDomainsで許可ドメインを事前登録でき、プロンプトを出さずに接続を許可できます。

対応OSと導入手順

macOSでは追加インストール不要で、そのまま/sandboxを実行できます。LinuxとWSL2では次の2パッケージが必要です。

# Ubuntu/Debian
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

インストール後にClaude Codeを再起動すると依存関係チェックが再実行されます。WSL1とネイティブのWindowsは非対応のため、wsl -l -vでWSL1と表示された場合はWSL2へのアップグレードが必要です。

またWSL2環境ではサンドボックス化されたコマンドからcmd.exeやpowershell.exe、/mnt/c/配下のバイナリを直接起動できません。Windows側の実行ファイルが必要な場合は、excludedCommandsにそのコマンドを追加してサンドボックス対象外にします。

{
  "sandbox": {
    "excludedCommands": ["docker *"]
  }
}

許可プロンプト削減のメリット

Sandboxを有効にする最大のメリットは権限確認プロンプトの削減です。auto-allowモードでは、サンドボックス化できたコマンドは確認なしで実行されるため、ビルドやテストの実行のようなタスクをまとめて任せやすくなります。

ただし、すべての確認が省略されるわけではありません。明示的なdenyルールは常に有効なほか、rmやrmdirが/やホームディレクトリなど重要パスを対象にする場合は引き続き確認が入ります。またBash(git push *)のように入力内容を指定したaskルールも確認を強制します。

裸のBash許可ルールだけはサンドボックス化されたコマンドでスキップされる仕様なので、細かく制御したい操作にはコンテンツ指定のルールを併用するとよいでしょう。

devcontainerやpermissions設定との使い分け

Sandboxと似た目的の仕組みに、権限設定とDevContainerがあります。役割の違いを整理すると使い分けやすくなります。

permissions・Sandbox・DevContainerの役割の違いを示す対比図。permissionsはツール呼び出しをルールベースで判定し、Sandboxは許可されたBashコマンドが触れるファイル・ネットワーク先をOSレベルで強制し、DevContainerはプロジェクト全体をコンテナに隔離することを示す

permissions設定: どのツール呼び出しを実行してよいかをコマンド文字列やルールベースで判定します。Bash以外にRead・Edit・WebFetch・MCPなど全ツールに適用されます
Sandbox: 実行が許可されたBashコマンドが実際にどのファイル・ネットワーク先に触れられるかをOSレベルで強制します。コマンド文字列の見た目上の意図に関わらず、動作中のプロセスそのものを制限します
DevContainer: プロジェクト全体をDockerコンテナに隔離し、Bash以外のツールやホスト環境への影響そのものを遮断します。詳しくは「Claude CodeをDevContainerで使う方法」で解説しています

Sandboxのネットワークプロキシは既定でTLSを終端・検査しませんので、許可ドメインへの通信内容までは検証していない点に注意してください。より強固な分離が必要ならDevContainerや専用プロキシとの併用を検討しましょう。同様の隔離手段としては、Codexのサンドボックスが承認モードとの組み合わせで似た役割を果たしています。

つまずきポイント

jestがハングする、または失敗する: watchmanがサンドボックスと非互換です。jest --no-watchmanで実行してください
macOSでgh・gcloud・terraformがTLS検証エラーになる: Seatbelt環境と相性が悪いツールです。excludedCommandsに追加してサンドボックス外で実行しましょう
dockerコマンドが失敗する: dockerはサンドボックスと非互換です。excludedCommandsにdocker *を追加してください
--dangerously-skip-permissionsがrootで拒否される: サンドボックス内なら自動でチェックがスキップされますが、root・sudoでの直接実行は引き続き拒否されます。非rootユーザーで実行するか「DevContainerで使う方法」の構成を利用してください

よくある質問

Sandboxを有効にすればpermissions設定は不要になりますか?

いいえ、不要にはなりません。Sandboxは実行が許可されたBashコマンドの動作範囲をOSレベルで制限する仕組みで、そもそもツール呼び出しを実行してよいかを判定するpermissions設定とは役割が異なります。両方を組み合わせるとより安全な運用になります。

DevContainerと同時に使う必要がありますか?

必須ではありませんが、組み合わせて問題ありません。DevContainerはプロジェクト全体をコンテナに隔離する仕組み、Sandboxはその中でBashコマンドの挙動を細かく制限する仕組みなので、両方使うとより多層的な防御になります。

ネットワークの通信内容まで検査してくれますか?

いいえ、既定では検査しません。プロキシは接続先ドメインの許可・拒否のみを判定し、TLSを終端・検査しないため通信内容までは確認していません。より厳密な検査が必要なら、独自のプロキシでTLS終端を行う必要があります。

まとめ

Sandboxを使えば、Claude CodeのBashコマンドが触れられるファイルとネットワーク接続先をOSレベルで制限しつつ、範囲内のコマンドは確認なしで自動実行できます。

macOSなら追加インストール不要、Linux・WSL2でもbubblewrapとsocatを入れるだけで/sandboxから試せる手軽さが魅力です。

一方でTLSの中身までは検査しない点や、Docker・watchman系ツールとの非互換など制限事項もあるため、過信せず用途に応じて設定を調整することが大切です。

権限管理は「権限管理の仕組みと設定方法」、コンテナ単位の隔離は「DevContainerで使う方法」、基本操作は「Claude Codeの使い方完全ガイド」もあわせてご覧ください。

hooksやgit、rewindと合わせた事故防止の全体像は「誤削除を防ぐ安全運用ガイド」でも整理しています。