[BUG] Cowork cloud sandbox: egress allowlist collapses to ~5 hosts despite account setting "All domains"

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?

Every Cowork cloud container provisioned for my account comes up enforcing an egress allowlist of roughly five hosts, even though Settings → Capabilities → Allow network egress → Domain allowlist is set to "All domains" and the UI states "Claude can access all domains on the internet."

All package registries, CDNs, OS repos and general internet hosts are refused with 403 / x-deny-reason: host_not_allowed, so pip install, npm install, apt-get and any outbound HTTP from the session shell are impossible.

Measured allowlist (24 hosts probed from the session shell)

Allowed (5):

api.github.com 200
github.com 400 (reached origin)
codeload.github.com 400 (reached origin)
objects.githubusercontent.com 404 (reached origin)
api.anthropic.com 404 (reached origin)

Denied (19):

raw.githubusercontent.com registry.npmjs.org registry.yarnpkg.com
pypi.org files.pythonhosted.org index.crates.io
proxy.golang.org deb.debian.org archive.ubuntu.com
cdnjs.cloudflare.com cdn.jsdelivr.net fonts.googleapis.com
storage.googleapis.com claude.com docs.claude.com
google.com example.com api.slack.com
semaphore.co

Note that raw.githubusercontent.com is denied while github.com is allowed — an inconsistency no deliberate policy would produce, and evidence the enforced list is not a considered default. This is also far narrower than the ~205-entry list reported in #34690.

The denial is host-scoped, not tool-scoped

• Same curl binary, same flags, one second apart: api.github.com → 200, pypi.org → 403. The tool is not the variable.
• Both network paths are closed. The registries sit in the container's no_proxy list, so a direct request hits the network filter; forcing it back through the proxy yields CONNECT pypi.org:443 → HTTP/1.1 403 Forbidden.
• Proxy status reports selective: false, toolScoped: false, standalone: false.

This worked normally until roughly five hours before the first observation, with no configuration change on my side.

What Should Happen?

With "Allow network egress" enabled and Domain allowlist set to "All domains", the session sandbox should be able to reach any host on the internet. pip install, npm install and outbound HTTPS from the session shell should all succeed.

At minimum, the enforced allowlist should match what the Capabilities UI reports. Currently the UI states "Claude can access all domains on the internet" while the egress gateway enforces roughly five hosts.

Error Messages/Logs

$ curl -sS -o /dev/null -D- -w '\n%{http_code}\n' https://pypi.org/simple/
HTTP/2 403
x-deny-reason: host_not_allowed
content-length: 95
content-type: text/plain

Host not in allowlist: pypi.org. Add this host to your network egress settings to allow access.

--- forcing it back through the proxy instead of the no_proxy direct path ---
$ env -u no_proxy -u NO_PROXY curl -v https://pypi.org/simple/
* Connected to 127.0.0.1 (127.0.0.1) port 41211
* CONNECT tunnel: HTTP/1.1 negotiated
> CONNECT pypi.org:443 HTTP/1.1
< HTTP/1.1 403 Forbidden
* CONNECT tunnel failed, response 403
curl: (56) CONNECT tunnel failed, response 403

--- /__agentproxy/status recentRelayFailures ---
{ "ts": "2026-09-11T02:45:17.639Z",
  "kind": "connect_rejected",
  "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
  "host": "registry.npmjs.org:443" }
{ "ts": "2026-09-11T02:45:17.883Z",
  "kind": "connect_rejected",
  "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
  "host": "pypi.org:443" }

--- practical effect ---
$ pip install --no-cache-dir cowsay
ERROR: Could not find a version that satisfies the requirement cowsay (from versions: none)
ERROR: No matching distribution found for cowsay

$ npm view left-pad version
npm error 403 In most cases, you or one of your dependencies are requesting
npm error 403 a package version that is forbidden by your security policy, or
npm error 403 on a server you do not have access to.

Steps to Reproduce

1. In Settings → Capabilities, confirm Allow network egress is on and Domain allowlist is set to All domains. The UI should read "Claude can access all domains on the internet."
2. Start a new Cowork cloud session. (This must be a session provisioned after any settings change — see the note below.)
3. In that session, run:

curl -sS -o /dev/null -D- -w '\n%{http_code}\n' https://pypi.org/simple/

Expected: 200
Actual: 403 with x-deny-reason: host_not_allowed

An equally good single-command check is pip install cowsay (not preinstalled, so it must hit the network).

Two traps that produce false negatives

• Stale container. The egress policy is stamped onto a container at provisioning and never re-read. A session that was already open when a setting changed keeps the old policy indefinitely, so testing a fix in an existing session will appear to fail. Verify only in a container provisioned after the change.
• Preinstalled package. pip install six returns "Requirement already satisfied" on this image and never touches the network, which makes the block look absent. Always test with a package that is not preinstalled.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Same build (1.52386.0) — worked ~2026-09-10 22:00 UTC

Claude Code Version

Cowork cloud session — Claude desktop 1.52386.0; bundled Claude Code SDK 2.1.266

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment

| | |
|---|---|
| Product | Cowork cloud session (not the local workspace VM) |
| Claude desktop | 1.52386.0 (Electron 44.2.0, Node 24.20.0) |
| Host OS | Windows 11 Pro 25H2, build 26200.8875 |
| Account | Personal plan, not Team/Enterprise; I am the org owner |
| First observed | 2026-09-11 ~02:45 UTC |
| Last known good | ~2026-09-10 22:00 UTC |

Ruled out

| Hypothesis | Evidence against |
|---|---|
| My network / ISP | The same URLs from the host machine (PowerShell Invoke-WebRequest) all return 200 |
| Account setting wrong | Set to "All domains"; the UI confirms unrestricted access |
| Local managed policy | HKLM\SOFTWARE\Policies\Claude and HKCU\SOFTWARE\Policies\Claude do not exist, so coworkEgressAllowedHosts is unset — per the configuration reference, unset means no restriction |
| One bad container | Reproduced on 4 independently provisioned containers |
| Stale session | Persists in containers provisioned minutes earlier |
| GitHub connector | Revoked on both the Claude and GitHub sides, full sign-out/sign-in, new session — still 403 |
| Recent Cowork release | No egress-restricting change in the changelog in the past week |

Also tried, no effect

• Toggling Allow network egress off → save → on → save, then starting a new session
• Full sign-out / sign-in of the desktop app (re-mints the session credential)
• Multiple new sessions and new tasks

Impact

The session shell cannot install a dependency, fetch a file, or call an external API. Only git over HTTPS against GitHub still functions. Web search and fetch are unaffected because they route separately, which masks the problem — chat and research feel completely healthy while every shell operation fails.

Related issues

#34690 is the closest match ("All domains" not reflected in the session proxy JWT), though that report describes a ~205-entry enforced list where mine is ~5. Also related: #38984, #19087, #23818, #30112, #33386, #37970, #30861, #66567.