[BUG] Cloud sessions: WebFetch surfaces egress-policy denials as bare 403s — and the allowlist blocks claude.com itself

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet

(#13718 reported the same surface symptom; it was never diagnosed and
was closed by its author when his repro faded, with an explicit
invitation to file a successor with a specific example — this is that,
with the mechanism identified)

• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (cloud)

What's Wrong?

In Claude Code on the web (claude.ai/code), WebFetch failures caused by the
environment's egress network policy are surfaced as bare 403s,
indistinguishable from an upstream server refusing the request. The
container's own proxy documentation (/root/.ccr/README.md) explicitly
distinguishes this class — "403/407 from the proxy: the destination host is
not allowed by your organization's egress policy… Do not retry" — but the
WebFetch tool result carries none of that, so the agent burns turns
retrying, hunting mirrors, and mis-diagnosing.

Concrete same-session A/B repro (2026-07-03):

• WebFetch https://claude.com/blog/memory → HTTP 403 (also with www.)
• WebFetch https://code.claude.com/docs/en/memory → works

That first URL is Anthropic's own product blog: the session was trying to
verify a memory-feature claim against Anthropic's own announcement and was
blocked by Anthropic's own default proxy policy. The user had to paste the
page contents manually. (Reddit and mirror hosts were likewise blocked at
the proxy — connections never establish — which is defensible policy, but
gets reported identically to a site-side refusal.)

What Should Happen?

Two separable fixes:

1. Allowlist: include Anthropic's own public domains (claude.com,

www.claude.com, anthropic.com) in the default cloud network policy,
alongside the already-allowed code.claude.com.

1. Error clarity: when the 403/407 originates at the egress proxy,

say so in the tool error — e.g. *"Blocked by this environment's network
policy (not the destination server). Ask the user to paste the content
or adjust the environment's network settings."* The proxy layer already
knows the difference; the tool result just doesn't carry it.

Error Messages/Logs

The server returned HTTP 403 Forbidden.
The response body was not retrieved. If this URL requires authentication,
use an authenticated tool (e.g. `gh` for GitHub...) instead of WebFetch.

(Note the error text even points toward an authentication problem, which
this is not.)

Steps to Reproduce

1. Start a Claude Code on the web session (default network policy)
2. WebFetch https://claude.com/blog/memory → 403
3. WebFetch https://code.claude.com/docs/en/memory → succeeds
4. WebFetch example.com → 403

<img width="2628" height="1737" alt="Image" src="https://github.com/user-attachments/assets/7987ed2a-03d6-4e2f-b927-93a96e9371c9" />

<img width="2628" height="1737" alt="Image" src="https://github.com/user-attachments/assets/a5e6e236-f97f-4770-a7b9-bc8fe0407299" />

Claude Model

Multiple models

Is this a regression?

I don't know

Claude Code Version

cloud (claude.ai/code), observed 2026-07-03

Platform

Claude Code on the web

Additional Information

Successor to #13718, which had the same surfaced symptom but was
attributed in-thread (via pasted search results, no maintainer engagement)
to upstream bot-blocking. This report isolates a different mechanism —
the environment's own egress proxy — with a stable A/B repro. The
practical cost of the missing distinction: agents retry and route-hunt
policy denials (the exact behavior the proxy README says not to do)
before falling back to asking the user for a paste, which a clear error
would make immediate.