[BUG] Allow network egress - All domains' setting not reflected in session proxy JWT

Adding some observations that might help narrow this down:
I'm running Cowork on macOS. A few data points:
Subdomain asymmetry on GitHub:

github.com (main web interface) — accessible via WebFetch ✅
raw.githubusercontent.com — blocked ❌
api.github.com — blocked ❌

This suggests the hardcoded allowlist includes github.com but not its subdomains, which would be consistent with the JWT containing exact hostnames rather than wildcard entries like *.github.com.
Government/public-sector domains blocked:

ontario.ca (Ontario government website, Canada) — blocked ❌

This is a legitimate use case — fetching publicly available government documents and schedules.
Regression note:
I had a scheduled task (running in Cowork) that successfully fetched a page on ontario.ca for several weeks. It stopped working at some point — I don't have the exact date, but this suggests the allowlist may have become more restrictive over time, not less.
Environment: Cowork macOS, April 2026. Network egress set to "All domains" in Admin → Capabilities — this setting has no effect on the proxy behaviour as described in this issue.

Confirming this on Claude Code on the web (cloud sessions, both scheduled routines and manual runs), 2026-08-09. Same root cause, slightly different surface — posting the raw proxy exchange since it differs from the JWT symptom above.

Configuration: Allow network egress enabled, Domain allowlist = All domains, UI states "Claude can access all domains on the internet." Individual (non-Team) account.

Result: every non-package-manager host is rejected at CONNECT.

* Connected to 127.0.0.1 (127.0.0.1) port 37813
* CONNECT tunnel: HTTP/1.1 negotiated
> CONNECT www.litcharts.com:443 HTTP/1.1
> Proxy-Connection: Keep-Alive
< HTTP/1.1 403 Forbidden
< Content-Length: 36
* CONNECT tunnel failed, response 403

The 36-byte body of the CONNECT response (read off a raw socket):

request rejected: host not permitted

Note: in this environment the proxy sends no x-deny-reason header — the denial reason exists only in that body, which makes the failure harder to diagnose than the header-based case described in the original report.

WebFetch surfaces it as:

{"error_type":"EGRESS_BLOCKED","domain":"www.litcharts.com",
 "message":"Access to www.litcharts.com is blocked by the network egress proxy."}

$HTTPS_PROXY/__agentproxy/status corroborates:

{"enabled": true, "port": 37813, "selective": false,
 "recentRelayFailures": [
   {"kind":"connect_rejected","detail":"gateway answered 403 to CONNECT (policy denial or upstream failure)","host":"www.litcharts.com:443"},
   {"kind":"connect_rejected","host":"www.gutenberg.org:443"},
   {"kind":"connect_rejected","host":"wolnelektury.pl:443"}]}

Tested hosts: www.litcharts.com, www.gutenberg.org, wolnelektury.pl — all 403. Control: pypi.org/simple/ returns 200, but only because it sits in NO_PROXY and bypasses the filtering proxy entirely, so it is not evidence of working egress. The effective allowlist appears hardcoded to npm/PyPI/crates/Go/GitHub plus Anthropic domains, regardless of the account setting.

Impact: agents that rely on WebFetch to read primary sources cannot fetch a single one in cloud sessions. WebSearch still works, but returns titles/URLs/snippets only — the pages behind those URLs are unreachable. For any workflow whose correctness depends on reading sources rather than search snippets, unattended cloud runs silently degrade to snippet-based output. In our case this produced a measurable ~12% error rate on checkable claims versus the same pipeline run locally, where WebFetch works normally.

Happy to supply further diagnostics from a cloud session if useful.

Follow-up, ruling out the obvious alternative explanation: the target sites are not blocking the requests.

Same three URLs, same WebFetch tool, run from a local Claude Code session minutes after the cloud test — all three succeed:

| URL | cloud session | local session |
|---|---|---|
| https://www.litcharts.com/lit/hamlet | EGRESS_BLOCKED / CONNECT 403 | 200, page content returned |
| https://www.gutenberg.org/cache/epub/1524/pg1524.txt | EGRESS_BLOCKED / CONNECT 403 | 200, full text returned |
| https://wolnelektury.pl/katalog/lektura/hamlet.html | EGRESS_BLOCKED / CONNECT 403 | 200, metadata returned |

The only variable is the execution environment.

Two further points that rule out site-side blocking on their own:

1. The 403 is answered by the proxy, not the origin. It arrives in response to CONNECT www.litcharts.com:443 sent to 127.0.0.1:37813, i.e. before any TLS handshake with the origin server exists. A remote host cannot answer a CONNECT — that exchange is strictly between client and proxy.
2. The denial text is policy wording, not a WAF/bot page: request rejected: host not permitted, and the harness classifies it as EGRESS_BLOCKED with the message "blocked by the network egress proxy".

For completeness: in the same local session, verification agents fetched dozens of pages from folger.edu, shakespeare.mit.edu, pl.wikisource.org and wolnelektury.pl without a single block — so this is not rate limiting or bot detection against this client either.

Reproducing this on Claude Code web (claude.ai/code), not Windows/Cowork — so the platform:windows label understates the scope. Same symptom, and I was able to trace where the denial actually comes from: it is an upstream gateway, not just the locally-minted JWT.

All of the below is from one session on 2026-08-24, Domain allowlist = All domains, Allow network egress = ON, Additional allowed domains empty. Default claude-code-default environment.

DNS is fine

$ getent hosts example.com
2606:4700:10::ac42:93f3 example.com
2606:4700:10::6814:179a example.com

The sandbox is provisioned with the package-managers-only bypass list

NO_PROXY contains exactly the package-manager hosts and nothing else, while the UI says "Claude can access all domains on the internet":

HTTPS_PROXY=http://127.0.0.1:32825
GLOBAL_AGENT_HTTPS_PROXY=http://127.0.0.1:32825
NO_PROXY=localhost,127.0.0.1,::1,127.0.0.0/8,0.0.0.0/8,::,169.254.0.0/16,
         api.anthropic.com,api-staging.anthropic.com,api-pr-preview.anthropic.com,
         mcp-proxy.anthropic.com,mcp-proxy-staging.anthropic.com,
         registry.npmjs.org,jsr.io,npm.jsr.io,pypi.org,files.pythonhosted.org,
         index.crates.io,proxy.golang.org,host.docker.internal,
         10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10,
         .svc.cluster.local,*.svc.cluster.local

That is the "Package managers only" policy, present in a session whose account setting is All domains.

Hosts on that list work, nothing else does — same session, same second

$ curl -sS -o /dev/null -w "%{http_code}" https://registry.npmjs.org
200

$ curl -sS -o /dev/null -w "%{http_code}" https://example.com
curl: (56) CONNECT tunnel failed, response 403

Not WebFetch-specific

curl fails identically to WebFetch, so this is not a tool-layer issue and there is no in-sandbox workaround. For completeness, the WebFetch form:

{"error_type":"EGRESS_BLOCKED","domain":"example.com",
 "message":"Access to example.com is blocked by the network egress proxy."}

The denial comes from an upstream gateway

GET http://127.0.0.1:32825/__agentproxy/status:

{
  "enabled": true,
  "port": 32825,
  "caBundlePath": "/root/.ccr/ca-bundle.crt",
  "gitConfigInjection": true,
  "gitSshRewrite": true,
  "recentRelayFailures": [
    {
      "ts": "2026-08-24T14:01:49.808Z",
      "kind": "connect_rejected",
      "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
      "host": "example.com:443"
    }
  ]
}

Direct CONNECT against the local proxy:

HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Content-Length: 58
Connection: close

request blocked: no rule or allowlist entry allows host ""

So the local proxy relays and the gateway rejects on policy. Whatever reads the account allowlist at session-provisioning time is not seeing the current value.

Ruled out by test

| Hypothesis | Test | Result |
|---|---|---|
| Setting not actually applied | Re-checked UI before and after | "All domains", persists across logout/login |
| Stale auth token | Full logout and login | Still blocked |
| Warm sandbox reuse | Four separate new sessions after the change | Still blocked |
| Domain-specific policy | example.com, en.wikipedia.org, techcrunch.com, help.openai.com | All blocked |
| Tool-specific | curl from Bash vs WebFetch | Identical 403 |
| DNS | getent hosts | Resolves |
| Scheduled-agent-specific | Plain interactive cloud session | Identical failure |

Session ids from these runs, if useful for tracing: 01RPcBgaGEQNBQYfSTrieYgy, 01Kw9grbEUS8pS8SS5q1gY2q, 01Gci24cjMG2s7itcvuQfXWj.

Impact worth noting: scheduled routines fail green

This also hits scheduled routines, and there it is quiet rather than loud. A research routine whose fetch tool is dead falls back to search-result snippets, exits 0, and commits its report — the routine list shows "6 of 6 succeeded". Mine were degraded for three consecutive weekly runs before anyone noticed, and only because the prompt itself carried a control-fetch check that marked its own findings UNVERIFIED. Without that in-prompt check there is no signal at all: no error, no warning, and output that looks normal.

A related knock-on: any routine instruction of the form "verify against the rendered page before reporting" is currently unsatisfiable, so it either silently skips the check or blocks.

Adding a data point from Cowork on macOS, individual plan, 2026-09-11. Same configuration as the original report: Allow network egress ON, Domain allowlist "All domains," UI confirming "Claude can access all domains on the internet."

My case differs from the ones above in a way that seems worth recording: the package-manager bypass list is also being denied.

In the comments above, hosts in NO_PROXY still work, because they skip the filtering proxy. On my sessions they do not. NO_PROXY has the standard contents (registry.npmjs.org, pypi.org, files.pythonhosted.org, index.crates.io, proxy.golang.org and the Anthropic hosts), and curl does bypass the local proxy for them, but the connection is still intercepted:

api.anthropic.com          404   (reaches the origin)
registry.npmjs.org         403
pypi.org                   403
files.pythonhosted.org     403
index.crates.io            403
proxy.golang.org           403
github.com                 403
example.com                403

Every 403 carries x-deny-reason: host_not_allowed and the body:

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

The interception is transparent rather than via CONNECT. Requesting pypi.org with the local proxy bypassed still terminates TLS against a certificate issued by O=Anthropic; CN=Egress Gateway SDS Issuing CA (production), and the 403 arrives as a normal HTTP/2 response rather than a CONNECT rejection. So the effective allowlist here appears to be the Anthropic API and nothing else, which is narrower than "Package managers only" and narrower than anything selectable in the UI.

Both halves of the session are affected identically: the cloud container and the local Cowork VM on the Mac. That rules out anything local, since the cloud container is a fresh machine with no VM involved.

Ruled out by test: toggling Allow network egress off and back on; two fresh sessions after the change; and a conflicting org policy, since an individual plan has no organization settings page (/admin-settings returns "You don't have access to organization settings").

One timing note that may match the observation above about the allowlist narrowing over time. This worked on 2026-09-10, when a scheduled task of mine made several hundred successful calls to a third-party API, and stopped on 2026-09-11 with no change on my end.

Same here, Max plan, individual account, macOS. My Cowork setup worked for months running on my computer. On 4 September 2026 Anthropic migrated my tasks to the cloud by default (email "Your Cowork tasks are moving to the cloud"). Since then, with "Allow network egress" set to All domains, the cloud sandbox returns "CONNECT tunnel failed, 403" from the proxy for www.google.com, api.hyperliquid.xyz and other ordinary hosts; only the fixed allowlist works. Switching back to "Only on your computer" in Settings > Cowork restores network immediately, so the bug is specific to the cloud environment.

Adding a Team-account reproduction with a dated regression window, which I don't think this thread has yet.

Account type: Team. Org setting: Allow network egress = ON, Domain allowlist = "All domains" ("Claude can access all domains on the internet"). Unchanged before, during and after the failure.

Regression window (UTC)

| Time | State |
|---|---|
| 2026-09-10 22:14Z | Working — 21 consecutive successful HTTPS calls to api.openai.com |
| 2026-09-10 ~22:14–22:40Z | Degrading — 6 × connect_rejected against that same host during the run above; each retried through and succeeded |
| 2026-09-11 02:37Z | Hard fail — same host, same session, same code, no successes |
| 2026-09-11 11:57Z | Still failing; reproduced in a second session |
| 2026-09-11 | Still failing; reproduced in a third brand-new session, and in the Cowork workspace VM on the user's own machine |

The ~26-minute intermittent window is the part I'd flag. The denial faded in rather than flipping — partial failures interleaved with successes against one host before it went hard. That reads like a rollout reaching the fleet, not a configuration change.

The enforced allowlist here is far narrower than the 205-host list reported above

Reachable:

| Host | Result | Note |
|---|---|---|
| registry.npmjs.org | 200 | in the proxy's noProxy bypass — never reaches the gateway |
| pypi.org | 200 | noProxy |
| api.anthropic.com | 404 | noProxy |
| github.com | 400 | through the gateway, allowed |
| claude.ai | 403 | through the gateway, allowed |

Refused at CONNECT (curl: (56) CONNECT tunnel failed, response 403):

api.openai.com              api.stability.ai        generativelanguage.googleapis.com
raw.githubusercontent.com   cdn.jsdelivr.net        example.com
www.google.com              anthropic.com           sentry.io
huggingface.co              registry.yarnpkg.com    crates.io
rubygems.org                packagist.org           go.dev
storage.googleapis.com      deb.debian.org          archive.ubuntu.com

So the gateway-permitted set is effectively {github.com, claude.ai}. Everything else that works does so only by bypassing the proxy entirely via noProxy.

Worth noting against the original report: registry.yarnpkg.com, crates.io, rubygems.org and deb.debian.org all appear in the 205-host allowed_hosts list quoted above, but are refused here — as is anthropic.com itself. So this is either a different and much smaller fallback list, or the JWT is being minted with a near-empty one. If the fallback list has a size, it would be useful to know whether it varies by account, plan or region.

Proxy state

$HTTPS_PROXY/__agentproxy/status reports "selective": false (no per-tool or selective allowlist in play), and logs every denial identically:

{"ts":"2026-09-11T11:57:06.353Z","kind":"connect_rejected",
 "detail":"gateway answered 403 to CONNECT (policy denial or upstream failure)",
 "host":"api.openai.com:443"}

Ruling out the usual suspects

• Not propagation delay — the setting was already in place and working (22:14Z), and the failure began mid-session with the setting untouched.
• Not stale session state — reproduced in a brand-new session created after the failure began.
• Not client or VM state — reproduced on two different machines (cloud container and the local Cowork workspace VM), which rules out a local proxy or a corrupted VM image.
• Not a user config change — the org setting was never edited; it read "All domains" before, during and after.

Happy to supply further probe output or status dumps if that helps narrow it.

Allow network egress is set to "All domains" in Settings → Capabilities, but every session (Cowork desktop AND claude.ai/code web, new sessions after re-saving the setting) enforces package-managers-only: all hosts 403 at proxy CONNECT, curl → 000. Worked 9/10, broken 9/11. Blocks a daily production workflow (Riverside uploads). Same as open issues #34690 / #30112 / #48114.

reproduced 2026-09-11 on both surfaces.

Since 2026-09-11, every Cowork cloud session blocks all egress except GitHub.
Settings > Capabilities: Allow network egress ON, Domain allowlist = All domains (unchanged for months).
Example session: https://claude.ai/code/session_01G6THDAi63PwExFoJRRYLHE

• git clone https://bitbucket.org/... -> CONNECT tunnel failed, response 403
• pypi.org, registry.npmjs.org, example.com -> HTTP 403, x-deny-reason: host_not_allowed
• github.com works

This worked in earlier sessions. Please check which egress policy cloud sessions are being given.

Confirming on Windows / Cowork desktop, Pro plan (individual), cloud sessions including scheduled tasks. Same end state as @MarcinPrDev, @robhdsndsn, @TheAviv and @stevekwan.

Exact regression date. Scheduled cloud runs reached accounts.pyrus.com, api.pyrus.com and docs.google.com successfully every morning from 2026-09-07 through 2026-09-10. The 2026-09-11 run failed. No settings changed on my side. This matches @stevekwan's 09-10 → 09-11 boundary exactly, and @TheAviv's mid-day 09-10 regression — three accounts on three platforms flipping within the same ~24h window.

Current state: only github.com and api.github.com return an HTTP status. Everything else is 403 at CONNECT.

accounts.pyrus.com 403 (CONNECT tunnel failed)
docs.google.com 403 (CONNECT tunnel failed)
github.com 400

$HTTPS_PROXY/__agentproxy/status:

{"kind":"connect_rejected",
"detail":"gateway answered 403 to CONNECT (policy denial or upstream failure)",
"host":"accounts.pyrus.com:443"}

Tried, all ineffective:

• Removing and re-adding each domain in Additional allowed domains
• Switching Domain allowlist from "Package managers only" to "All domains"
• Full desktop restart (quit to tray, verified process gone)
• Brand-new sessions with freshly provisioned sandboxes, plus manually fired scheduled runs
• Reverting an unrelated VPN exit-country change made the same evening (ruling out geo)

New data point: the "Only on your computer" workaround does not exist on Windows.

@uraw75 reports that switching Settings → Cowork back to "Only on your computer" restores network immediately on macOS. On Windows this is not available as an escape hatch — the local isolated Linux environment does not start at all:

Workspace unavailable. The isolated Linux environment on this device failed to start. A Windows update released September 8 prevents Claude's workspace from reaching your files. We're tracking this issue.

So Windows users hit by the cloud egress regression have no working path at all: cloud sessions can't reach custom hosts, and local execution can't start. I updated WSL to 2.7.13 (latest), enabled VirtualMachinePlatform, HypervisorPlatform and Microsoft-Windows-Subsystem-Linux, and rebooted — the workspace still fails to start.

Impact: two scheduled reports (Pyrus API + Google Sheets) have produced nothing since 09-11. They fail loudly rather than silently, but only because the prompt explicitly instructs them to stop and not publish on a network error — which, per @TheAviv's note about routines failing green, is not the default outcome.

<html><head></head><body><p>Adding a data point from a Cowork session on macOS (desktop app, cloud-hosted
session with a linked local device). Same root symptom as this issue, but the
minted allowlist in my case is much narrower than the ~205-host list quoted
above — it appears to be very close to empty.</p>
<p><strong>Setting:</strong> "Allow network egress" enabled, domain allowlist "All domains".
Unchanged for the life of the account — never edited, never scoped. Personal
org, single seat, so there is no admin policy layered on top.</p>
<p><strong>Symptom:</strong> every outbound host is refused at CONNECT by the egress proxy
except two GitHub hosts. Raw CONNECT to the local agent proxy, so this is the
proxy's own response rather than something a client is reinterpreting:</p>
<pre><code>$ CONNECT console.neon.tech:443
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Content-Length: 75
Connection: close

request blocked: no rule or allowlist entry allows host "console.neon.tech"
</code></pre>
<p><strong>Host matrix</strong> (all via raw CONNECT, same session, same minute):</p>

host | result
-- | --
github.com | 200 Connection Established
api.github.com | 200 Connection Established
raw.githubusercontent.com | 403
gitlab.com | 403
console.neon.tech / api.neon.tech / neon.tech | 403
api.fly.io / fly.io | 403
google.com / www.google.com | 403
docs.claude.com | 403
support.claude.com | 403

<p><strong>The part that suggests this is a distinct variant:</strong> I also probed entries
taken directly from the default allowlist quoted in the issue description —
<code>java.net</code>, <code>registry.yarnpkg.com</code>, <code>.googleapis.com</code>, <code>.nixos.org</code>. All of
them are refused too:</p>
<pre><code>storage.googleapis.com 403
www.googleapis.com 403
cache.nixos.org 403
java.net 403
registry.yarnpkg.com 403
</code></pre>
<p>So it is not that a hardcoded developer allowlist is being minted in place of
"All domains" — that list is not in force either. What is in force looks like
only the hosts the session's own GitHub integration needs. Anthropic's own
documentation and support domains being refused is what convinced me this is
not derived from any user-side configuration.</p>
<p><strong>It varies between sessions, which I think is the useful detail.</strong> My working
notes from 2026-09-10 record <code>github.com</code> itself being refused with the same
message ("no rule allows host github.com"), in a session on the same account
with the same "All domains" setting. Today github.com and api.github.com are
allowed and everything else is not. Same account, same setting, different
effective allowlist from one day to the next — consistent with the allowlist
being assembled per session from whatever integrations attach, with the user's
policy contributing nothing, and failing closed when nothing attaches.</p>
<p><strong>Both execution environments are affected by the same policy.</strong> The cloud
container and the VM on my linked local device return identical 403s for the
same hosts, so this is not specific to where code runs.</p>
<p><strong>What does not help:</strong> starting a new session, restarting the desktop app, or
re-saving the setting. Matches the report above that this is not a propagation
delay — I have been in this state for two days across several fresh sessions
and at least one fresh VM.</p>
<p><strong>Impact:</strong> the session cannot reach my Postgres database (Neon) or my
application host (Fly.io), which is most of what I use it for. Package
registries still work because they bypass the proxy via <code>no_proxy</code> rather than
because they are allowed, so "npm install works" is not evidence the policy is
being applied.</p>
<p>Environment: Cowork on macOS desktop app, cloud session with a linked local
device, <code>CCR_EGRESS_GATEWAY_ENABLED</code> set, agent proxy present at
<code>/root/.ccr/README.md</code>.</p>
<p>Possibly related and possibly not: GitHub API access in the same session is
separately gated per repository — <code>api.github.com</code> authenticates as my account
and then refuses every repository, including my own, with <em>"GitHub access to
this repository is not enabled for this session. Use add_repo to request
access."</em> There is no <code>add_repo</code> tool exposed in the session, so there is no
way to satisfy that instruction. Mentioning it only because it points the same
way: the reachable set looks like it is assembled from integration state rather
than from my configured policy.</p></body></html>

Same regression here (Cowork macOS, Claude for Mac 1.52386.0, cloud sessions). "Package managers only" + 29 custom domains was enforced and working until Sept 10 22:12 UTC; since then every host is refused (403 at CONNECT), even with "All domains", in both the cloud container and the local VM shell. An old July conversation that was not moved to the cloud still has network at the same time. Full details in #93525. Support ticket filed.

Same issue here in new Cowork and Code cloud sessions. Claude for Mac: Claude 1.52386.0 (1003ca) 2026-09-10T05:55:17.000Z.

Same exact symptoms, and workaround attempted on my end. This is affecting nearly 100 people in our team account, as we've built key workflows for the company that rely on making these requests. Maddening that there is nothing but radio silence anywhere I try and get support.

same issue here
Bug: Cowork cloud sessions block all outbound network traffic despite "All domains" being allowed.

Account: drestolano@hematologiaparatodos.com (Organization account)
Product: Claude Cowork, desktop app (macOS), cloud sessions (environment type: cloud_default)
Date observed: September 10, 2026 (worked normally on August 30, 2026)

Settings: Settings > Capabilities > "Allow network egress" = ON, Domain allowlist = "All domains" ("Claude can access all domains on the internet").

What happens: every HTTPS request from the session sandbox fails. The egress proxy answers 403 to CONNECT ("gateway answered 403 to CONNECT (policy denial or upstream failure)"). Blocked hosts include example.com, www.google.com, app.asana.com, api.telegram.org, *.supabase.co and our own self-hosted server (n8n.hematologiaparatodos.com.mx). Only GitHub and package registries get through.

Expected: with "All domains" selected, the sandbox should reach any domain.

Impact: all of our custom Skills that call our own automation server fail. Our clinic's daily operations depend on them.

Already ruled out: our server is up and reachable from the internet (verified from another network). Opening a new session doesn't help. It matches open GitHub issues #34690 and #63182 (the org-level allowlist is not propagated to the session proxy).

Request: please apply the "All domains" egress setting to Cowork cloud sessions on our organization account, or tell us the correct setting to change.