Claude Code のサンドボックス（/sandbox）とは｜有効にする方法と止まること・止まらないこと【2026年11月】

Claude Code のサンドボックスは、Claude が実行するシェルコマンドを、OS の仕組みで「書き込める場所」と「通信できる相手」の内側に閉じ込める機能です。 セッションの中で /sandbox と入力すると設定画面が開き、そこでモードを選ぶだけで有効になります。初期設定では無効なので、使うには自分で一度オンにする必要があります。

オンにすると、npm install や git のようなコマンドは、作業中のフォルダと一時フォルダ以外に書き込めなくなり、許可したドメイン以外へは通信できなくなります。そのうえで、内側で動くコマンドは1つずつ承認しなくても実行させられるので、「確認ダイアログが多すぎる」と「何でも許可するのは怖い」の間を取れるのが特長です。Anthropic は、社内の利用でサンドボックスにより権限の確認が84%減ったと公表しています（出典: Anthropic Engineering「Beyond permission prompts: making Claude Code more secure and autonomous」2025年10月20日）。

一方で、サンドボックスが守るのはシェルコマンドだけです。Claude 自身のファイル編集ツールや MCP サーバー、hooks は対象外で、ここを取り違えると「サンドボックスを入れたのに外のファイルが変わった」ということが起きます。本記事では、2026年11月7日に取得した Claude Code の公式ドキュメント（Configure the sandboxed Bash tool、Settings reference、Choose a sandbox environment）と CHANGELOG を原典に、仕組み・設定・注意点を整理します。サンドボックスが有効なセッションで実際にコマンドを動かして確かめた結果と、ドキュメントの記載から分かる内容は書き分けています。

結論：サンドボックスは「シェルコマンドの壁」、全体を閉じ込めるものではない

サンドボックスは、Claude が実行するシェルコマンドとその子プロセスだけを、ファイルとネットワークの2つの壁で囲む仕組みです。 2026年11月時点で押さえる点は次の5つです。

1. 初期設定はオフ：/sandbox で設定画面を開いてモードを選ぶか、設定ファイルで sandbox.enabled を true にすると有効になります
2. 対応は macOS・Linux・WSL2：Windows でそのまま動かす場合はサンドボックスなしで実行されます。Windows で使うなら WSL2 の中で Claude Code を動かします
3. 書き込みは作業フォルダと一時フォルダまで、読み取りはほぼ全体：初期設定では ~/.ssh や ~/.aws/credentials のような認証情報のファイルは読めてしまうので、守りたいものは自分で指定します
4. 通信は許可したドメインだけ：許可リストは最初は空で、新しいドメインが必要になるたびに確認が出ます（権限モードによって扱いが変わります）
5. ファイル編集ツール・MCP・hooks は対象外：これらは権限ルールで管理します。Claude Code ごと閉じ込めたいなら、コンテナや仮想マシンを使います

Claude Code の権限の確認を減らす別の方法として、自動判定のモデルに任せる Claude Code の auto モードがあります。サンドボックスと auto モードは別の仕組みで、組み合わせて使うこともできます（違いは後半の比較表で整理します）。

状況別の読み分け早見表

目的に合わせて、先に読む節を選んでください。

Claude Code のサンドボックスとは

Claude Code のサンドボックスとは、Claude が実行するシェルコマンドの書き込み先と通信先を、OS が強制する境界で制限する機能です。 公式ドキュメントでは「sandboxed Bash tool（サンドボックス化された Bash ツール）」と呼ばれています。対象は Bash・PowerShell・Monitor の3つのツールが実行するコマンドと、そのコマンドが起動したプロセスすべてです。

たとえば Claude が npm test を実行すると、npm が中で呼び出す node やビルドツールも同じ境界の内側で動きます。コマンドの名前がおとなしく見えても、中で何をしようとしても、境界の外には書けず、許可していない相手とは通信できません。ここが、コマンドの文字列を見て判断する「権限ルール」との大きな違いです。

2つの壁：ファイルとネットワーク

サンドボックスには、独立した2つの層があります。

• ファイルの壁：どのフォルダに書き込めるか、どのファイルを読めるかを制限します
• ネットワークの壁：どのドメインにつながるかを制限します

公式ドキュメントは「効果のあるサンドボックスには、ファイルとネットワークの両方の隔離が必要」と強調しています。ネットワークの壁がなければ、乗っ取られたエージェントが SSH の鍵のような機密ファイルを外へ送れてしまいます。ファイルの壁がなければ、システムのファイルに裏口を仕込んで、外へ通信する手段を手に入れられてしまいます。片方だけでは穴が残る、という考え方です。

OS ごとの仕組み

境界を強制するのは Claude Code ではなく OS の機能です。

Claude Code のサンドボックスは、オープンソースの @anthropic-ai/sandbox-runtime というパッケージの上に作られています。CHANGELOG では、バージョン 2.0.24 の項に「Linux と Mac で BashTool のサンドボックスモードを公開」とあり、これが最初の提供です（出典: Claude Code CHANGELOG）。2026年11月7日時点の最新版は 2.1.319 で、その間に設定項目が大きく増えています。

有効にする方法

サンドボックスは、セッション中に /sandbox を実行し、表示された画面でモードを選ぶと有効になります。 手順は次のとおりです。

ステップ1：/sandbox を実行する

Claude Code を起動し、入力欄に /sandbox と打ちます。設定画面が開き、次のタブが並びます。

Dependencies タブしか出ない場合は、まだサンドボックスを起動できない状態です。表示に従って部品を入れ、Claude Code を再起動してから、もう一度 /sandbox を実行します。

ステップ2：モードを選ぶ

Mode タブで「auto-allow（自動許可）」か「regular permissions（通常の確認）」を選びます。違いは次の節で説明します。迷ったら、まず自動許可を選んで、確認ダイアログがどれだけ減るかを試すのが分かりやすいでしょう。

ステップ3：コマンドを実行させる

Claude にビルドやテストのコマンドを実行させます。初めて新しいドメインへの通信が必要になったときは、確認が出ます。auto モードの場合は確認の代わりに、Claude がコマンドごとに必要なホストを申告し、自動判定のモデルがコマンドと一緒に審査します。

設定がどこに保存されるか

/sandbox の画面で選んだモードは、そのプロジェクトの .claude/settings.local.json に保存されます。このファイルは自動的にグローバルの gitignore に追加されるので、リポジトリには入りません。すべてのプロジェクトでサンドボックスを使いたい場合は、ユーザー設定 ~/.claude/settings.json に次のように書きます。

{
  "sandbox": {
    "enabled": true
  }
}

1回のセッションだけ試したい場合は、設定ファイルを書き換えずに --settings で渡せます。次の例は、サンドボックスを有効にし、サンドボックスの外でのやり直しを禁止して起動します。

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

本記事では、設定ファイルのキーのうちサンドボックスに関係するもの（sandbox の下）だけを扱います。

注意：起動できないと黙ってサンドボックスなしで動く

初期設定では、OS が対応していなかったり、起動時の部品の確認に失敗したりすると、Claude Code はサンドボックスなしでコマンドを実行します。止まるのではなく、そのまま動き続ける点に注意してください。サンドボックスが使えないなら起動しないようにしたい場合は、sandbox.failIfUnavailable を true にします。安全のための前提条件としてサンドボックスを使う会社の配布設定では、この設定が向いています。

対応している環境と準備

macOS は準備なしで使え、Linux と WSL2 は bubblewrap と socat を入れると使えます。 Windows でそのまま動かす Claude Code はサンドボックスに対応していません。

macOS

macOS に組み込まれた Seatbelt を使うので、追加のインストールは要りません。/sandbox からすぐ始められます。

Linux

パッケージマネージャーで2つの部品を入れます。

# Ubuntu / Debian
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

部品の確認は起動時に行われるので、入れた後は Claude Code を再起動します。Ubuntu では、AppArmor によるユーザー名前空間の制限で bubblewrap が起動できないことがあります。その場合、公式ドキュメントは /usr/bin/bwrap 用の AppArmor プロファイルを追加する手順を案内しています。

Unix ドメインソケットへの接続を止める seccomp フィルターは任意の部品で、無くてもサンドボックスは動きます。Dependencies タブがほかのタブと並んで表示されている場合は、この任意の部品が足りないだけです。

WSL2（Windows で使う場合）

Windows では、WSL2 のディストリビューションの中に Claude Code を入れて使います。準備は Linux と同じです。WSL1 で動かしていると「Sandboxing requires WSL2」と表示されるので、PowerShell で wsl -l -v を実行してバージョンを確かめ、WSL2 に切り替えます。

WSL2 では、cmd.exe や powershell.exe、/mnt/c/ 以下の Windows のプログラムを起動する操作が、Unix ソケットを通じて Windows 側に渡されます。そのため、サンドボックス内からこれらを起動できるかどうかは、Unix ソケットの設定しだいになります。

2つのモード：自動許可と通常の確認

自動許可モードは「サンドボックスの内側で動くコマンドは確認なしで実行する」、通常の確認モードは「サンドボックスの内側でも毎回確認する」モードです。 どちらのモードでも、ファイルとネットワークの制限そのものは同じです。違うのは承認のしかただけです。

自動許可（auto-allow）モード

境界が守ってくれることを前提に、内側で動くコマンドを確認なしで実行します。設定キーでは sandbox.autoAllowBashIfSandboxed（既定は true）にあたります。ただし、次のものは自動許可モードでも止まったり確認が出たりします。

• Bash の deny ルール（禁止ルール）に当てはまるコマンドは実行されません
• 重要なパスを対象にした rm・rmdir は、通常の確認に回ります
• Bash(git push *) のように中身を指定した ask ルール（確認ルール）は、サンドボックス内でも確認が出ます
• Monitor ツールのコマンドは、サンドボックス内で動きますが自動では承認されません
• FOO=bar npm test のように前に変数を置いたコマンド、make CC=clang、eval "ls" などは、どのプログラムが動くかが変わりうるため通常の確認に回ります

公式ドキュメントは、自動許可モードが（plan モードなど一部の例外を除き）権限モードとは独立に動く点にも触れています。たとえば、ファイル編集のたびに確認が出る Manual モードでも、自動許可が有効なら、サンドボックス内の Bash コマンドによるファイルの変更は確認なしで実行されます。「編集ツールは毎回聞いてくるのに、シェル経由の書き換えは聞かれない」という状態になるので、作業フォルダの中身をコマンドで書き換えられてよいかを、先に考えておく必要があります。

通常の確認（regular permissions）モード

すべての Bash コマンドが、サンドボックス内でも通常の確認の流れを通ります。境界による保護は残しつつ、承認は自分で行いたい場合に選びます。sandbox.autoAllowBashIfSandboxed を false にしたのと同じです。

サンドボックスの外でのやり直し

サンドボックスの中ではうまく動かないコマンドもあります。そのとき Claude は、失敗の内容を見て、dangerouslyDisableSandbox という指定を付けてサンドボックスの外でやり直すことがあります。誰がそれを承認するかは権限モードで変わります。

外でのやり直しそのものを禁止するには、sandbox.allowUnsandboxedCommands を false にします。/sandbox の Overrides タブでは「Strict sandbox mode」と表示されます。これを入れると、excludedCommands（後述）に書いたもの以外は、Claude が実行するコマンドはすべてサンドボックス内で動きます。なお、Bash(curl *) のような allow ルールがコマンドに当てはまると、その allow ルールが外でのやり直しも承認してしまう点に注意してください。

サンドボックスで止まること・止まらないこと

サンドボックスで止まるのは「シェルコマンドによる、許可した範囲の外への書き込みと通信」で、ファイル編集ツールや MCP サーバーの動作は止まりません。 初期設定で何ができるかを整理すると次のとおりです。

作業フォルダの範囲そのものは、Claude Code の作業ディレクトリと add-dirで詳しく解説しています。--add-dir・/add-dir・permissions.additionalDirectories で足したフォルダは、サンドボックス内のコマンドからも書き込めるようになります。

書き込みが止まらない「保護されたパス」の例外

書き込みできる作業フォルダの中でも、Claude Code が設定やプログラムを読み込むファイルには書き込めません。コマンドがこれらを書き換えられると、自分に権限を与えたり、サンドボックスの外で動く hook や MCP サーバーを足したりできてしまうからです。対象は次のようなファイルです。

• 作業フォルダとその上位にある .claude の設定ファイル、.claude/skills・.claude/agents・.claude/commands・.claude/hooks、.mcp.json
• 作業フォルダの中の .bashrc・.zshrc などのシェル起動ファイル、.gitconfig、.vscode・.idea、.git の中の hooks と config
• ~/.claude のほとんどの中身と ~/.claude.json

allowWrite でこれらのパスを含めても、保護は外れません。

サンドボックスの外で動くもの

次のものはサンドボックスの境界の外で動きます。止めたい場合は、それぞれ別の方法で管理します。

hooks や MCP サーバーまで1つの境界に入れたい場合は、Claude Code の処理全体をコンテナや仮想マシン、または sandbox-runtime の中で動かします。

通信の壁で起きること

サンドボックス内のコマンドは、ネットワークに直接つながりません。Linux・WSL2 では別のネットワーク名前空間で動き、macOS では Seatbelt がプロキシ以外への接続を止めます。Claude Code は手元でプロキシを動かし、HTTPS_PROXY などの環境変数でコマンドをそこへ向けます。プロキシは接続先のホスト名を許可リストと照らし合わせます。

このため、ツールによって結果が変わります。

• curl・npm・HTTPS の git のようにプロキシの環境変数を読むツールは、ホストを許可すればつながります
• 素の ssh や多くのデータベースのドライバーのように、プロキシの環境変数を読まないツールは、許可したホストにもつながりません
• UDP、QUIC を使う HTTP/3、ping のような ICMP はサンドボックスの外に出られません

確認で「Yes」を選ぶと、そのセッションの間だけそのホストが許可されます。「Yes, and don't ask again」を選ぶと、WebFetch(domain:...) の allow ルールがローカル設定に保存され、次回以降も許可されたままになります。

許可リストにないホストへの接続は、権限モードによって扱いが変わります。

サンドボックスの限界

公式ドキュメントは、サンドボックスがリスクを減らすものであって、完全な隔離ではないとはっきり書いています。主な限界は次のとおりです。

• 通信の中身は見ていない：プロキシはホスト名で許可を判断し、初期設定では暗号化された通信の中身を確認しません。github.com のような広いドメインを許可すると、データの持ち出し経路になりえます
• Unix ソケットの許可に注意：たとえば /var/run/docker.sock への接続を許可すると、Docker を通じてホスト全体を操作できてしまいます
• 書き込み先を広げすぎない：$PATH にあるプログラムのフォルダやシェルの設定ファイルへの書き込みを許すと、別の場面でコードを実行される原因になります
• 送られる内容は変わらない：サンドボックスの有無にかかわらず、プロンプトや Claude が読んだファイルの内容はモデルの提供元に送られます

実際に動かして確かめた結果

2026年11月7日、サンドボックスが有効な Claude Code のセッション（macOS 27.0.1）で、公式ドキュメントが案内する確認用のコマンドを Claude に実行させたところ、ドキュメントどおりに止まりました。 公式ドキュメントは、サンドボックスが効いているかを確かめる方法として、次の2つのコマンドを Claude に実行させることを勧めています。入力欄の ! から自分で打つとサンドボックスの外で動くため、確認にならない点に注意してください。

$ touch ~/sandbox-probe
touch: /Users/<ユーザー名>/sandbox-probe: Operation not permitted

$ curl --noproxy '*' https://example.com
curl: (6) Could not resolve host: example.com

1つ目は、作業フォルダの外にあるホームフォルダへの書き込みが「Operation not permitted」で拒否された結果です。Linux と WSL2 では「Read-only file system」と表示されると、ドキュメントに書かれています。2つ目は、プロキシを通らずに直接つなごうとしたため、名前の解決すらできなかった結果です。

続けて、プロキシを通る通常の curl も試しました。このセッションは auto モードで動いており、コマンドが申告していないホストへの接続は拒否されるはずです。

$ curl -sS https://example.com -o /dev/null -w '%{http_code}\n'
curl: (56) CONNECT tunnel failed, response 403
000

プロキシが接続を 403 で断っています。同じコマンドを、接続先として example.com を申告して実行すると、応答コード 200 が返りました。また、一時フォルダ（$TMPDIR）へのファイルの作成は問題なく成功しました。書き込みは作業フォルダと一時フォルダまで、通信は許可したホストだけ、という初期設定の動きが確かめられます。

自分の環境で確かめる場合は、Claude に上の2つのコマンドを実行させます。touch が成功してしまった場合は、作られた ~/sandbox-probe を消してから、/sandbox でサンドボックスが有効になっているか、Linux・WSL2 なら部品がそろっているかを確認します。Claude がサンドボックスの外でのやり直しを求めてきたら、確認のためなので断ります。

権限ルール・auto モード・Docker との違い

権限ルールと auto モードは「そのツールを実行してよいか」を実行前に判断する仕組み、サンドボックスは「実行したコマンドが何に触れられるか」を実行中に制限する仕組みです。 どれか1つを選ぶものではなく、重ねて使えます。主な選択肢を並べると次のようになります。

公式の Choose a sandbox environment は、目的ごとに次の選び方を示しています。

• 自分のパソコンで、日々の確認を減らしたい：組み込みのサンドボックス（/sandbox）
• --dangerously-skip-permissions や auto モードで無人で動かしたい：dev container、コンテナ・VM、または sandbox-runtime
• Docker を使わずに MCP サーバーや hooks も閉じ込めたい：sandbox-runtime
• 信頼できないリポジトリを扱う：専用の仮想マシン、またはクラウドのセッション

組み込みのサンドボックスはシェルコマンドしか閉じ込めないので、それだけでは完全な無人実行には足りない、というのが公式の立場です。特に --dangerously-skip-permissions は、コンテナや VM、sandbox-runtime の中で動かすよう求めています。Docker を使って Claude Code を動かす方法は Claude Code と Docker の活用ガイドで紹介しています。

auto モードとの組み合わせ

サンドボックスの自動許可モードと、権限モードの auto モードは名前が似ていますが、別物です。自動許可は「境界の内側だから確認しない」、auto モードは「自動判定のモデルが安全と判断したから確認しない」という違いがあります。両方を有効にすると、auto モードではサンドボックス内のコマンドの通信先をコマンドごとに申告させ、自動判定のモデルがそれを一緒に審査します（バージョン 2.1.271 以上）。申告したホストはそのコマンドの実行中だけ開き、セッションや設定ファイルには残りません。

書き込み先・通信先を調整する設定

ツールが作業フォルダの外に書く必要があるなら allowWrite、通信先を足すなら allowedDomains、どうしても中で動かないツールだけを excludedCommands で外に出します。 広く外に出すほど守りが弱くなるので、できるだけ狭い設定から試します。

書き込み先を足す：allowWrite

kubectl・terraform・npm などが作業フォルダの外に書き込む必要がある場合は、そのパスだけを許可します。

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

~/.kube はホームフォルダからの相対パス、/tmp/build は絶対パスです。権限ルールの Read(...)・Edit(...) では絶対パスを // で始めますが、サンドボックスのパスは普通の書き方をする点が異なります。複数の設定ファイルに同じリストがある場合は、置き換えではなく合算されます。

読ませたくないものを指定する：denyRead と credentials

初期設定では認証情報のファイルも読めるので、守りたいものは明示します。次の例は、AWS の認証情報ファイルと SSH のフォルダを読めなくし、GITHUB_TOKEN と NPM_TOKEN をサンドボックス内のコマンドの環境変数から外します。

{
  "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" }
      ]
    }
  }
}

組み込みの「読ませない一覧」は無く、書いたものだけが制限されます。ホームフォルダ全体を読ませず、プロジェクトだけを読ませたい場合は、プロジェクトの .claude/settings.json に "denyRead": ["~/"] と "allowRead": ["."] を書く方法が公式に紹介されています。ユーザー設定に同じことを書くと、. が ~/.claude を指してしまい、プロジェクトが読めなくなる点に注意してください。

通信先を足す：allowedDomains

よく使うドメインを先に許可しておくと、確認が出なくなります。

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

広いドメインほど持ち出し経路にもなりうるので、必要なものだけにします。確認を出さずに許可リスト外を一律に断りたい場合は strictAllowlist を使います（2.1.219 以上。ユーザー設定・管理設定・--settings で有効で、リポジトリの設定ファイルでは効きません）。

どうしても中で動かないツール：excludedCommands

中で動かないツールは、コマンドのパターンを excludedCommands に書くと、サンドボックスの外で動きます。

{
  "sandbox": {
    "enabled": true,
    "excludedCommands": ["docker compose *"]
  }
}

ここに書いたコマンドは、ファイルの制限も通信の制限もない、利用者と同じ権限で動きます。書くときの注意は次のとおりです。

• パターンは権限ルールの Bash(...) と同じ書き方で、末尾に * を付けないと引数なしの完全一致になります
• 1回の実行に含まれるすべてのコマンドが当てはまらないと外に出ません。npm ci && docker compose build は、npm ci も書いていなければサンドボックス内のままです
• cd を含む実行、$(...) などのコマンド置換、ファイルへのリダイレクトがあると、全体がサンドボックス内に残ります
• docker * のような広いパターンは、そのツールができることすべてを外に出します。Claude が作業フォルダの compose ファイルを書き換えてから外で実行する、ということも起こりえます

公式ドキュメントは、1つのフォルダや1つのホストが足りないだけなら、excludedCommands ではなく allowWrite や allowedDomains で済ませ、サンドボックス内に残すことを勧めています。

うまく動かないときの対処

サンドボックスの外では動くのに中では失敗するコマンドは、多くの場合、通信先の許可か excludedCommands で解決します。 公式ドキュメントに載っている主な症状と対処をまとめます。

社内のプロキシを通さないと外に出られないネットワークでは、HTTPS_PROXY・HTTP_PROXY・NO_PROXY を設定ファイルの env か、Claude Code を起動する環境に設定します。Claude Code は許可リストで確認したうえで、許可した接続を社内のプロキシに通します。

会社で使うときに固定する設定

会社全体でサンドボックスを必ず使わせるには、管理設定（managed settings）で enabled・failIfUnavailable・allowUnsandboxedCommands の3つを配ります。 管理設定は、MDM で配るファイルか、claude.ai のサーバー側の管理設定で届けます。公式ドキュメントが示す例は次のとおりです。

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

この3つで、サンドボックスを有効にし、使えない環境では起動させず、失敗したコマンドを外でやり直すことも禁止します。あわせて、次の点を決めておくと運用が安定します。

• 会社として認めるツールの excludedCommands は管理設定に書く：この構成では、リポジトリの .claude/settings.json・.claude/settings.local.json に書いた excludedCommands や allowedDomains、allowWrite などの「緩める設定」が無視されます（2.1.285 以上）。取り込んだリポジトリが勝手にコマンドを外に出せないようにするためです
• 認証情報のフォルダを sandbox.credentials で守る：初期設定では ~/.aws や ~/.ssh が読めるので、管理設定で deny を配ります
• 通信先を会社の一覧に固定するなら allowManagedDomainsOnly：管理設定にあるドメインと WebFetch(domain:...) のルールだけが有効になり、それ以外は確認なしで拒否されます
• Windows の端末の扱いを決める：failIfUnavailable を入れると、サンドボックスに対応しない Windows でそのまま動かす Claude Code は起動しなくなります。WSL2 での利用に統一するか、コンテナや VM を使うかを決めておきます

この構成でも、利用者が入力欄の ! から自分で打つコマンドは、ほとんどのセッションでサンドボックスの外で動きます。これは、利用者がふだんターミナルで持っている権限と同じ範囲です。

導入にあたっての法務・情報システム部門の観点や、権限設計の全体像は Claude Code のセキュリティと社内導入で整理しています。

よくある質問

まとめ

• Claude Code のサンドボックスは、Claude が実行するシェルコマンドとその子プロセスを、ファイルとネットワークの2つの壁で OS が制限する機能です。初期設定では無効で、/sandbox か sandbox.enabled で有効にします
• 対応は macOS・Linux・WSL2 です。Linux と WSL2 は bubblewrap と socat が必要で、Windows では WSL2 の中で使います
• 初期設定では、書き込みは作業フォルダ・一時フォルダ・足したフォルダまで、読み取りはほぼ全体、通信は許可したドメインだけです。認証情報のファイルは自分で credentials や denyRead で守ります
• ファイル編集ツール、MCP サーバー、hooks、! で打ったコマンドは対象外です。Claude Code ごと閉じ込めたいなら、sandbox-runtime・コンテナ・VM を使います
• 実機でも、ホームフォルダへの書き込みと許可していない通信は拒否され、一時フォルダへの書き込みと許可したホストへの通信は通りました
• 会社で使うなら、管理設定で enabled・failIfUnavailable・allowUnsandboxedCommands: false を配り、認めるツールの excludedCommands と認証情報の保護も管理設定に書きます