[DOCS] Undocumented built-in allowlist bypasses WebFetch `deny` rules
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.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗