[DOCS] Undocumented built-in allowlist bypasses WebFetch `deny` rules

Resolved 💬 3 comments Opened Jun 2, 2026 by u1f992 Closed Jul 5, 2026

Documentation Type

Missing documentation (feature not documented)

Documentation Location

https://code.claude.com/docs/en/permissions or https://code.claude.com/docs/en/tools-reference

Section/Topic

Permissions / WebFetch domain rules and deny precedence

Current Documentation

The permissions page states that deny always wins:

Rules are evaluated in order: deny → ask → allow. The first matching rule wins, so deny rules always take precedence.

Neither the permissions page nor the Tools reference (WebFetch tool behavior) mentions any built-in, trusted, or default-allowed list of domains.

What's Wrong or Missing?

Claude Code ships a hardcoded built-in allowlist of domains (including github.com/anthropics, code.claude.com, developer.mozilla.org, etc.) that is consulted by WebFetch. URLs matching it (host + path prefix) are fetched even when a user deny rule is set.

For example, with .claude/settings.local.json:

{ "permissions": { "deny": ["WebFetch(domain:github.com)"] } }

github.com/anthropics/* is still fetched (a nonexistent path reaches a 404 rather than being denied), while github.com/torvalds/linux is correctly blocked with WebFetch denied access to domain:github.com. This allowlist is undocumented, and its effect does not match the documented rule that "deny rules always take precedence."

The list can be inspected (Claude Code 2.1.159 / BuildID[sha1]=2eabd56b93310e766961206f003fc2e163ec5f86):

$ strings -n 6 "$(readlink -f "$(which claude)")" | grep -aoE '=new Set\(\["platform\.claude\.com"[^]]{0,90}'
=new Set(["platform.claude.com","code.claude.com","modelcontextprotocol.io","github.com/anthropics","agentskills.io","doc

Suggested Improvement

Document this built-in trusted-domain allowlist and how it relates to deny rules. Ideally on the Permissions page next to the deny → ask → allow precedence note, and/or in the WebFetch tool behavior section. Make clear that the list is built-in (and version-specific), and that user deny rules do not override it.

Impact

Low - Minor confusion or inconvenience

Additional Context

The current allowlist contents are reasonable, and allowing these domains through deny is not itself objectionable.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗