Claude Codeサンドボックス、ファイルと通信を別々に緩める設定が来た
Claude Code v2.1.216とv2.1.219で追加されたsandbox.filesystem.disabledとsandbox.network.strictAllowlistを検証。ファイル隔離だけ外す設定と、許可リスト外の通信を黙って弾く設定をsettings.json実例つきで解説する。
エンジニアのゆとです。
Claude Codeのサンドボックスに、地味だけど実務ではけっこう効く設定が2つ増えた。sandbox.filesystem.disabled（v2.1.216、7月20日）とsandbox.network.strictAllowlist（v2.1.219、7月24日）。
結論から言うと、これは「サンドボックスを使うか使わないか」の二択だったところに、「ファイル隔離だけ外す」「通信の許可リスト外を黙って弾く」という調整ノブが増えたという話だ。どっちも派手な新機能じゃない。でも、フリーランスで他社のコードベースを触る仕事をしてる身としては、地味な設定変更のほうが刺さることが多い。今回もそのパターンだと思う。
サンドボックスは元々「ファイル」と「通信」の2層構造
前提から整理する。Claude Codeのサンドボックス（Bashツール用）は、公式ドキュメントを読む限り最初から2つの独立したレイヤーでできている。
ファイルシステム隔離。デフォルトでは書き込みが作業ディレクトリとセッションの一時ディレクトリに限定される。読み取りはほぼPC全体に対して許可されてるけど、一部のディレクトリは拒否される（~/.aws/credentialsのような認証情報ファイルはデフォルトだと読めてしまう点は要注意で、ここはsandbox.credentialsで別途塞ぐ設計になってる）。
ネットワーク隔離。デフォルトではどのドメインも事前許可されていない状態で、コマンドが新しいドメインにアクセスしようとするたびにプロンプトで確認を求められる。プロキシがサンドボックスの外側で動いて、リクエストのホスト名を見て通す・通さないを判断する仕組みだ。
この「ファイルか、通信か」を独立に切り替えられるようになったのが今回のアップデートの核心。今までは大枠でオン・オフを切り替えるしかなかった箇所に、片方だけ緩めるという選択肢が公式に用意された。
sandbox.filesystem.disabled — ファイルは自由に、通信だけ縛る
v2.1.216で追加された設定。trueにすると、ファイルシステム隔離だけをスキップして、ネットワーク隔離は維持したまま動かせる。settings.jsonではこう書く。
{
"sandbox": {
"enabled": true,
"filesystem": {
"disabled": true
},
"network": {
"allowedDomains": ["github.com", "*.npmjs.org"]
}
}
}これが刺さる場面は割とはっきりしてる。クライアント案件でリポジトリ全体を読み書きさせたいけど、外部への通信だけは信頼できるドメインに絞りたい、というケース。僕みたいなフリーランスだと「このプロジェクトのファイルはいくらでも触っていいけど、変な外部サービスに勝手にPOSTされるのだけは絶対避けたい」という要望と相性がいい。ファイル隔離を維持したままallowWriteでパスを個別に許可していく手間から解放される。
ただし気をつけたい点が2つある。1つは、この設定はプロジェクトの.claude/settings.jsonや.claude/settings.local.jsonからは効かないこと。ユーザー設定・管理者設定・--settingsフラグからしか有効化できない。つまりチェックアウトしてきたプロジェクト側が勝手にファイル隔離を外すことはできない仕組みになっていて、これは意図的な安全策だと思う。
もう1つは公式ドキュメントにも明記されてる注意点で、ファイル隔離をオフにして自動承認（auto-allow）と組み合わせると、サンドボックス内のコマンドがシェルの起動ファイルや$PATH上の実行ファイル、~/.claude/settings.jsonそのものを書き換えて、次回実行時に自分の権限を広げる余地が生まれる。通信を絞ってても、ローカル環境の中で権限昇格される可能性はゼロにならない。「ファイルは信頼してるプロジェクトだけ」に留めるのが無難だ。
sandbox.network.strictAllowlist — 許可リスト外を「聞く」から「黙って弾く」へ
こっちがv2.1.219（7月24日）の追加分。変更ログの説明をそのまま訳すと「サンドボックス化されたコマンドに対して、許可リスト外のホストをプロンプトなしで拒否する」設定だ。
デフォルトの挙動を思い出してほしい。許可してないドメインに初めてアクセスしようとすると、Claude Codeはプロンプトで「このドメインへのアクセスを許可しますか」と聞いてくる。対話的にターミナルを見ながら作業してるときはこれでいい。Yesと答えればそのセッション中は再度聞かれない。
でも、この「聞く」という挙動そのものが、無人実行では成立しない。GitHub Actionsのようなヘッドレス環境でClaude Codeを走らせてるときに、許可リストに入ってないドメインへのリクエストが発生したら、プロンプトに答える人間がその場にいない。従来はここでフローが止まるか、失敗して終わるかのどちらかだった。
strictAllowlistを有効にすると、この「止まる」を「即座に拒否」に変える。許可リストに入っているドメインは通す、入っていないドメインは黙って弾く。プロンプト待ちで止まることがなくなる代わりに、想定してなかった通信は問答無用でブロックされる。
CI/CDパイプラインや、監視なしで長時間走らせるバッチ処理との相性がいい設定だと思う。逆に、日常的にターミナルの前に座って対話的に使ってる分には、そこまで恩恵を感じる場面は多くない。「誰も答えられないプロンプトを無くす」のが主目的の設定だと理解しておくのが正確そうだ。
1つだけ注意しておきたいのは、strictAllowlistを有効にした状態でMCPサーバーが許可リスト外のドメインに疎通確認しようとすると、そのMCPサーバーが起動直後に落ちて、引きずられる形でClaude Code本体が「process exited with code 1」を返すことがある点だ。エラーメッセージだけ見ると原因が分かりにくいので、心当たりがある人はexit codeの原因切り分け方を先に見ておくと早い。
実際に組み合わせて書くとこうなる
2つを組み合わせた設定例を置いておく。フリーランスが「クライアントのコードは自由に触っていい、でも通信は許可リストに閉じる、CIでも同じ設定で無人稼働させる」という要件を満たすならこの形になる。
{
"sandbox": {
"enabled": true,
"filesystem": {
"disabled": true
},
"network": {
"allowedDomains": ["github.com", "*.npmjs.org", "api.example-client.com"],
"strictAllowlist": true
}
}
}どのスコープのsettings.jsonに書くべきかは設定によって扱いが違う。filesystem.disabledはユーザー設定・管理者設定・CLIフラグからしか効かないので、個人の~/.claude/settings.jsonに置くのが基本になる。設定ファイルのスコープ構造そのものを整理し直したいなら、以前書いた記事を先に読んでおくと迷わない。
どんな人が使うべきか
僕の感覚だと、刺さる人は大きく2パターンに分かれる。
1つ目はフリーランスで受託案件をやってる人。クライアントのプロプライエタリなコードベースに対して、ファイル操作は信頼してフルアクセスさせたいけど、外部への通信経路だけはきっちり管理したい、というニーズは実際によくある。「このリポジトリの中身はいくら触ってもらっても構わないが、契約外のサービスに勝手にデータを送られるのは困る」というのは、クライアント側の担当者に説明しやすい線引きでもある。
2つ目はCI/CDでClaude Codeを無人稼働させてる人。プルリクエストのレビューや自動修正をパイプラインに組み込んでる場合、途中でプロンプト待ちが発生するのはそのまま処理のスタックを意味する。strictAllowlistで「許可リスト外は問答無用でブロック」にしておけば、想定外の通信が起きてもジョブは止まらず、単にその処理だけが失敗する形に倒せる。GitHub Actions連携の設計をもう一段詰めたい人は、こちらの記事も合わせて読んでほしい。
パーミッションプロンプト自体を減らしたい、という文脈で設定を見直してる人にも関係が深い話だ。
セキュリティ的にどう受け止めるか
今回の2つの設定は、どっちも「隔離を強める」方向じゃなくて「隔離を選択的に緩める」方向の変更だ。これをどう捉えるかは人によると思うけど、僕はAnthropicが実運用のパターンに合わせて設計を柔軟にしてきてる、という受け止め方をしてる。全部縛るか全部緩めるかの二択だと、結局「面倒だから全部オフ」を選ぶ人が出てくる。層を分けて選べるようにするのは、むしろ安全側に倒す設計だと思う。
ただし公式ドキュメントの警告はそのまま真に受けたほうがいい。ファイル隔離とネットワーク隔離は「両方揃って初めて意味がある」設計で、ファイルを緩めるなら通信側の許可リストを絞る、通信を緩めるならファイル側を絞る、という対になった判断を必ずセットで考える必要がある。片方だけ緩めて、もう片方は「まあデフォルトのままでいいか」と放置すると、緩めた側から突破されたときに歯止めがなくなる。
認証情報の保護についても、sandbox.credentialsのような周辺設定と合わせて考えるのが筋がいい。鍵管理まわりのAI活用について広く整理した記事も置いてあるので、興味があれば見てほしい。
正直、今回の2設定は「知らなくても致命的に困る」ものではない。でも、クライアントワークやCI運用でサンドボックスの境界線を自分で設計し直したいタイミングが来たとき、この2つのノブがあることを知ってるかどうかで、選べる設計の幅がだいぶ変わる。設定ファイルをいじる前に、まず公式のサンドボックス解説を一度通しで読んでおくのをおすすめする。
