network.strictAllowlistは許可リスト外を拒否にする設定
sandbox.network.strictAllowlistは、許可リスト外のホストへのアクセスをプロンプトなしで拒否に切り替える設定です。書ける場所の制限とfalse時のpermission mode別挙動をまとめました。
Claude Codeのサンドボックスは、既定では許可リストに無いドメインへの接続をプロンプトで確認します。sandbox.network.strictAllowlistをtrueにすると、この確認が消えます。許可リスト外のホストは、聞かれることなくそのまま拒否されます。書ける場所がユーザー設定・managed設定・CLIの--settingsフラグに限られる点と、一度オンにすると誰も戻せなくなる点が、他の設定キーと違う癖です。
strictAllowlistが変えるのは「聞く」か「聞かず拒否」かだけ
サンドボックス化されたBashコマンドが新しいホストへ接続しようとすると、Claude Codeは既定で承認を求めます。「はい」と答えればそのセッション中は接続でき、「はい、今後は聞かない」を選べばWebFetch(domain:...)という許可ルールとして保存され、以後も許可され続けます。ここで参照される「許可リスト」の中身は、sandbox.network.allowedDomainsにあらかじめ書いたドメインと、こうして保存されたWebFetch(domain:...)の許可ルールです。allowManagedDomainsOnlyが有効なときは、managed設定のこの2つだけに絞られます。
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(プロンプトで確認)です。
同じsandbox.network配下には、組織独自のプロキシへ経路を差し替えるhttpProxyPort・socksProxyPortもあります。こちらは通信の行き先ではなく通り道を変えるだけの設定で、許可・拒否の判断自体には関与しません。strictAllowlistと混同しやすいので、役割が別物だと分けて覚えておくと設定を読み違えません。
プロジェクトのsettings.jsonに書いても効かない
strictAllowlistが読まれるのは、ユーザー設定・managed設定・--settingsフラグの3か所だけです。リポジトリの.claude/settings.jsonや.claude/settings.local.jsonに書いても、公式ドキュメントは「効果が無い」と明言しています。チェックアウトしたプロジェクト側の設定だけでこの挙動をオン・オフすることはできません。
これは他の多くの真偽値キーとは仕組みが違います。sandbox.enabledのような一般的なBoolean値は、最も優先度の高いスコープの値を採用する通常の上書き方式です。strictAllowlistはそうではなく、ユーザー設定かmanaged設定のどちらか一方でもtrueにすれば、以後ずっとオンのままになります。管理者がmanaged設定でオンにしていれば、開発者が自分のユーザー設定をfalseに戻しても無効になりません。逆にユーザー自身がオンにした場合も、プロジェクトを移動した先でオフに戻す手段はありません。
falseのままだと挙動はpermission modeで4通りに分かれる
strictAllowlistを設定しない、あるいはどこからもtrueにされていないとき、許可リスト外のホストへの接続をどう扱うかはpermission modeが決めます。
| permission mode | 許可リスト外のホストへの挙動 |
|---|---|
| auto mode | 許可リスト外のホストへの挙動分類器がその都度判定する |
| dontAsk mode | 許可リスト外のホストへの挙動プロンプトを出さず自動で拒否する |
| bypassPermissions mode | 許可リスト外のホストへの挙動確認なしで許可する |
| plan mode(bypassが使える場合) | 許可リスト外のホストへの挙動確認なしで許可する |
| 上記以外(defaultなど) | 許可リスト外のホストへの挙動プロンプトで確認する |
この表が示すとおり、dontAskモードはstrictAllowlist: trueと似た「聞かずに拒否」という結果になります。ただし対象が違います。dontAskはセッションのpermission mode全体を切り替える設定で、Bash・Read・Editなどあらゆるツール呼び出しに及びます。strictAllowlistはサンドボックスのネットワーク層だけに効く、より狭い設定です。strictAllowlistをtrueにした場合は、この表の分岐そのものが働きません。auto modeの分類器やbypassPermissionsモードの判定を経由せず、どのpermission modeでも許可リスト外は一律で拒否されます。分岐が生まれるのはfalseのときだけです。
ここで見落としやすいのが、auto modeを使えばそれだけで安全という思い込みです。auto modeは分類器が個別に判断するのであって、自動的に拒否するわけではありません。分類器が「問題なさそうだ」と判定すれば、許可リストに無いホストへの接続でもそのまま通ります。許可リスト外を確実に拒否させたいなら、auto modeとは別にstrictAllowlistを明示的にtrueにする必要があります。
WebFetchなどサンドボックス外のツールには効かない
strictAllowlistが拘束するのはサンドボックス化されたBashコマンドとその子プロセスだけです。制限はコマンドが起動するスクリプト・プログラム・サブプロセスすべてに及びますが、Bashを経由しない経路までは追いません。WebFetchのようにClaude Codeのプロセス内で動くツールは対象に含まれず、Read・Edit・Writeのような組み込みファイルツールもサンドボックスではなく別の権限システムを直接使います。WebFetchは自分自身のWebFetch(domain:...)許可・拒否ルールに従って動作し続けます。strictAllowlistをtrueにしても、WebFetchが許可リスト外のURLを取得すること自体は止まりません。ネットワークの出口を本気で絞りたい場合は、この2つの制御が別物である前提で両方を確認します。
サブエージェントは親セッションと同じプロセスで動き、同じサンドボックス設定を引き継ぎます。親セッションでサンドボックスが有効なら、サブエージェント内で実行されるBashコマンドも同じstrictAllowlistの対象です。個別のサブエージェント定義だけで緩めることはできません。
もう1つ、TLSの中身までは見ていない点も押さえておく価値があります。既定のサンドボックスプロキシは、接続先のホスト名だけを見て許可・拒否を判断し、HTTPS通信の中身は検査しません。公式ドキュメントは、この仕組み上、domain fronting(TLSのSNIと実際のHTTPリクエスト先を意図的にずらす手法)のような手段で許可リスト外のホストへ実質的に到達できる余地が残ると明記しています。strictAllowlistはホスト名ベースの許可判定を厳格化する設定であって、通信内容そのものを検査するファイアウォールに置き換わるものではありません。TLSの内容まで検査したい場合は、tlsTerminateを設定した独自プロキシを挟む構成が公式の案内です。tlsTerminateもユーザー設定・managed設定からしか有効化できず、v2.1.199以降が必要です。strictAllowlistと書ける場所がそろっているのは偶然ではありません。どちらもプロジェクト側の設定で緩められては困る、強い制御だからです。
隣接するネットワーク設定との役割分担
sandbox.network配下にはstrictAllowlist以外にも似た響きの設定が並びます。どれが何を決めるかを混同すると、意図と違う構成になりがちです。名前が似ている分、レビューの場で「どれを直したのか」が伝わりにくい設定でもあります。
| 設定 | 何を決めるか | 書ける場所 |
|---|---|---|
allowedDomains | 何を決めるかプロンプトなしで許可するドメイン | 書ける場所任意の設定ファイル(managed含む) |
deniedDomains | 何を決めるか常にブロックするドメイン(allowedDomainsより優先) | 書ける場所任意の設定ファイル(managed含む) |
allowManagedDomainsOnly | 何を決めるか許可リストの出所をmanaged設定だけに絞る | 書ける場所managed設定のみ |
strictAllowlist | 何を決めるか許可リスト外を「聞かず拒否」に変える | 書ける場所ユーザー設定・managed設定・--settings |
allowManagedDomainsOnlyを有効にすると、Claude Codeはmanaged設定のallowedDomainsとWebFetch(domain:...)許可ルールだけを許可リストとして扱います。プロジェクトやユーザーが追加したドメインは無視されます。この状態でstrictAllowlistもtrueにすると、許可リストの中身は管理者だけが決め、それ以外のホストは開発者側のどんな設定に関係なく一律で拒否される構成になります。deniedDomainsだけは例外で、allowManagedDomainsOnlyが有効でもすべてのスコープから統合されます。開発者は許可リストを広げられませんが、自分の判断で追加のドメインをブロックすることは引き続きできます。
よくあるつまずき
- sandbox.enabledを付け忘れる:
strictAllowlistだけ書いてもサンドボックス自体が無効なら何も起きません。sandbox.enabled: trueとセットで確認します - プロジェクトのsettings.jsonで制御しようとする: リポジトリ側の設定ファイルからは変更できません。ユーザー設定・managed設定・
--settingsフラグのいずれかに書く必要があります - falseに戻せば解除できると思い込む: managed設定が一度でも
trueにしていれば、ユーザー側でfalseにしても効果はありません。組織のポリシーを個人の設定で緩められない設計です - WebFetchも同時に締まると思い込む: 締まりません。
WebFetchは自分の許可・拒否ルールで別に動きます - auto modeにしておけば十分だと思い込む: auto modeの分類器は個別に判断するだけで、許可リスト外を自動で拒否するわけではありません。確実に拒否させるには
strictAllowlistを明示的にtrueにします
まとめ
sandbox.network.strictAllowlistは、サンドボックス化されたBashコマンドが許可リスト外のホストに触れたとき、プロンプトの代わりに問答無用で拒否へ倒す設定です。ユーザー設定・managed設定・--settingsフラグの3か所でしか書けず、プロジェクト側の設定は無視されます。どこか1か所でもtrueにすれば以後ずっとオンのままで、falseに戻して解除することはできません。効果が及ぶのはサンドボックス化されたBashコマンドだけで、WebFetchのような別系統のツールや、TLSの中身までは制御しません。CI・共有マシン・managed設定でネットワークの許可リストを固定運用したい場面に向く、スコープの狭い設定です。
サンドボックスのファイルシステム層だけを外す設定はsandbox.filesystem.disabledの挙動、allowedDomainsにIPv6アドレスを書くときの書式はIPv6ドメイン許可リストの書き方にまとめています。auto modeがpermission modeとして何を止めるかはauto modeブロック一覧、他のAIコーディングエージェントとサンドボックス実装を比べたい場合はAIコーディングエージェントのサンドボックス実装比較を参照してください。