Cloud sessions: GitHub gate overrides "Full" network access — anonymous public-repo API/HTML reads 403, user Authorization headers swallowed

Summary

In Claude Code on the web (cloud sessions), the egress proxy special-cases GitHub and overrides the environment's network policy. A custom environment is configured with Network access: Full — "Unrestricted internet access for maximum flexibility." Despite that:

1. Anonymous, read-only requests to api.github.com for public repos not attached to the session are 403'd with a repo-scoping policy message.
2. Even plain public HTML pages on github.com are 403'd — fetching https://github.com/anthropics/claude-code/issues (this very issue tracker) returns the proxy's policy JSON, not GitHub.
3. User-supplied Authorization headers are intercepted and discarded. Sending an explicit Authorization: Bearer <token> to api.github.com still yields the same 403 policy JSON — the proxy substitutes its own scoped credential handling instead of forwarding the request as sent (or at least failing transparently). Injecting/replacing auth on requests the user authored, then failing them, makes debugging actively misleading: tools report "GitHub is down/permission denied" when neither is true.
4. Meanwhile — same session, same hosts — git ls-remote, shallow clones of arbitrary public repos, and github.com/<owner>/<repo>/releases/download/... asset downloads all pass through fine.

So the block is not protecting anything: the identical bytes are reachable over the git protocol and the download endpoints. It just breaks every ordinary tool that speaks the REST/GraphQL API read-only — release-version resolvers, gh api, action updaters, anything checking releases/latest — inside an environment the user explicitly configured for unrestricted egress.

Reproduction (from inside a cloud session, environment network access = Full)

$ curl -sS https://example.com -o /dev/null -w '%{http_code}\n'
200                                      # network policy is genuinely "Full"

$ curl -sS https://api.github.com/repos/rhysd/actionlint/releases/latest
{"message":"GitHub access to this repository is not enabled for this session. Use add_repo to request access. ...","documentation_url":"https://docs.anthropic.com/en/docs/claude-code/github-actions"}

$ curl -sS -H "Authorization: Bearer <valid-or-not, irrelevant>" \
    https://api.github.com/repos/rhysd/actionlint -o /dev/null -w '%{http_code}\n'
403                                      # user's own auth header is not forwarded

$ curl -sS "https://github.com/anthropics/claude-code/issues" 
{"message":"GitHub access to this repository is not enabled for this session. ..."}   # public HTML page!

$ git ls-remote --tags https://github.com/rhysd/actionlint | head -1
9af83da01dd0b5e50c1a4d8a6d0b581e46907a9a        refs/tags/v1.6.13    # git protocol: fine

$ curl -sSLO https://github.com/rhysd/actionlint/releases/download/v1.7.7/actionlint_1.7.7_linux_amd64.tar.gz
# downloads fine

The proxy status endpoint confirms no domain filtering is active ("selective": false); the gating is exclusively the GitHub credential-scoping layer.

What I expect

• Network access: Full should mean full. For repos not attached to the session, requests to api.github.com / github.com should pass through anonymously — no injected credential, no gating. Anonymous public-repo reads need no token and leak nothing.
• Never silently swallow a user-supplied Authorization header. If the managed token must not be used for a host, forward the request as the tool sent it (or unauthenticated) — don't intercept, replace, and 403.
• Keep the scoped-credential injection exactly as it is for attached repos and for the write path. The containment design there is sound and I'm not asking to weaken it. The problem is only that the gate is host-wide instead of credential-wide.

To be clear about tone: the credential isolation itself is good engineering. But a gate that blocks an unauthenticated GET /repos/x/y/releases/latest — and the public issues page of this very repo — while happily serving the same repo over git clone is not a security boundary, it's a paper wall with a "wrong door" sign 😂 yes, this was claude, and it overrides an explicit user configuration while doing it.

Related issues (instances of the same scoping model over-reaching)

• #78277 — web session on a fork can't read upstream's public issues via the repo-scoped API; add_repo refuses cross-owner adds
• #81509 — let cloud sessions comment on public repos the user cannot push to
• #85456 — sandbox proxy blocks specific git/API operations asymmetrically
• #84581 — Cowork cloud sessions cannot access any GitHub repository

Environment

• Claude Code on the web (claude.ai/code), custom cloud environment, Network access: Full
• Observed 2026-08-15; proxy status: "selective": false, gitConfigInjection: false, gitSshRewrite: false