network.strictAllowlistは許可リスト外を拒否にする設定
sandbox.network.strictAllowlistは、許可リスト外のホストへのアクセスをプロンプトなしで拒否に切り替える設定です。書ける場所の制限、効く範囲、falseのときのmode別挙動を解説します。
Claude Codeのサンドボックスは、既定では許可リストに無いドメインへの接続をその場で確認します。sandbox.network.strictAllowlistをtrueにすると、この確認が消えます。許可リスト外のホストは、聞かれることなくそのまま拒否されます。
他の設定キーと違う癖が3つあります。書けるのはユーザー設定・managed設定・CLIの--settingsだけです。一度オンになると誰も戻せません。さらに、効くのはサンドボックス化されたBashコマンドの通信だけで、独自プロキシを指定した通信やWebFetchは対象外です。
「聞かれる」のをやめさせたいとき: strictAllowlistが変えること
サンドボックス化されたBashコマンドが新しいホストへ接続しようとすると、Claude Codeは既定で承認を求めます。「はい」と答えればそのセッション中は接続でき、「はい、今後は聞かない」を選べばWebFetch(domain:...)という許可ルールとして保存されます。ここでいう許可リストは、sandbox.network.allowedDomainsに書いたドメインと、保存されたWebFetch(domain:...)の許可ルールの合計です。
strictAllowlistがtrueのとき、この許可リストに無いホストへの接続は、選択の余地なく拒否されます。プロンプトも分類器の判定も挟みません。
sandbox.network.deniedDomainsに列挙したドメインは、strictAllowlistの設定に関係なく常にブロックされます。広いallowedDomainsのワイルドカードに一致していても、deniedDomainsが優先されます。
設定の書き方とバージョン要件
設定はネストしたJSONで、ユーザーの~/.claude/settings.jsonかmanaged設定に書きます。
{
"sandbox": {
"enabled": true,
"network": {
"allowedDomains": ["github.com", "*.npmjs.org"],
"strictAllowlist": true
}
}
}strictAllowlistにはClaude Code v2.1.219以降が必要です。sandbox.enabledがtrueでなければ、サンドボックス化されたコマンド自体が存在しないため、この設定は何も変えません。既定値はfalseです。
ファイルを書き換えずに試すなら、--settingsにJSON文字列を渡せます。v2.1.287のclaude --helpでは、このフラグは次のように表示されます。
claude --help | grep -A1 -- "--settings <"
# --settings <file-or-json> Path to a settings JSON file or a JSON
# string to load additional settings from<file-or-json>とあるとおり、ファイルパスとJSON文字列のどちらも渡せます。サンドボックスの公式ドキュメントにもclaude --settings '{"sandbox": {...}}'の形の例があります。--settingsはstrictAllowlistを読む3か所のうちの1つなので、一時的にオンにして挙動を見る用途に向きます。
どこに書くと効くのか
strictAllowlistが読まれるのは、ユーザー設定・managed設定・--settingsフラグの3か所だけです。リポジトリの.claude/settings.jsonや.claude/settings.local.jsonに書いても、効果はありません。チェックアウトしたプロジェクト側の設定だけで、この挙動をオン・オフすることはできません。
仕組みも一般的な真偽値キーとは違います。sandbox.enabledのような値は、優先度の高いスコープの値が採用される上書き方式です。strictAllowlistは、どこか1か所の信頼できる設定がtrueにした時点で、以後ずっとオンのままになります。
書く場所ごとの効き方
managed設定
管理者が
trueにすると、開発者が自分のユーザー設定をfalseに戻しても無効になりません。ユーザー設定と --settings
自分で
trueにした場合も、他の設定ファイルのfalseでは戻りません。--settingsはセッションの起動時に渡します。リポジトリの設定
strictAllowlistを書いても無視されます。加えてv2.1.285以降は、他の設定がtrueのとき、リポジトリ側のallowedDomains・WebFetch(domain:...)の許可ルール・プロキシポートも無視されます。
外部のリポジトリをクローンして使うとき、そのリポジトリが自分の許可ドメインを増やしてstrictAllowlistをすり抜けることはできません。
falseのままだと、挙動はpermission modeで分かれる
strictAllowlistを設定しない、またはどこからもtrueにされていないとき、許可リスト外のホストをどう扱うかはpermission modeが決めます。
falseのときのpermission mode別の扱い
聞かずに通す・拒否する
bypassPermissionsと、bypassが使える対話ターミナルのplan mode: 許可dontAsk: 拒否
確認が入る・コマンド単位で判定
- 手動(default)・
acceptEdits・上記以外のplan mode: プロンプトで確認 - auto mode: コマンド単位のホスト一覧を分類器が審査(下の節)。承認されなければ拒否
dontAskはstrictAllowlist: trueと同じ「聞かずに拒否」になりますが、対象が違います。dontAskはセッション全体のpermission modeで、確認が必要になるツール呼び出しを、Bashに限らずすべて拒否します。strictAllowlistはサンドボックスのネットワーク層だけに効く、狭い設定です。
strictAllowlistをtrueにすると、上の分岐そのものが働きません。公式ドキュメントによると、strictAllowlistとallowManagedDomainsOnlyのどちらかがオンなら、組み込みのサンドボックスプロキシはどのpermission modeでも許可リスト外を拒否します。bypassPermissionsmodeでも同じです。
auto modeを選べば安全、とは言えない理由
auto modeでは、Claudeがコマンドごとに「このコマンドにはregistry.npmjs.orgが要る」と一覧を付け、分類器がコマンドと一緒にその一覧を審査します。承認されれば、許可リストに無いホストにそのコマンドの実行中だけ接続できます。セッションの許可リストや設定には何も追加されず、次のコマンドはまた自分で一覧を付けます。
つまりauto modeは、自動で拒否する仕組みではなく、コマンドごとに許可を判定する仕組みです。許可リスト外を確実に拒否させたいなら、strictAllowlistをtrueにします。trueのとき、Claude Codeはコマンド単位の一覧そのものを拒否します。
trueでも止まらない通信
strictAllowlistが拘束するのは、サンドボックス化されたBashコマンドと、そのコマンドが起動する子プロセスの通信です。止まらない経路が3つあります。1つ目と2つ目は次の2枚です。
strictAllowlist: trueでも止まらないもの
WebFetchなどプロセス内のツール
WebFetchは自分のWebFetch(domain:...)許可・拒否ルールに従い続けます。許可リスト外のURLを取得することを、strictAllowlistは止めません。
独自プロキシに向けた通信
httpProxyPort・socksProxyPortを設定すると、そのプロキシ宛ての通信にはClaude Code側のallowedDomains・deniedDomains・strictAllowlist・承認プロンプトが適用されなくなります。フィルタはプロキシ自身が担います。
3つ目はTLSの中身です。既定のサンドボックスプロキシは、クライアントが名乗るホスト名だけで許可・拒否を決め、HTTPS通信の中身は見ません。このためdomain fronting(TLSのSNIと実際のリクエスト先をずらす手法)など、許可リスト外のホストへ到達する余地が残ると明記されています。github.comのような広いドメインを許可すると、情報持ち出しの経路にもなりえます。
TLSの内容まで検査したい場合の案内は、TLSを終端して通信を検査する独自プロキシを自前で用意し、そのCA証明書をサンドボックス内にインストールする構成です。network.tlsTerminateは別の用途の実験的設定で、組み込みプロキシにTLSを終端させますが、公式の説明ではmaskによる認証情報の置換のためのもので、内容フィルタリングは追加しません。v2.1.199以降が必要で、書けるのはユーザー設定・managed設定・--settingsだけです。
リポジトリ側から独自プロキシへ経路を替えて許可リストを避ける道も、前掲の「リポジトリの設定」と同じ規則で塞がれています。
サブエージェントは親セッションと同じプロセスで動き、同じサンドボックス設定を引き継ぎます。親でサンドボックスが有効なら、サブエージェント内のBashコマンドも同じstrictAllowlistの対象です。
隣接するネットワーク設定の役割分担
sandbox.network配下には、名前が似た設定が並びます。
| 設定 | 何を決めるか | 書ける場所 |
|---|---|---|
allowedDomains | 何を決めるかプロンプトなしで許可するドメイン | 書ける場所任意(プロジェクト・ローカル設定には制限あり。allowManagedDomainsOnly時はmanagedのみ) |
deniedDomains | 何を決めるか常にブロックするドメイン(allowedDomainsより優先) | 書ける場所任意の設定ファイル |
allowManagedDomainsOnly | 何を決めるか許可リストをmanaged設定の中身だけに絞る | 書ける場所managed設定のみ |
strictAllowlist | 何を決めるか許可リスト外を「聞かず拒否」に変える | 書ける場所ユーザー設定・managed設定・--settings |
httpProxyPort・socksProxyPort | 何を決めるか通信を自前のプロキシへ向ける | 書ける場所任意の設定ファイル(他の設定で制限される場合あり) |
allowManagedDomainsOnlyを有効にすると、managed設定のallowedDomainsとWebFetch(domain:...)許可ルールだけが許可リストになります。ユーザーやプロジェクトが足したドメインは無視され、許可リスト外のドメインは自動でブロックされます。つまりallowManagedDomainsOnlyだけでも「聞かずに拒否」は成立します。strictAllowlistとの違いは、許可リストの出所をmanaged設定だけに絞るかどうかです。
deniedDomainsだけは例外で、allowManagedDomainsOnlyでもすべてのスコープから統合されます。開発者は許可リストを広げられませんが、追加のドメインを自分でブロックすることはできます。
つまずきの切り分け
症状から原因を探すときの目安です。
- 設定したのに許可リスト外へ接続できてしまう: まず
sandbox.enabledがtrueか確認します。次に、通信の経路がWebFetchや独自プロキシでないか、strictAllowlistをリポジトリ側のファイルに書いていないかを見ます allowedDomainsに足したのに拒否される: そのドメインをリポジトリの設定に書いていませんか。ユーザー設定かmanaged設定がstrictAllowlist: trueのとき、v2.1.285以降はリポジトリ側のallowedDomainsが無視されますfalseに戻したのにオフにならない: managed設定かユーザー設定のどこかがtrueのままです。信頼できる設定の1か所でもtrueなら、オンのままです- auto modeなのに、必要なホストへ接続できない:
strictAllowlistがtrueだと、Claudeがコマンドに付けたホスト一覧も拒否されます。必要なホストはallowedDomainsに足します
まとめ
管理者がmanaged設定でtrueにし、allowManagedDomainsOnlyで許可リストの出所も絞れば、開発者側の設定でネットワークの許可を広げる道はほぼ塞がります。
サンドボックスのファイルシステム層だけを外す設定はsandbox.filesystem.disabledの挙動、allowedDomainsにIPv6アドレスを書くときの書式はIPv6ドメイン許可リストの書き方にあります。auto modeが止める操作はauto modeブロック一覧、他のAIコーディングエージェントとの違いはAIコーディングエージェントのサンドボックス実装比較で比べられます。