Claude Code WebFetch権限ルール — ドメイン単位の許可設計

Claude CodeのWebFetchツールは、ドメイン単位で許可・拒否を書くWebFetch(domain:...)ルールで細かく制御できます。書き方を誤ると「特定のドメインだけ許可したつもりが全ドメインに広がっていた」「サンドボックス内のcurlには効いていなかった」という食い違いが起きやすく、ここを押さえておくと事故が減ります。

Claude CodeのWebFetch権限ルールでできること

WebFetch権限ルールはsettings.jsonのpermissions.allowまたはpermissions.denyに書く文字列で、対象はリクエスト先のホスト名です。書式は3種類あります。

マッチングは大文字小文字を区別せず、ルール側・ホスト名側の末尾ドットも同一視します(example.com.とexample.comは同じ扱い)。ワイルドカードが先頭の*.または単独の*以外の位置にあるとき、*はドットとドットの間のテキスト1つ分にしかマッチしません。WebFetch(domain:example.*)はexample.orgにはマッチしますが、example.evil.comにはマッチしません(*がevil.comというドットをまたぐ文字列になってしまうため)。攻撃者が取得しうるドメインへ末尾ワイルドカードが広がらないための制約です。

ワイルドカード自体を使うにはClaude Code v2.1.172以降が必要です。

裸のWebFetchとWebFetch(domain:*)は同じではない

どちらも「全URLを対象にする」点は同じですが、allowとdenyそれぞれでの挙動が異なります。

違いの本質は、domain:付きのルールだけがサンドボックスの許可・拒否ドメインリストにも反映される点にあります。裸のWebFetchルールはWebFetchツールの挙動だけを変え、Bashで実行するcurlのようなサンドボックス化コマンドの到達可能ホストには影響しません。

Claudeに自由に取得させつつサンドボックスの許可リストはそのままにしたい場合は、裸のallow形式を使います。

{
  "permissions": {
    "allow": ["WebFetch"]
  }
}

この設定では、Claudeへページ取得を頼むとプロンプトなしで取得します。一方、サンドボックス化されたcurlで許可リスト外のホストへ接続しようとすると、Claude Codeは改めてそのホストの確認を求めます(autoモードでは分類器へ判定が回ります)。裸のルールはホストを許可リストへ追加していないためです。

組み込みの事前承認ドメインは自分のルールとどう共存するか

WebFetchには、権限ルールを何も書いていなくてもプロンプトなしで取得できる、組み込みの事前承認ドキュメントドメイン一覧があります。ManualモードやacceptEditsモードでは、この一覧に載っているドメインと、自分の権限ルールですでに許可・拒否したドメインだけがプロンプトをスキップします。それ以外の未知のドメインは都度確認を求められ、確認プロンプトには3つの選択肢があります。なおallowルールでドメインを許可していても、実際の取得前にはWebFetch側のドメイン安全チェックが別途走るため、許可ルールだけで無条件に取得できるとは限りません。

• Yes: この1回だけ承認する。次に同じドメインへ取得しようとしても再度プロンプトが出る
• Yes, and don't ask again for <domain>: 承認した上で、そのドメインのWebFetch(domain:...)allowルールをそのリポジトリの.claude/settings.local.jsonに保存する。組織がallowManagedPermissionRulesOnlyを設定している場合、この選択肢自体が表示されなくなる
• No, and tell Claude what to do differently: 取得を拒否する

autoモードとbypassPermissionsモードはこのプロンプトを原則スキップしますが、明示的なaskルールがそのドメインに一致する場合は例外としてプロンプトが残ります。逆に、事前承認ドメインであってもdeny ask allowいずれかの明示的なWebFetch(domain:...)ルールを書けば、そちらが優先されます。組み込みの事前承認を上書きして、特定のドキュメントドメインだけ改めて確認させる、あるいは完全にブロックすることもできます。

この事前承認一覧とサンドボックスの許可リストは、どちらの方向にも自動で共有されません。サンドボックス化コマンドはWebFetchの組み込み事前承認ドメインを引き継がないため、curlのようなサンドボックス化コマンドから同じドメインへ確認なしで到達させたいなら、改めてsandbox.network.allowedDomainsかWebFetch(domain:...)ルールに追加する必要があります。逆にWebFetchもサンドボックスの許可リストを参照しないため、サンドボックスや組織のネットワーク許可リストにドメインを追加しても、WebFetch側のプロンプトは止まりません。両方を確認なしで通したいドメインは、両方の設定に個別に書く必要があります。

サンドボックスのネットワーク許可リストとどう連動するか

Claude Codeのサンドボックスは、filesystem isolationとは独立したネットワーク隔離レイヤーを持ちます。サンドボックス化コマンドがどのホストへ到達できるかは、sandbox.network.allowedDomainsの設定と、WebFetch(domain:...)のallowルールを合わせたリストで決まります。逆に特定のホストを明示的に遮断したい場合はsandbox.network.deniedDomainsにドメインを書きます。allowedDomainsはあくまで許可リストであり、到達を止める役割はdeniedDomains側が担います。

既定ではどのドメインも事前許可されていません。サンドボックス化コマンドが未知のドメインへ接続しようとすると、Claude Codeは承認を求め(autoモードでは分類器が判定)、「今後も確認しない」を選ぶとWebFetch(domain:...)のallowルールとしてローカル設定に保存されます。以後のセッションでもそのホストは許可されたままになります。

サンドボックスのドメインリストでは、ワイルドカードは先頭の*.と単独の*の2形式のみが有効です。単独*の利用にはClaude Code v2.1.186以降が必要です。それ以外の位置のワイルドカード(example.*など)はWebFetchツール自体のマッチには使えても、サンドボックス化コマンドの到達可否には影響しません。

組織・チーム運用では2段階の締め方があります。

• strictAllowlist: ユーザー設定・管理設定・CLIの--settingsでtrueにすると、許可リスト外のホストへの接続はプロンプトを出さずに拒否されます(v2.1.219以降)。リポジトリの.claude/settings.jsonや.claude/settings.local.jsonに書いても効果はありません
• allowManagedDomainsOnly: 管理設定でこれを設定すると、許可リスト外のドメインは自動的にブロックされ、管理設定に登録されたallowedDomainsとWebFetch(domain:...)ルールだけが有効になります

どちらもサンドボックス化コマンドにのみ適用され、WebFetchツール自体は権限ルールに従って動きます。IPv6アドレスをドメインリストに書く場合は[::1]のように角括弧で囲む必要があり(ポート指定は[::1]:443)、角括弧付き表記にはv2.1.229以降が必要です。書き方の細かい注意点はIPv6ドメイン許可リストの書き方 — Claude Codeサンドボックスにまとめています。

WebFetchの許可設計を使い分ける

用途別にどの書き方が向くかをまとめます。

ルールの評価順は他の権限ルールと同じく、deny → ask → allowの順で最初に一致したものが採用されます。範囲の広いdenyルールは、範囲の狭いallowルールがあっても優先されるため、WebFetch(domain:*)をdenyに置くと個別のallowルールごと遮断されることに注意してください。

よくあるつまずき

• 裸のWebFetchをdenyしたのにBashのcurlは通ってしまう: 裸のdenyルールはWebFetchツールを消すだけで、サンドボックス化コマンドの到達範囲は変えません。curl側も止めたいならsandbox.network.deniedDomainsに対象ホストを書くか、strictAllowlistを有効にして許可リスト外を丸ごと拒否します
• WebFetch(domain:example.*)が思ったドメインにマッチしない: 末尾以外の位置のワイルドカードは、ドットとドットの間の1区画にしか一致しません。サブドメインをまとめて許可したいなら先頭に*.を置く形に書き換えます
• リポジトリの.claude/settings.local.jsonにstrictAllowlistを書いても効かない: この設定はユーザー設定・管理設定・CLIの--settingsでのみ有効です。リポジトリスコープの設定ファイルに書いても無視されます
• IPv6アドレスを許可リストに書いたのにマッチしない: 角括弧なしの::1:443はアドレスとポートの両方の読み方ができてしまう曖昧な表記です。claude doctorを実行するとSandbox network domain entries have unreliable spellingsという警告で該当エントリーを教えてくれるので、[::1]:443の形に書き直します

よくある質問

WebFetch(domain:*)と裸のWebFetchはどちらが安全ですか

用途によります。Claudeの取得判断だけを自由にしたいなら裸のWebFetchのほうが影響範囲が狭く、サンドボックス化コマンドの到達可能ホストは既存の許可リストのまま維持できます。WebFetch(domain:*)をallowにすると、サンドボックス化コマンドも任意のホストへ到達できるようになるため、意図せず広い許可を与えることになります。

ドメインルールのワイルドカードはいつから使えますか

WebFetchツール自体のマッチにはv2.1.172以降が必要です。サンドボックスのドメインリストで単独*を使う場合はv2.1.186以降、IPv6アドレスを角括弧で書く場合はv2.1.229以降が必要です。

strictAllowlistとallowManagedDomainsOnlyはどちらを使うべきですか

strictAllowlistはユーザー設定・CLIからでも有効化できる個人・チーム向けの締め方です。allowManagedDomainsOnlyは管理設定でのみ有効で、組織側が許可リストを一元管理し、ユーザー側の設定を無視して強制する運用に向きます。両方を同時に使うことも可能です。

サンドボックスの許可リストにドメインを追加すればWebFetchのプロンプトも消えますか

消えません。WebFetchはサンドボックスの許可リストを参照しないため、sandbox.network.allowedDomainsにドメインを追加してもWebFetch単体のプロンプトは残ります。両方で確認なしにしたい場合は、WebFetch(domain:...)のallowルールも別途書く必要があります。

承認済みのドメインはどこに保存されますか

サンドボックス化コマンドの接続確認プロンプトで「今後も確認しない」を選ぶと、Claude CodeはWebFetch(domain:...)のallowルールとして/permissionsからも見えるローカル設定に保存します。以後同じリポジトリ内のセッションではそのホストへの確認は出ません。

まとめ

WebFetchの権限ルールは、domain:付きかどうかでWebFetchツールだけに効くのかサンドボックスの到達範囲まで変わるのかが分かれます。個別ドメインの許可にはWebFetch(domain:example.com)、サブドメインをまとめるなら先頭*.、Claudeの取得判断だけ自由にしたいなら裸のWebFetchallowを使い分けます。組織でホワイトリスト運用を徹底するなら、strictAllowlistやallowManagedDomainsOnlyを管理設定側に置くことで、個々の開発者の設定に依存しない締め方ができます。サンドボックス全体の設計思想はClaude Codeのサンドボックス設計、ルールの一覧管理は/permissionsコマンド、個人・チーム・企業別の実装値はClaude Codeセキュリティ・権限ガイドで扱っています。