はじめに
Claude CodeのBashサンドボックス（/sandbox）を有効にすると、kubectl や terraform、社内スクリプトなど作業ディレクトリの外に書き込む必要があるツールが、権限不足で止まることがある。かといってサンドボックスごと切ると、今度は通信先の制限まで失ってしまう。「ファイルの書き込み制限だけ外して、通信の制限は残したい」。そう思ったことがある人は少なくないはずだ。
Claude Code v2.1.216で追加された sandbox.filesystem.disabled は、まさにこの要望に応える設定だ。ただし公式ドキュメントを読むと、設定できる場所が限定されていたり、オフにした瞬間に別の防御まで一緒に外れたりと、単純に「制限を1つ緩めるだけ」ではないことが分かる。加えて、この記事の執筆自体がクラウド実行環境のClaude Codeセッションで行われており、実際に検証してみるとこの設定が「そもそも効かない環境」があることも見えてきた。
この記事で学べること
- Claude CodeのBashサンドボックスが持つ「ファイルシステム分離」「ネットワーク分離」という2層構造
-
sandbox.filesystem.disabledの設定方法と、オフにしたときに何が変わり何が変わらないか - 設定できるスコープが
settings.jsonの置き場所によって制限される理由 - クラウド実行環境（Claude Code on the web）ではこの設定がそもそも対象外になるケース
対象読者
- Claude CodeのBashサンドボックスを既に有効化している、または検討している人
-
kubectl/terraform/npmなど外部ツールがサンドボックスの書き込み制限に引っかかった経験がある人 - 組織でClaude Codeのセキュリティ設定を管理する立場の人
検証環境
- Claude Code on the web（クラウドリモート実行環境・本記事の執筆・検証セッションそのもの）
- 設定・仕様の記述は 公式ドキュメント「Configure the sandboxed Bash tool」 と CHANGELOG.md を一次情報として参照
TL;DR
-
sandbox.filesystem.disabled: trueにすると、ファイルシステム分離だけをオフにし、ネットワーク分離（許可ドメイン制御）は維持できる（v2.1.216以降） - この設定は「ユーザー設定」「管理者設定」「
--settingsCLIフラグ」からしか有効化できない。プロジェクトの.claude/settings.jsonには書けない仕組みになっている - オフにすると
settings.json自体への書き込み拒否ルールやdenyReadの読み取り保護も一緒に外れるため、信頼できないワークロードには使わない - Claude Code on the web（クラウドリモート実行環境）では、この設定が前提とするローカルのBashサンドボックス機構（macOS Seatbelt / Linux bubblewrap）自体が動いていないケースがある
背景・課題: サンドボックスの「2層構造」
Claude CodeのBashサンドボックスは、OSの機能（macOSはSeatbelt、Linux/WSL2はbubblewrap）を使って、Bashツールとその子プロセスが触れるファイルとネットワーク先を制限する仕組みだ1。この制限は独立した2つの層に分かれている。
-
ファイルシステム分離: デフォルトでは作業ディレクトリとセッション一時ディレクトリ以外への書き込みができない。読み取りはPCのほぼ全体に許可されるが、
denyReadで個別に塞げる -
ネットワーク分離: ローカルプロキシ経由の通信のみ許可され、許可していないドメインへの接続は拒否される。初回はドメインごとに承認を求められ、
allowedDomainsで事前許可もできる
この2層は独立して効くため、片方だけを緩めることが理屈のうえでは可能だ。ところがv2.1.215までは、ファイルシステム分離を外すオプションが用意されておらず、kubectl が ~/.kube に書き込めない、terraform が /tmp 配下の別ディレクトリを使うといった理由でサンドボックス自体を諦めるケースが起きていた。sandbox.filesystem.allowWrite で個別にパスを許可する方法もあるが、書き込み先が動的に変わるツールでは追いつかない。
sandbox.filesystem.disabled の設定
v2.1.216で追加されたのが、ファイルシステム分離だけをまとめてオフにする設定だ。settings.json に以下のように書く。
{
"sandbox": {
"enabled": true,
"filesystem": {
"disabled": true
},
"network": {
"allowedDomains": ["github.com", "*.npmjs.org"]
}
}
}
filesystem.disabled: true にすると、サンドボックス内のコマンドはホストのファイルシステムに無制限で読み書きできるようになる。一方 network.allowedDomains で指定した許可ドメイン以外への通信は、引き続きブロックされる。公式ドキュメントはこの使い分けを「サンドボックスで“何を書けるか”ではなく“どこに繋げるか”を制御したいときにオフにする」とまとめている1。
オフにすると一緒に外れるもの
ファイルシステム分離を切ると、副作用として以下も一緒に外れる。
-
filesystem.denyReadやsandbox.credentials.filesによる読み取り保護（~/.aws/credentialsや~/.sshを塞ぐ設定） - サンドボックス自身の
settings.jsonへの書き込み拒否ルール（通常は、サンドボックス化されたコマンドが自分のポリシーファイルを書き換えられないよう保護されている） - セッション一時ディレクトリへの
$TMPDIRの固定（オフにするとシェルの$TMPDIRをそのまま継承する）
環境変数のマスク（credentials.envVars の deny/mask）だけは、ファイルシステム層と独立しているため引き続き効く。公式ドキュメントは「ファイルシステム分離とコマンドの自動承認を組み合わせた状態でこれを有効にすると、書き込んだファイルが後続コマンドの実行や ~/.claude/settings.json の読み込みを通じて自分自身の権限を広げる経路になりうる」と警告している1。オフにするのは、それをされても問題ないワークロードに限るべき設定ということだ。
どのスコープから設定できるか
もう1つの制約が、設定できる settings.json のスコープが限定されている点だ。
| 設定元 |
filesystem.disabled を書けるか |
|---|---|
ユーザー設定（~/.claude/settings.json） |
書ける |
| 管理者設定（managed settings） | 書ける |
--settings CLIフラグ |
書ける |
プロジェクト設定（.claude/settings.json） |
書けない |
プロジェクトローカル設定（.claude/settings.local.json） |
書けない |
プロジェクト側から書けないようになっているのは、リポジトリをcloneしただけでファイルシステム保護が無効化される事態を防ぐためだ。さらに管理者設定が sandbox.filesystem を何か1つでも設定している場合、あるいは sandbox.credentials.files を1件でも登録している場合は、filesystem.disabled の制御権が管理者設定に一本化され、ユーザー側の上書きも効かなくなる1。組織で配布したファイルシステム保護は、ユーザーが個別に緩めることができない設計だ。
クラウド実行環境ではこの設定が効かないことがある
ここまでは公式ドキュメントに基づく仕様の整理だが、実際に手元の環境で filesystem.disabled を試そうとして、1つ気づいたことがある。本記事はClaude Code on the web（クラウドリモート実行環境）のセッション内で執筆しており、このセッション自身のBashサンドボックス状態を確認してみた。
$ echo "test" > /tmp/sandbox-write-test.txt && echo "WRITE_OK"
WRITE_OK
$ which bwrap
（出力なし。終了コード1＝bwrapコマンドが存在しない）
$ env | grep -i sandbox
IS_SANDBOX=yes
ANT_IMAGE_REPOSITORY=sandbox-ccr-default
/tmp への書き込みは通り、bwrap（bubblewrap）バイナリは見つからなかった。公式ドキュメントが説明するBashサンドボックス（/sandbox コマンドで有効化する機構）はLinux/WSL2ではbubblewrapを前提としており1、それが存在しないということは、このクラウドセッションはClaude Code CLI自身のファイルシステム/ネットワーク分離機構の対象外にある。IS_SANDBOX=yes という環境変数はあるが、これはコンテナ単位の外側の隔離（ANT_IMAGE_REPOSITORY という値からも読み取れる）を示すものであって、sandbox.filesystem.disabled が制御する「Bashツールごとの二層分離」とは別のレイヤーだ。
つまり sandbox.filesystem.disabled はローカルで動くClaude Code CLI（macOS / Linux / WSL2）向けの設定であり、Claude Code on the webのようにセッション全体が1つのコンテナで隔離されている実行環境では、そもそも設定する対象のサンドボックス機構が存在しない。この違いは公式ドキュメントの「Scope」セクションにも直接書かれてはおらず、実機で env と which bwrap を確認して初めて分かった。ローカルCLIとクラウド実行環境を併用しているチームは、セキュリティ設定を検討する際にどちらの実行形態を想定しているかを先に切り分けたほうがよい。
実務での使いどころ
ここまでの整理を踏まえると、filesystem.disabled を使う場面は次のように絞り込める。
- ローカルのClaude Code CLIで、
kubectl/terraform/ 自社CLIなど書き込み先が予測しづらいツールを頻繁に動かしていて、allowWriteの個別追加が追いつかない場合 - 一方で、通信先だけは
allowedDomainsで確実に絞りたい場合（社内レジストリ・特定のクラウドAPIのみ許可、といったポリシー） - そのワークロードが「サンドボックス内のコマンドが自分の権限を書き換えて広げにいく」ことを心配しなくてよい、信頼できる作業である場合
逆に、書き込み先を予測できないコード（外部から取得したスクリプトの実行など）を動かす場合や、複数人がプロジェクトを共有していて設定を統一したい場合は、filesystem.disabled に頼らず sandbox.filesystem.allowWrite で個別にパスを許可するか、管理者設定でポリシーを固定したほうが安全域を保てる。
まとめ
- v2.1.216の
sandbox.filesystem.disabledは、Bashサンドボックスのファイルシステム分離だけを外し、ネットワーク分離は維持できる設定 - オフにすると読み取り保護と
settings.jsonの書き込み拒否も一緒に外れるため、信頼できるワークロード限定で使う - プロジェクト設定からは書けず、ユーザー設定・管理者設定・CLIフラグからのみ有効化できる。管理者設定が絡むと上書きも封じられる
- Claude Code on the webのようなクラウド実行環境では、この設定が前提とするローカルのBashサンドボックス機構（bubblewrap等）自体が存在しないことがある。設定を検討する前に、自分が使っているのがどちらの実行形態かを確認したほうがよい
Claude Code(138.9kスター・22.3kフォーク、GitHubリポジトリより・2026-07-24時点)は月次でこうした細かい権限まわりの調整を重ねており、サンドボックス設定だけでも allowRead / denyWrite / credentials.mask など組み合わせの選択肢が増え続けている。自分の実行環境がローカルCLIかクラウドセッションかを踏まえたうえで、必要な層だけを選んで緩める設計が現実的だ。
参考リンク
- Configure the sandboxed Bash tool（Anthropic公式ドキュメント。設定例・警告事項の一次情報）
- claude-code CHANGELOG.md（バージョンごとの変更点）
- anthropics/claude-code（GitHubリポジトリ）