[BUG] Cloud sessions: egress gateway returns "no rule or allowlist entry allows host" for allow-listed hosts since 2026-10-10
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Since 2026-10-10 (worked until 2026-10-09, config unchanged), Claude Code cloud sessions in my environment "Default" get 403 from the egress gateway on CONNECT for every host except github.com, including hosts that are in the default package-manager list and hosts explicitly added to the environment's allowed domains.
Environment "Default" network access: Custom; allowed domains huggingface.co, .huggingface.co, .hf.co; "include default package manager list" checked. Not modified since it worked.
Blocked (same body for all): registry.npmjs.org, pypi.org, files.pythonhosted.org, registry-1.docker.io, nodejs.org, huggingface.co, cdn-lfs.hf.co, and even the environment's own telemetry host http-intake.logs.us5.datadoghq.com.
Allowed: github.com:443 → 200 Connection Established.
The "no rule or allowlist entry" text on in-list apex hosts suggests the session's egress ruleset is empty or not applied, rather than a missing domain.
What Should Happen?
Hosts in the default package-manager list and in the environment's allowed domains should be reachable through the egress proxy, as they were until 2026-10-09.
Error Messages/Logs
> CONNECT registry.npmjs.org:443 HTTP/1.1
< HTTP/1.1 403 Forbidden
< Content-Type: text/plain; charset=utf-8
< Content-Length: 76
request blocked: no rule or allowlist entry allows host "registry.npmjs.org"
Agent proxy status (recentRelayFailures):
{"kind":"connect_rejected","detail":"gateway answered 403 to CONNECT (policy denial or upstream failure)","host":"registry.npmjs.org:443"}
claude doctor:
Organization policy: Loaded from api.anthropic.com
Managed settings (remote): not fetched — not available in sandboxed sessions
(no warning about ignored allowed domains)Steps to Reproduce
- Start a Claude Code cloud session (claude.ai/code) in environment "Default" (Custom network access, default package manager list included, huggingface.co added).
- In the session run: curl -v https://huggingface.co/ (or any host in the default package-manager list via the proxy)
- Observe: CONNECT tunnel failed, response 403, body "request blocked: no rule or allowlist entry allows host ...".
- Run: curl -v https://github.com/ → works.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown exact version; worked until 2026-10-09 in the same cloud environment
Claude Code Version
2.1.296 (Claude Code), commit fdb6c17a97b6
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Non-interactive/CI environment
Additional Information
CLAUDE_CODE_REMOTE_ENVIRONMENT_TYPE=cloud_default
Session IDs: cse_01Cq5WuGpERtUbtwRDyjmJg1 (2026-10-11 07:55 UTC), cse_01Sd4cXq5PAVj96joe9KfcBA (07:18 UTC).
First failure seen: 2026-10-10 ~16:28 UTC. Still reproducing on 2026-10-11 09:06 UTC.
registry.npmjs.org, pypi.org and files.pythonhosted.org are also in NO_PROXY, and direct DNS resolution fails ("Could not resolve host"), so they fail both ways.
3 Comments
Your logs identify two different failure paths: the proxy rejects CONNECT with 403 before an origin HTTP response, while the NO_PROXY path fails name resolution. Keep those separate in the repro; changing certificate verification would not explain a CONNECT policy rejection. For a compact comparison, use the same harmless URL with a short timeout, once explicitly through the configured proxy (override NO_PROXY for that one command only), then through the existing direct path, with github.com as the working control. Record UTC time, session/environment identity, CONNECT host:port and the exact response, redacting proxy credentials and tokens from verbose output. A fresh session using the same unchanged environment can help distinguish stale session policy from an environment-wide failure. Your explicit apex-host failures are useful evidence, but they do not by themselves prove the ruleset is empty. I would attach that matrix to support rather than broadening the allowlist or enabling unrestricted access as a workaround.
Thanks — here is the matrix you suggested, from two sessions on the same unchanged environment. Same harmless URL per host, --max-time 8, once explicitly through the configured proxy (NO_PROXY emptied for that command only) and once direct. No proxy credentials appear in the output (the proxy is local, http://127.0.0.1:<port>).
Session A (long-running): cse_01Sd4cXq5PAVj96joe9KfcBA, cloud_default, claude 2.1.296 — 2026-10-11T09:37:31Z
Session B (fresh, created just for this): cse_014udj9rrrZ7Gn18n3MrYsWm, cloud_default, claude 2.1.296 — 2026-10-11T09:42:01Z
Both sessions give identical results:
| host:port | via proxy | direct (--noproxy '*') | raw CONNECT to proxy |
|---|---|---|---|
| registry.npmjs.org:443 | (56) CONNECT tunnel failed, response 403 | (6) Could not resolve host | 403 — request blocked: no rule or allowlist entry allows host "registry.npmjs.org" |
| pypi.org:443 | (56) CONNECT tunnel failed, response 403 | (6) Could not resolve host | 403 — same body, host "pypi.org" |
| huggingface.co:443 | (56) CONNECT tunnel failed, response 403 | (6) Could not resolve host | 403 — same body, host "huggingface.co" |
| github.com:443 | tunnel opens; origin answers HTTP 400 on / and 403 on /robots.txt | (6) Could not resolve host | 200 Connection Established |
Notes:
Still reproducing on 2026-10-15, 12:18 to 12:40 UTC, on a scheduled cloud session. One datum that narrows it past the matrix above, where the control was github.com only:
The allowlist is not empty, it is just narrow, and the refusals are per host. In the same shell, in the same minute:
| host:port | result |
|---|---|
|
api.browserbase.com:443|connect_rejectedx16 in a single command, plus onews_error|| a self-hosted CDP host on a bare-IP hostname |
connect_rejectedx3 ||
chat.googleapis.com:443| tunnel opens, origin answers HTTP 404 ||
oauth2.googleapis.com:443| tunnel opens, origin answers HTTP 404 |So this is not name resolution and not a dead ruleset: two third-party Google hosts pass CONNECT while a third-party vendor API and a self-hosted host are refused by policy. MCP connectors were unaffected throughout, since they tunnel through a different proxy.
The reason this is worth more than a workaround note: from inside the session the refusal is indistinguishable from an expired credential. Every script built on that vendor's SDK dies with
which reads as a signed-out login, and the obvious next move is to go and re-authenticate something that was never broken. Surfacing the refusing rule in the error body that reaches the client, or letting
__agentproxy/statusbe queried per host before the attempt, would remove that misdiagnosis entirely.The same two host families have been refused on this environment on every run for over a week, and the environment is the one configured with the credentials for that vendor, so the credential and the reachability are configured in two places that disagree.