Sandboxing（サンドボックス）

Claude CodeにビルドやテストのBashコマンドを任せたいが、毎回の許可が面倒で、かつ秘密ファイルや知らないネット接続には触られたくない人向け

Claude CodeにBashコマンドを任せると、テストやビルドを走らせるたびに「これ実行していい？」と確認が挟まります。毎回はだるい。かといって全部許可すると、作業フォルダの外まで勝手に書き換えられたり、隠しておきたい認証用のファイルを読まれたりしないか不安になります。sandbox はこの板挟みを、OSの力で物理的に解く仕組みです。

やり方はシンプルで、1コマンドずつ承認する代わりに「触っていいファイルの範囲」と「つないでいいネット接続先」を先に決めます。あとはBashコマンドとそこから派生する子プロセス全部に、その境界をOSが強制してくれます。許可を聞かれる回数は激減するのに、外側には漏れない。これが基本のうれしさです。

噛み砕くと

イメージとしては、Claudeに作業部屋を1つあてがう感じです。部屋の中（＝作業フォルダ）では自由に物を動かしていい。でもドアの外の廊下や他人の部屋には出られない。窓から外（＝ネット）に手紙を出したいときだけ、最初の1回は「ここに出していい？」と聞いてくる。

鍵をかけてるのは部屋の管理人、つまりOSそのものです。Claudeが「ここ出ていいよね」と勝手に判断するのではなく、macOSやLinuxの機能がドアを物理的にロックしている。だからClaude側のミスや暴走では境界を越えられません。ここが普通の「許可するか聞く」設定と決定的に違うところです。

sandbox が縛るのは「ファイル」と「ネット」の2方向

境界は2つの方向にかかります。両方そろって初めて意味を持つので、片方だけだと思うと足をすくわれます。

1つ目はファイルの方向。初期状態だと、書き込みは作業フォルダとその下だけに限られます。フォルダの外や、システムの大事なところ（たとえば ~/.bashrc や /bin/）は書き換え不可。一方で読み取りはコンピュータ全体が対象です。ここが落とし穴で、初期状態のままだと ~/.aws/credentials や ~/.ssh/ のような秘密ファイルまで読めてしまいます。公式もはっきり警告しています。

this default still allows reading credential files such as ~/.aws/credentials and ~/.ssh/. Add them to denyRead to block them.

守りたいなら、後で出てくる denyRead に足してふさぐ。「sandboxにしたから秘密も自動で安全」は誤解です。

2つ目はネットの方向。最初は許可された接続先がゼロです。コマンドが新しい接続先を必要とした瞬間、Claude Codeが「ここつないでいい？」と聞いてきます。先に許す相手は allowedDomains、逆に必ず塞ぐ相手は deniedDomains に書きます。

動くのは macOS・Linux・WSL2。ネイティブWindowsは対象外

この仕組みはClaude Code本体に組み込まれていて、追加インストールなしで使えます。ただし動く土台が決まっています。

macOS では Seatbelt という標準の機能を使うので、何も入れずにそのまま動きます。Linux では bubblewrap という別の仕組みを使い、これは追加で2つのパッケージが要ります。Ubuntu や Debian なら sudo apt-get install bubblewrap socat で入ります。Windows はネイティブでは動きません。WSL2 という、Windowsの中でLinuxを動かす環境の上で動かします。WSL1 は不可です。bubblewrap がWSL2のカーネル機能を必要とするためです。

依存が足りないと、設定パネルに Dependencies タブだけが出ます。インストールしてClaude Codeを再起動すれば使えるようになります。

「料理ブログの開発」を例に、実際の手順を見る

料理ブログのサイトを作っているとします。レシピを表示するページを直すたび、Claudeにテストとビルドを走らせてほしい。でも毎回「これ実行していい？」が出るのは面倒だし、Macの中にある別件のSSH鍵やAWSの認証ファイルは絶対に触られたくない。この状況で sandbox を組んでいきます。前提はmacOS（Seatbeltがすぐ使える）、もしくはLinux/WSL2なら bubblewrap と socat が入っている状態です。

ステップ1: 設定パネルを開く

Claude Codeの中で /sandbox と打ちます。これで sandbox の設定パネルが開きます。タブが3つ見えるはずです。承認方式を選ぶ Mode、sandboxで失敗したコマンドの扱いを決める Overrides、解決後の設定を確認する Config の3つです。

/sandbox

ステップ2: Mode タブで auto-allow を選ぶ

Mode タブで auto-allow mode を選びます。これを選ぶと、Bashコマンドは sandbox の中で動こうとして、許可を求めずに自動で走るようになります。選んだ内容は .claude/settings.local.json に書き込まれます。このファイルはこのプロジェクト限定で、git の管理対象からは外れています。

ステップ3: Claudeにテストを頼む

「レシピ表示のテストを流して」と頼みます。テストもビルドも、作業フォルダの中だけで完結するBashコマンドなら、承認なしでスッと走ります。確認の連打から解放される瞬間です。これが地味に効きます。

ステップ4: 外部の接続先で初めて聞かれる

ここで初心者がやりがちな勘違いがあります。「auto-allowにしたんだから全部黙って通る」と思い込むことです。実際はネット接続は別扱いで、初期状態は許可ゼロ。たとえば npm がパッケージを取りに外部のレジストリへつなごうとした瞬間、Claude Codeが「ここつないでいい？」と1回聞いてきます。よく使う相手なら allowedDomains に足しておけば次から聞かれません。

ステップ5: 秘密ファイルを読み取り禁止にする

初期状態のままだと、SSH鍵やAWSの認証ファイルが読めてしまいます。ここを塞ぎます。全プロジェクトで効かせたいので ~/.claude/settings.json に書きます。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws"]
    }
  }
}

これで ~/.ssh と ~/.aws の中身は、sandboxされたコマンドからは読めなくなります。

逆向きに、書き込みを禁じたい場所には denyWrite が使えます。たとえば "denyWrite": ["~/.zshrc"] と書けば、起動時に読まれる設定ファイルを書き換えるコマンドを弾けます。読み取りも細かく出し入れでき、"denyRead": ["~/"] でホームをまるごと読み禁止にしつつ "allowRead": ["."] でプロジェクトのフォルダだけ読み戻す、という指定も可能です。

ステップ6: 作業フォルダの外に書く必要が出たら許可を足す

たとえば npm が作業フォルダの外（~/.npm など）に何か書く必要が出ることがあります。そのままだと書き込みが弾かれて失敗します。そういうツールには、書いていい場所だけをピンポイントで許可します。kubectl や terraform でも同じです。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.npm", "/tmp/build"],
      "denyRead": ["~/.ssh", "~/.aws"]
    }
  }
}

ちなみに auto-allow にしていても、rm -rf ~ のようにホームディレクトリやシステムの根っこを消そうとするコマンドは、必ず確認が出ます。自動承認の中にも安全弁が残っているわけです。

つまり Sandboxing は何をしてくれるのか

• やってくれる: 触れる範囲をファイルとネットの2方向で先に決め、その境界をOSに強制させる。auto-allow なら範囲内のBashを承認なしで走らせる
• やってくれない: 完全な隔離ではない。ネット通信の中身（TLS）は検査しないので、広い接続先を許すと情報が外に漏れる抜け道になりうる
• 意味が薄い場面: Read・Edit・Write といった組み込みのファイル操作には効かない（これらは承認の仕組みを直接通る）。Bashの外の話には及ばない

使いどころ3シナリオ（具体題材で再現）

シナリオ1: 料理ブログのテストを回しまくるとき

レシピ一覧の表示崩れを直しては確認、を1日に何十回も繰り返す開発フェーズ。auto-allow にしておけば、テストとビルドのBashが承認なしで走り続けます。確認ダイアログで集中が切れない。それでいて、別フォルダに置いた家計簿アプリのコードや、Macの認証ファイルには触れない。攻めと守りを同時に取れる典型例です。

シナリオ2: 知らない人のコードを試しに動かすとき

GitHubで見つけた料理ブログ用のテーマを、手元のMacにコピーして動かしてみたい。でも中で何が走るか分からなくて怖い。こういうときこそ sandbox です。書き込みは作業フォルダ内だけ、ネットは初期状態で全部ブロックなので、勝手にどこかへ通信されても1回は止まります。さらに ~/.ssh を denyRead で塞いでおけば、鍵を抜かれる心配も減ります。

シナリオ3: チームの環境を管理者が固めたいとき

複数人で料理ブログを開発していて、全員のClaude Codeで sandbox を必ず効かせたい。~/.claude/settings.json の sandbox.enabled を true にすれば全プロジェクトで有効になります。さらに、sandboxが起動できない環境では作業を止めたいなら sandbox.failIfUnavailable を true に。これでsandboxが「あれば便利」から「ないと動かさない」セキュリティの関門に変わります。

初心者が踏みやすい落とし穴

• 初期状態だと秘密ファイルが読める。読み取りはコンピュータ全体が対象なので、~/.aws/credentials や ~/.ssh/ も見えてしまう。守りたいなら denyRead に足す。これが一番実害の出やすい誤解です
• あらかじめ覚えさせた認証情報はsandboxの外にある。~/.aws を denyRead で塞いでも、ターミナルに AWS_SECRET_ACCESS_KEY=xxx のような値を起動時から覚えさせていれば、子プロセスはその値を読めてしまう。sandbox はこの種の起動時の設定値までは検査しません。Anthropicやクラウドの認証情報を子プロセスから取り除きたいときは CLAUDE_CODE_SUBPROCESS_ENV_SCRUB という設定値を使います
• これは「実行するか聞くか」を決める設定ではない。公式も /sandbox is not a permission mode と明言しています。承認の仕組みは「そのコマンドを実行するか・先に聞くか」を決め、sandbox は「実行されたコマンドが何に触れるか」を縛る。別の層なので併用できます
• 完全な隔離ではない。ネット通信の中身（TLS）は検査されない。github.com のような広い接続先を丸ごと許すと、そこを経由して情報が外に持ち出される穴になりえます。守りを厳しくしたいなら、中身を検査する仕組みを別に用意する
• ネイティブWindowsでは動かない。WSL2の中で動かす。WSL1も不可。LinuxではあらかじめBubblewrapとsocatのインストールが要ります
• sandboxで動けないコマンドがある。docker や jest が使う watchman、gh や gcloud や terraform などはsandbox非対応。excludedCommands に入れてsandboxの外で動かします。失敗した場合、Claudeが dangerouslyDisableSandbox を付けて再試行することがあり、その時は通常の承認が求められます
• auto-allow でも何でも通るわけではない。明示の拒否ルールは常に効くし、/ やホームを狙う rm・rmdir は必ず確認が出ます。抜け道を完全に封じたいなら allowUnsandboxedCommands を false にして、再試行の逃げ道ごと塞ぐ
• 起動できないと黙って外で動く。初期状態では、依存が足りなかったり非対応の環境だと、警告は出るものの止まらずにsandboxなしで実行されます。セキュリティの関門にしたいなら failIfUnavailable を true に
• /sandbox コマンドとこの仕組みは別物。/sandbox はこの仕組みの設定パネルを開くコマンド。こちらの項目は「sandbox という隔離の仕組みそのもの」を指します。設定を開く操作は /sandbox 側を見てください

書き方

/sandbox で設定パネルを開く（Mode / Overrides / Config の3タブ）。または ~/.claude/settings.json の "sandbox": { "enabled": true, "filesystem": { "denyRead": [...], "denyWrite": [...], "allowWrite": [...], "allowRead": [...] } } で直接設定する

やってみるとこうなる

入力

/sandbox

出力例

設定パネルが開き、Mode タブで auto-allow mode を選ぶと .claude/settings.local.json に承認方式が書き込まれる。以降、作業フォルダ内のBashは承認なしで走り、初めての外部接続先に触ると Claude Code が「ここつないでいい？」と1回だけ確認する

関連項目

• /sandbox（サンドボックス）
• Permission Modes（パーミッションモード）
• Allow / Deny Rules（アロウ・デナイ・ルールズ）
• Subagent Types（サブエージェントタイプス）
• --worktree（ワークツリー）
• sandbox.network.deniedDomains（サンドボックス・ネットワーク・ディナイドドメインズ）

公式ドキュメント

https://code.claude.com/docs/en/sandboxing