[BUG]Cowork network egress allowlist not working - custom domains blocked with 403 blocked-by-allowlist

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/23818
2. https://github.com/anthropics/claude-code/issues/11897
3. https://github.com/anthropics/claude-code/issues/18854

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Same issue via Claude Code remote execution (launched from Desktop app)

Reproducing this in remote container sessions started from Claude Desktop. The code executes server-side in a container (claude_code_remote), and the egress proxy JWT minted at session start still contains a hardcoded allowed_hosts field with ~100 specific domains — despite "All domains" being set in capabilities.

Deny reason in remote containers: x-deny-reason: host_not_allowed (vs blocked-by-allowlist on local Desktop proxy — may be two separate proxy implementations with the same root cause).

Decoded the session JWT and confirmed my custom domain is absent from allowed_hosts even in a session started 12+ hours after enabling "All domains". The policy change is not reflected in newly-minted JWTs.

Related to #19087. The JWT generation appears to be the common failure point across both execution environments.

Same issue here. macOS, Claude Desktop 1.1.4328 (d8e391), 2026-02-25T17:04:36.000Z. Pro plan.

The VM boots fine and the API is reachable — the network itself is working. From cowork_vm_node.log:

[VM] Network status: CONNECTED
[VM] API reachability: REACHABLE
[VM:start] Startup complete, total time: 5444ms

But all non-API web requests are blocked by the egress proxy. Cowork reports "google.com is blocked by the network egress proxy" when asked to reach any external domain.

I've tried:

• "All domains" — blocked
• "Package managers only" + manually adding google.com — blocked
• Deleting vm_bundles, letting the VM rebuild — blocked
• Full quit and reopen between every settings change — blocked

I dont know why this is marked as invalid, there are similar bugs listed.

any update? Also having this issue.

https://github.com/anthropics/claude-code/issues/11897 This seems to be related

Noticed this issue about 8-9 days ago - thought a new session would fix this, it did not. Very persistent bug.

Same issue, network access to MANY sites not working - full restart of everything on my end done, no change.

I have been trying to contact anthropic support for 2 weeks, with not a peep.

I have the same issue with the hardcoded whitelists in the anthropic Proxy for Claude Cowork. Even big Websites like YouTube or Reddit etc. are not reachable.

Debugging Steps

This is likely a config propagation issue between settings UI and MITM proxy:

1. Full restart - Kill Claude Desktop entirely, not just the session
2. JWT conflict - As noted in #19087, JWT allowlist may override UI settings
3. Proxy scope - Cowork might use a separate proxy instance

Workaround: Run a local proxy bypass:
export HTTP_PROXY=http://localhost:8080

Similar issues in OpenClaw's sandbox - config and enforcement must be synchronized.

Same issue here. Running Cowork on macOS with "All domains" enabled.
Restarted session after changing settings — still blocked.

Use case: biotech equity research requiring access to academic
publishers (PMC/ncbi.nlm.nih.gov, nejm.org, mdpi.com, nature.com),
pharma IR pages, and patent databases. Only patents.google.com gets through —
everything else returns 403 blocked-by-allowlist.

This makes Cowork significantly less useful for any research-heavy
workflow. The agent can search the web but can't fetch the actual
content it finds, which defeats the purpose.

just chiming in with additional; support for this issue.

macOS Tahoe 26.3.1, Claude desktop 1.1.7053. "All domains" is enabled.

Adding confirmation that this issue persists in the latest version:

Environment:

• Claude Code: 1.1.7714 (3bd6f6)
• Date: 2026-03-19
• Platform: macOS

Status: Still unable to connect to whitelisted external APIs (tested with api.openai.com) via Co-Work sandbox. Connection blocked with same error as reported in #28067.

The .cowork manifest declares the API domain, but it's not being merged into the VM's network allowlist before the session spawns.

Request: Can we get an ETA on when this fix is scheduled? This is blocking production Co-Work plugin development.

Broader Impact: All External APIs Blocked

This isn't just affecting specific domains—it's a systemic issue blocking all external API access. Testing from a home network with unrestricted outbound connectivity reveals:

DNS Resolution: Globally blocked for all external domains

• ❌ speech.googleapis.com (Google Speech API)
• ❌ stt.speech.microsoft.com (Microsoft Azure Speech)
• ❌ api.openai.com (OpenAI)
• ❌ api.deepgram.com (Deepgram)
• ❌ api.assemblyai.com (AssemblyAI)
• ❌ api.elevenlabs.io (ElevenLabs)
• ❌ api.sonix.ai (Sonix)
• ❌ api.speechmatics.com (Speechmatics)
• ❌ api.gladia.io (Gladia)
• ❌ api.groq.com (Groq)
• ❌ api.symbl.ai (Symbl.ai)
• ❌ api.supadata.ai (Supadata)

Only Whitelisted Domain:

• ✅ api.anthropic.com (Claude's own API)

Root Cause: The Co-Work sandbox uses an internal proxy with a restrictive allowlist. DNS queries are intercepted and blocked; the proxy is the only egress path. Even the .cowork manifest's whitelist declarations are not being enforced.

Impact: Users cannot access external data processing, transcription, integration, or AI APIs. This blocks legitimate enterprise use cases that depend on multi-API workflows.

Same issue for me on Claude desktop on Mac with cowork. It used to work. This really limits its usefulness.

Anyone have a fix for this? Same issue for me. It seems to also be inconsistent across Cowork sessions?

Same issue here. It's blocking things like release-assets.githubusercontent.com, which makes me unable to install the GH CLI tool on the VM

Same issue here. It's blocking 7min.ai and https://7min.ai/daily-ai-news-llms.txt

Same issue, it's blocking requests to my custom MCP Server.

Chiming in to say the same is happening to me on Windows 11, Claude 1.1.9134. Getting blocked on a bunch of sites like Medium, Substack and Goodreads.

Do we need to create a new bug for this, since this one has been marked "invalid"? It's pretty much a dealbreaker for a lot of use cases, so I'm afraid it's being filtered out of somebodies "what to work on next" query.

Do we need to create a new bug for this, since this one has been marked "invalid"? It's pretty much a dealbreaker for a lot of use cases, so I'm afraid it's being filtered out of somebodies "what to work on next" query.

I created a new bug, it was also instantly marked as invalid. I've been failing to get any support on this issue or anything else for a month. Claude code has now erased all my chat history too. It is to quote, Adrian, a bunch of utter utter utter utter barstards

I'm having this same issue:
Access to this website is blocked by your network egress settings
I have a bunch of specific websites I want claude to visit. ON top of that, there is nothing in Settings I can configure to make this work, so it is a bit confusing the message.

Getting same. Claude cowork tells me the allowlist doesn't seem to be taking effect from the sandbox

same issue here

Network Egress settings are ignored.

New MacBook Pro, Claude Pro Subscription. Fresh Install. Claude.app version:
Claude 1.2.234 (2d1855) 2026-04-01T07:58:22.000Z

No VPN or special network settings. Out of the box install in a standard MacOS user account. Settings > Capabilities setting:

Allow network egress

Give Claude network access to install packages and libraries in order to perform advanced data analysis, custom visualizations, and specialized file processing. Monitor chats closely as this comes with security risks.

Domain Allow List: ALL DOMAINS

---
Even with "ALL DOMAINS" whitelisted, all websites and package managers are blocked from Cowork. This greatly reduces the utility of Cowork.

Affected environment: Cowork (desktop app), automated/scheduled skill

Adding a production use case that hasn't been called out yet in this thread: this bug breaks unattended, scheduled skills — not just interactive sessions.

We have a Triage Auto-Responder skill that runs on a schedule to process our Zendesk support queue even when the agent is offline. Part of its job is reading ticket attachments (invoices, receipts, order confirmations) to extract order numbers and purchase dates so it doesn't ask customers for information they've already provided.

Because all Zendesk attachments are served through zdusercontent.com, and that domain is blocked by the sandbox proxy regardless of the admin allowlist setting, the skill is blind to every attachment in the queue. We confirmed the domain was added to the allowlist in Admin Settings > Capabilities > Network Access — no effect, as documented in this issue.

The Chrome extension workaround doesn't apply here because the skill runs on a schedule without a user present.

Impact: Every ticket with an attachment gets a degraded response — the skill has to ask the customer to re-provide information that's already in the attachment.

Happy to provide logs or more detail if useful. Upvoting and following for updates.

Same here with Claude 1.569.0 (49894a) 2026-04-02T20:01:42.000Z on MacOS

Working for me now after a Claude update.

Yeah just tried setup cowork with a custom plugin across the team and no one can use our skills because they need access to the outside world (github) - changing org settings doesn't change anything

Windows - Claude 1.569.0 (49894a) 2026-04-02T20:01:42.000Z

Solved for me as of Claude 1.569.0 (49894a)

the same here with Claude 1.1062.0 (b81bcd) 2026-04-06T21:20:28.000Z Can't access github.io pages. This is a cowork trying to access specific pages.

Having this same issue. Pretty frustrating.

Surprising that a bug so impactful and over a month old hasn't been solved by Mythos. :) Can we get a fix please?

Working for me as of Claude 1.1617.0 (8d6345) - but had to wait a while and restart Desktop for the changes to propagate, it seems.

I'm also experiencing this issue with Claude Code Scheduled Tasks (Remote Agents).

Setup:

• Domain allowlist: tried both "All domains" and "Package managers only" + Additional allowed domains
• Additional allowed domains: added my custom API gateway domain and Google Cloud Run service domains
• Deleted and recreated triggers multiple times to ensure fresh JWT sessions

Result:
Every new session's egress proxy JWT still contains only the hardcoded ~205 default domains. My custom domains are always blocked with 403 host_not_allowed.

The remote agent even decoded the proxy JWT and confirmed:

• allowed_hosts only permits a specific GCP project/region that is NOT mine
• My own Cloud Run services (different project/region) are blocked
• My custom API gateway domain is blocked
• "All domains" setting has zero effect on the JWT

Workaround: Running claude -p locally works fine (no egress proxy), but this defeats the purpose of scheduled remote agents.

Impact: This completely blocks the use of scheduled tasks for any workflow that calls custom APIs. Our use case is an automated educational content generation pipeline that needs to call our own API gateway and Cloud Run services.

Would really appreciate an official timeline for a fix. This has been open since November 2025.

mark

I'm also seeing this issue with the latest Claude Cowork.

Also it's own help text seems to be off:

Could you add api.github.com to Settings → Desktop app → Capabilities → Network allowlist (it needs to be that exact hostname, not just github.com)?

Capabilities is under Settings, not in Desktop App.

_Creating a New Session or New Chat_ should fix this, I was just able to reproduce (then ran into this thread), talked with the Anthropic AI Agent (transcript below):

Agent: That behavior is expected: Cowork network settings only apply when a new Cowork session is created. If you add domains to the allowlist while a conversation is already active, the change won’t take effect in that existing session. So the fix is to start a brand new conversation after updating the allowlist, then try the same request again. One more thing to keep in mind: these network egress permissions don’t apply to web search or MCPs (including Claude in Chrome), so allowlisting won’t affect those tools. Is that what you were looking for? Paul: Let me test this and then get back to you on how it works. Agent: Sounds good. I'll be here if you need any follow-up help after testing. Paul: I attempted to completely restart the Cowork app (close and then reopen via "quit Claude") and it didn't work. Is that expected? Agent: Yes, that’s expected. Quitting and reopening Claude Cowork won’t apply an updated allowlist to an existing conversation. The network egress settings only take effect when a new Cowork session is created, so you need to start a brand new conversation after updating the allowlist for the change to show up. One more thing to keep in mind: these network permissions don’t apply to web search or MCPs (including Claude in Chrome), so allowlisting won’t affect those tools.

So you'll need to create a new context/chat to have this take affect, which feels like a strange behavior, but seemed to work. The existing chat/context will never be able to use the new egress rules from what I can tell. I asked Claude to dump memory and a starter prompt for me to start a new chat.

Direct quote from Support Article:

Network settings are applied when a new Cowork session is created. If you change the network access mode or add domains to the allowlist while a conversation is already active, those changes will not take effect in that session. Start a new conversation for the updated settings to apply.

Another vote for this - I'm seeing this issue too!

I want to add a +1 to this. I troubleshot for an hour today before looking for bug reports.

I spent a long time on this until spotting @pauljpemberton's comment above re: new session required. Odd behaviour.

Working solution: configure a custom environment with explicit allowed domains

In Claude Code on the web (claude.ai/code), each routine/session runs in a cloud environment with its own network policy. The "Default" environment uses the Trusted allowlist, which is why custom domains return 403 host_not_allowed.

Fix: create a new environment alongside Default and pick a different access level. Attach your routine/session custom environment to it instead of Default.

<img width="1191" height="694" alt="Image" src="https://github.com/user-attachments/assets/fd4218d1-29c0-4adc-87fe-eb04fed5cea6" />

Full — any domain. Use this only to confirm the egress proxy is the root cause. Don't run production routines on Full; it removes the sandbox boundary.

Custom — explicit allowlist with *. wildcards, optionally extending the Trusted defaults. This is what you should actually run on: minimal exposure, only the domains your routine needs.

Same issue, macOS, All domains setting has no effect

Same issue. Windows. Latest Claude Version. Various restarts and combinations of Allowlist settings have zero impact on the application.

Same issue, macOS, All domains setting has no effect

Confirming this on Claude Code 2.1.42 with CLAUDE_CODE_USE_CCR_V2=true (remote_desktop entrypoint). The "All domains" egress setting does not take effect mid-session and appears to have no effect even after session restart. All external hosts return x-deny-reason: host_not_allowed except api.anthropic.com and registry.npmjs.org. MCP stdio servers (tavily-mcp, context7) that made outbound calls worked fine before CCR v2 migration.

here's a workaround: Use <string>["*"]</string> (JSON-encoded array) instead of <array><string>*</string></array> (native plist array). It will work! Enjoy!

Confirming as a Teams plan org admin — "All domains" does not unblock custom domains.

Adding to the pile with an admin-side repro, since I control the capabilities settings directly and can confirm the config is correct.

Environment

• Plan: Team (I'm the org admin)
• Platform: Claude Desktop for macOS, Cowork
• Claude Desktop version: 〈fill in — Settings → About〉

What I configured

1. Organization settings → Capabilities → Code execution → "Allow network egress" = ON
2. Added api.harvestapp.com to "Additional allowed domains"
3. Tested → still blocked
4. Switched mode to "All domains"
5. Fully quit Claude Desktop, started a brand-new Cowork session
6. Still blocked

Control — a domain that should be reachable:
curl -sS -o /dev/null -w "%{http_code}\n" https://api.github.com/

Target — the domain I explicitly allowlisted / "All domains" should cover:
curl -v https://api.harvestapp.com/v2/users/me

Claude responds: That confirms it clearly — there's a local proxy (localhost:3128) that all outbound traffic is routed through, and api.harvestapp.com is not on its allowlist. The header X-Proxy-Error: blocked-by-allowlist is the definitive answer.
api.harvestapp.com cannot be reached from the Cowork sandbox. Only domains explicitly allowed by Anthropic's proxy are accessible.

Facing similar issue in claude desktop when the allowed domain is set as Package Manager Only and added my custom domain yet facing the permissions issue

Access to this website is blocked by your organization's network egress settings. Ask your administrator to adjust egress settings to allow access to this site.

Same Issue "All Domains" setting not propagating to the sandbox proxy JWT when trying to access WordPress API on a seflf hosted WordPress site.

Confirming on Windows, for the code-execution sandbox (not just WebFetch), on a freshly-booted VM.

Environment: Claude desktop (Cowork), Windows 11 host. Sandbox egress via HTTP proxy at localhost:3128 (SOCKS at localhost:1080). Allowlist set to "All domains".

On a VM with uptime < 1 minute (rules out stale-session / propagation-delay explanations):

pypi.org → 200 (package-manager domain, allowed)
example.com → 403, response header X-Proxy-Error: blocked-by-allowlist
a custom-added domain → same 403 / blocked-by-allowlist
The 403 is returned by the proxy at the CONNECT phase: CONNECT <host>:443 → HTTP/1.1 403 Forbidden / X-Proxy-Error: blocked-by-allowlist. Custom allowlist entries and "All domains" both have no effect; only package-manager domains ever pass — matching the hardcoded-allowed_hosts-in-JWT finding above. Can attach curl -v output showing the CONNECT 403 + X-Proxy-Error header alongside the pypi.org 200

Seeing the same issue on Claude Code on the web (not just Desktop Cowork).

Steps: allowlist set to "Package managers only" + specific domains added → still 403 on those domains. Switched to "All domains" and tried 3 separate fresh sessions (confirmed fresh each time — internal proxy port changed every time). Still blocked in all three — not just the target domain, but even generic ones like www.google.com and example.com fail to connect.

This persisted over 30+ minutes across multiple fresh sessions, so it doesn't look like a brief propagation delay — the "All domains" setting doesn't seem to reach the actual egress gateway at all.

Still present — and now a regression — on 1.49585.0 (macOS, Apple Silicon, Pro plan).

Allow network egress is on and Domain allowlist = "All domains" (UI says "Claude can access all domains on the internet"), yet all non-Anthropic-API egress is still blocked. On Pro this in-app toggle is the only egress control (no Admin → Capabilities layer), and it's set to the most permissive option.

What's new vs the original report: this worked reliably for months and broke without any settings change, on/around 1.49585.0 (2026-09-08).

Repro / evidence:

$ curl -s -o /dev/null -w "%{http_code}" https://github.com
000

$ git push origin main
fatal: unable to access 'https://github.com/<owner>/<repo>.git/':
Received HTTP code 403 from proxy after CONNECT

The Anthropic API stays reachable; only non-API domains are blocked — consistent with the proxy enforcing an allowlist that doesn't include what the UI has selected. Reproduces identically in both an on-device ("on your computer") session and a cloud session reaching the machine over the bridge.

Likely the same root cause as #34690 (the "All domains" selection not making it into the session proxy allowlist). This makes git push/fetch over HTTPS and any non-allowlisted host unreachable from the sandbox, with no user-side fix since the toggle has no effect.

Secondary, related: when the repo lives under a delete-restricted attached folder, git can't clean up its own .git/*.lock files (unlink → Operation not permitted), so a single interrupted git operation leaves stale locks that block the next commit until removed manually.

Adding a fresh Cowork cloud-session reproduction from 2026-09-10 at approximately 23:37 UTC.

Environment and admin settings

• Claude Team plan; Cowork cloud execution, accessed through claude.ai.
• Organization settings → Capabilities → Code execution:
• Cloud code execution and file creation: enabled.
• Allow network egress: enabled.
• Domain allowlist: All domains.
• The admin settings were checked directly, rather than inferred from the agent's error message.

Minimal reproduction
In a newly created Cowork session, run this using the sandbox terminal/code-execution tool (not WebFetch, a browser, or MCP):

curl -sS -o /dev/null -w '%{http_code}' --max-time 15 --retry 0 https://example.com

Observed:

• HTTP status reported by curl: 000.
• curl exit code: 56.
• Error: curl: (56) CONNECT tunnel failed, response 403.

This was an unauthenticated request with the body discarded. No credentials, proxy changes, or network-policy bypasses were used. The failure occurs while establishing the CONNECT tunnel, before an HTTP response from example.com.

Additional diagnostic: OTel disabled
To test whether Cowork monitoring configuration was involved, we cleared the organization's OTLP export settings, reset content capture, verified the saved configuration, and then created the fresh session above. The collector endpoint was empty before that session started. The same CONNECT 403 persisted. This rules out clearing OTel as an effective workaround in this test; it does not establish the underlying cause.

Remote MCP tool calls were still working while direct sandbox HTTPS requests failed, so connector reachability should not be treated as proof that sandbox egress works.

This appears consistent with the fresh-session symptoms in #34690. Can the team investigate whether the All domains organization setting is being propagated to the effective Cowork cloud egress policy? Happy to provide further non-sensitive reproduction details.

Confirming the same on Pro + desktop (and over the cloud bridge) — 403 from proxy after CONNECT on git push with "All domains" set. Combined with the Team/cloud repro above, this spans plans and execution modes, so it looks like the shared egress layer, not a plan- or surface-specific config.

Adding another confirmed repro, Cowork session linked to a Mac via desktop app ("Link to this computer"), both shells affected (cloud sandbox Bash and local device_bash):

Was working normally through 2026-09-07, broke mid-session on 2026-09-11 with no config change on my end. Same behavior in both this thread's reports and mine: 403 Forbidden on the proxy CONNECT, ignoring account Settings → Capabilities → Network → "All domains".

$ curl -sv -m 15 https://example.com -o /dev/null 2>&1 | grep -E "CONNECT|HTTP/1.1"

• Uses proxy env variable https_proxy == 'http://127.0.0.1:45139'

CONNECT example.com:443 HTTP/1.1

< HTTP/1.1 403 Forbidden

Confirmed it's not a local network/API-key issue: the exact same curl command against the target API succeeds with HTTP 200 when run outside Claude, in the Mac's native Terminal.

$HTTPS_PROXY/__agentproxy/status (cloud container) shows:
enabled: true, port: 45139, selective: false, standalone: false, toolScoped: false
Only package registries (pypi.org, registry.npmjs.org) and a few Anthropic hosts are in noProxy — every other host gets the 403, including neutral controls like example.com, not just the specific third-party APIs I need (commercial data APIs with auth headers).

Reference session: session_0151goyP3JR4Z2YCugaUUJKF

Reproducing this on 2026-09-11, and adding two data points: the same "All domains" setting is also ignored by the cloud session egress gateway (not just the desktop MITM proxy), and the desktop VM blocks even github.com.

Environment: Claude Desktop (Cowork) on macOS, Settings > Capabilities: "Allow network egress" = ON, Domain allowlist = "All domains". Setting changed, app restarted, and a fresh cloud session started afterward — behavior identical to older sessions.

1. Cloud sandbox session — upstream gateway answers 403 to the CONNECT itself for arbitrary domains, while a curated few pass:

$ curl -sS --max-time 20 -o /dev/null -w "HTTP=%{http_code} CONNECT=%{http_connect}\n" URL

https://api.vimeo.com/                             -> curl: (56) CONNECT tunnel failed, response 403 ; CONNECT=403
https://legion-backend-staging.azurewebsites.net/  -> curl: (56) CONNECT tunnel failed, response 403 ; CONNECT=403
https://github.com/                                -> CONNECT=200 (allowed)
https://api.github.com/                            -> HTTP=200 CONNECT=200 (allowed)

The sandbox's local agent proxy reports itself healthy and non-selective ("selective": false) and attributes the denial upstream:

"recentRelayFailures": [
  { "kind": "connect_rejected",
    "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
    "host": "api.vimeo.com:443" },
  { "kind": "connect_rejected",
    "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
    "host": "legion-backend-staging.azurewebsites.net:443" }
]

2. Desktop VM (device_bash), same session, same settings — blocks everything including GitHub:

$ curl -sS -o /dev/null -w "CONNECT=%{http_connect}\n" https://github.com/
curl: (56) Received HTTP code 403 from proxy after CONNECT
CONNECT=403

So with "All domains" explicitly selected: the cloud gateway still enforces what looks like a fixed curated allowlist, and the desktop VM proxy enforces an even narrower one. The setting has no observable effect on either surface. Matches #23818 / #30861 / #38984 as well.

Impact here: any workflow against arbitrary APIs (a Vimeo upload pipeline and an Azure-hosted backend in our case) is unusable in Cowork.

<html><head></head><body><p>Same symptom on a <strong>personal Pro account</strong>, cloud Cowork session — and in my case it's a clear <strong>regression</strong>, not a from-the-start failure.</p>
<p><strong>Settings (verified in UI):</strong></p>
<ul>
<li>"Allow network egress": ON</li>
<li>"Domain allowlist": All domains — UI confirms "Claude can access all domains on the internet"</li>
</ul>
<p><strong>Symptom:</strong> every external host fails at CONNECT with 403, including <code>www.example.com:443</code>. Only noProxy-listed package registries (pypi.org) succeed.</p>
<pre><code>$ curl -v https://www.example.com
&gt; CONNECT www.example.com:443 HTTP/1.1
&lt; HTTP/1.1 403 Forbidden

• CONNECT tunnel failed, response 403

curl: (56) CONNECT tunnel failed, response 403
</code></pre>
<p>The agent proxy status endpoint (<code>/__agentproxy/status</code>) logs:</p>
<pre><code>kind: connect_rejected
detail: gateway answered 403 to CONNECT (policy denial or upstream failure)
host: www.cheonan.go.kr:443
</code></pre>
<p>Status also reports <code>enabled: true</code>, <code>selective: false</code>, <code>toolScoped: false</code>.</p>
<p><strong>Regression timeline</strong> — I have scheduled tasks that fetch <code>www.cheonan.go.kr</code> three times each weekday, so the break is precisely bracketed:</p>

Run (UTC) | Result
-- | --
2026-09-10 05:11 | SUCCEEDED
2026-09-10 10:20 | SUCCEEDED
2026-09-11 01:32 | FAILED (403)
2026-09-11 05:10 | FAILED (403)

<p>Nothing changed on my side between those runs — same task, same script, same settings. Manual runs fail identically, so it isn't specific to the scheduler.</p>
<p>Notably <code>api.github.com</code> IS reachable from the same session while <code>github.com</code> and all other external hosts are not, which suggests an allowlist is being applied that ignores the "All domains" setting entirely.</p></body></html>

Coworkの管理設定（Capabilities）で許可ドメインを登録済みですが、Cowork内から外部ドメインへの通信が全て403 Forbiddenでブロックされます。
エラー本文: request blocked: no rule or allowlist entry allows host "＜ドメイン名＞"
設定を登録し直しても解消せず、複数の新しいセッションでも同じ現象が再現します。
GitHubのissue #30112、#23818 と同じ症状です。
組織アカウントでの許可リスト同期を確認し、修正をお願いします。

この機能（Admin CapabilitiesのNetwork Access）を使うためにTeamプランに契約していますが、このバグのせいで契約した目的の機能が使えていません。優先的に対応をお願いします。

Same issue
Cowork / Claude Desktop — network egress allowlist does not match configured policy

Org settings > Capabilities > Code execution:
Cloud code execution and file creation .... on (Default)
Allow network egress [Chat][Cowork] ....... on (Default)
No network-access mode selector is rendered under either setting.

Measured inside the Cowork local VM (aarch64, Python 3.10.12):
CONNECT pypi.org:443 -> HTTP/1.1 403 Forbidden
X-Proxy-Error: blocked-by-allowlist
Proxy auth succeeds; the proxy is healthy (bare request returns 407).

Reachable : api.anthropic.com, claude.ai, objects.githubusercontent.com
Blocked : pypi.org, files.pythonhosted.org, registry.npmjs.org,
registry.yarnpkg.com, index.crates.io, proxy.golang.org,
jsr.io, nodejs.org, github.com, raw.githubusercontent.com,
deb.debian.org, storage.googleapis.com, google.com
The proxy returns 403 on its own status/allowlist endpoints.

Expected under the documented default ("package managers only"): pypi.org and
files.pythonhosted.org reachable. Effect: pip3 install -r requirements.txt is
impossible, so a JSON-Schema validator (jsonschema>=4.18) cannot be installed;
the VM ships 3.2.0, which has no Draft202012Validator.

Appears related to anthropics/claude-code#30112, #34690, #51400.

Seeing the same thing, with one extra data point that might help narrow it down: for me it is per-project, not account-wide.

Most of my projects reach their domains normally. One specific project gets nothing at all, under the same account and the same network settings. In that project every host is denied except the ones in the proxy's own hardcoded noProxy bypass list (Anthropic endpoints, GitHub, and the npm/PyPI/crates/Go registries). Measured in the cloud shell:

api.github.com -> 200 mysite.example -> blocked
github.com -> 400 example.com -> blocked
google.com -> blocked
wikipedia.org -> blocked
support.claude.com -> blocked

example.com being blocked is the part that rules out anything domain-specific on my side.

Every denial logs the same way:

curl -sS "$HTTPS_PROXY/__agentproxy/status"
{"kind":"connect_rejected",
"detail":"gateway answered 403 to CONNECT (policy denial or upstream failure)",
"host":"..."}

with "selective": false and "toolScoped": false.

It hits both shells. The cloud container reaches api.github.com but nothing else. The local VM shell (device_bash) is tighter still and cannot even reach api.github.com.

Things that did not change anything:

• Confirming the domains are allowed in Organization settings > Capabilities > Code execution
• Starting a brand new task, which I understand is when egress policy is resolved

Since other projects under the same settings work fine, this looks less like the proxy ignoring the allowlist globally and more like the allowlist not being delivered to certain projects' VMs. That would fit the allowedDomains=23 clue in the original report, where a default list appears to arrive in place of the configured one.

Happy to pull whatever diagnostics would be useful.

This gets more and more broken after latest updates on Sep 10:

• #93494 — Cowork (macOS): all outbound egress lost mid-session from both the desktop workspace and the cloud container
• #93507 — Cowork macOS: local sandbox VM starts with no network route, cloud egress proxy returns 403 for every domain (regression since 2026-09-10 ~23:15 UTC)
• #93512 — Cowork cloud sessions ignore "Allow network egress: All domains," enforce a narrow built-in allowlist; third-party API calls fail on both cloud and local VM shells
• #93520 — Cowork VM egress allowlist ignores Admin Capabilities network access settings
• #93525 — Cowork cloud sandbox: egress allowlist collapses to ~5 hosts despite "All domains"
• #93561 — Cowork/cloud sandbox: api.telegram.org blocked, Pro/Max accounts have no setting to allow it
• #93562 — Egress allowlist ignores "All domains": every host outside a built-in list gets 403 on CONNECT; scheduled tasks silently marked SUCCEEDED despite failing
• #93589 — Cowork Desktop: "Additional allowed domains"/"All domains" stopped being enforced after the 2026-09-11 VM update (2.1.260 → 2.1.266)
• #93056 — Cloud egress gateway resets any TLS ClientHello carrying the ECH extension (Chromium/Playwright specific, same gateway component, possibly separate root cause), from Sep 9

I have same problem on version 1.52386.0

@claude pls fix

Adding another confirmed reproduction from 2026-09-11, cloud session and desktop VM both affected, fresh session started after the setting was saved.

Environment

• Plan: Team
• Claude Desktop for macOS, version 26.6.2
• Cowork cloud session linked to the Mac via the desktop app
• Settings > Capabilities: "Allow network egress" = ON, Domain allowlist = "All domains". Verified in both the claude.ai settings page and the desktop app; they match.
• Setting was toggled to a managed list and back to "All domains", saved, then a brand new session was started for the tests below. Results were identical to a session run about an hour earlier.

Cloud sandbox shell (fresh session)

example.com                 HTTP=000  CONNECT=403
www.google.com              HTTP=000  CONNECT=403
en.wikipedia.org            HTTP=000  CONNECT=403
raw.githubusercontent.com   HTTP=000  CONNECT=403
github.com                  HTTP=400  CONNECT=200  (allowed)
api.github.com              HTTP=200  CONNECT=200  (allowed)

Package registries, which are in the proxy's own noProxy list and should be reachable under any allowlist mode including "Package managers only":

pypi.org             HTTP/2 403   x-deny-reason: host_not_allowed
registry.npmjs.org   HTTP/2 403   x-deny-reason: host_not_allowed

So pip and npm installs fail in the sandbox regardless of the setting.

$HTTPS_PROXY/__agentproxy/status reports enabled: true, selective: false, toolScoped: false and logs each blocked CONNECT as:

"kind": "connect_rejected",
"detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)"

Mac local VM shell (device_bash, same linked session)

All tested hosts blocked, including github.com and api.github.com, which the cloud sandbox allows:

example.com                 HTTP=000  CONNECT=403
www.google.com              HTTP=000  CONNECT=403
en.wikipedia.org            HTTP=000  CONNECT=403
raw.githubusercontent.com   HTTP=000  CONNECT=403
github.com                  HTTP=000  CONNECT=403
api.github.com              HTTP=000  CONNECT=403

Verbose output from the Mac VM proxy (127.0.0.1:3128):

> CONNECT example.com:443 HTTP/1.1
< HTTP/1.1 403 Forbidden
< X-Proxy-Error: blocked-by-allowlist
* Received HTTP code 403 from proxy after CONNECT

Still working

WebFetch and the Claude in Chrome extension both reach example.com and other sites normally, and remote MCP connectors work. Only the two sandbox shells are affected.

No settings changed on my side other than the toggle-and-restore described above, which had no effect. Matches the Sep 10-11 regression reports above (#93494, #93507, #93512, #93525, #93562, #93589).

Same symptom on Cowork, 11 Sep 2026, desktop app 1.52386.0, Team org.

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

What makes this report different from the ones above: our effective allowlist appears to be empty, not merely frozen to the default set.

registry.npmjs.org      403  "Host not in allowlist: registry.npmjs.org"
files.pythonhosted.org  403  same
pypi.org                403  same
example.com             403  at CONNECT, no body
google.com              403  at CONNECT, no body
<our internal host>     403  at CONNECT, no body

registry.npmjs.org is in the default allowlist and in the container's own noProxy list, yet it is refused. DNS resolves fine. Same result over plain HTTP on port 80 (no CONNECT), and with curl --noproxy '*'. Same from the local device VM (device_bash), whose traffic is forced through the same tunnel — so there is no local workaround.

Reproduced on two successive fresh containers, several hours apart.

Note that most hosts return a bodyless 403 at CONNECT; only a few return the readable Host not in allowlist message. That makes this easy to misdiagnose as a gateway outage rather than an allowlist problem — it cost us half a day before we read a response body instead of just the status code.

Impact: the cloud container has no network at all — internal API, database, package installs. This is consistent with #34690's finding that the session proxy JWT never reads the org setting.

I just realized that in Cowork, the new tasks, created since yesterday, are the ones that are having troubles. Old tasks are still working, so I'm reusing them while this is solved. Hope this help someone.

Follow-up with a working control container, which I have not seen in this thread yet.

Two accounts in the same Team org, on the same Mac, same app build (1.52386.0), same guest kernel (6.18.44-fc-v24), both root@vm, tests run 25 seconds apart.

Account A — egress works. No proxy in the container at all:

$ env | grep -iE 'proxy|no_proxy'
(empty)
$ cat /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:..."     # nothing else

$ curl -D - https://registry.npmjs.org/
HTTP/2 200
server: cloudflare
{}

Account B — egress blocked. Full proxy stack injected:

CCR_AGENT_PROXY_ENABLED=1
CCR_UPSTREAM_PROXY_ENABLED=1
https_proxy=http://127.0.0.1:34231
CLAUDE_CODE_PROXY_RESOLVES_HOSTS=true
no_proxy=...,registry.npmjs.org,jsr.io,pypi.org,files.pythonhosted.org,index.crates.io,proxy.golang.org,...

$ curl -D - https://registry.npmjs.org/
HTTP/2 403
x-deny-reason: host_not_allowed
Host not in allowlist: registry.npmjs.org. Add this host to your network egress
settings to allow access.

Why this matters: the difference is not the org-level setting (identical org, single settings page), not a local network/VPN/corporate proxy (same machine, same minute, and no third-party proxy can emit x-deny-reason), and not the client version (same build). One session is provisioned with no egress filtering whatsoever, the other with the filtering proxy and an empty effective allowlist. So the proxy injection and the allowlist it receives are decided per session at provisioning time — which is consistent with #34690's finding that the session proxy JWT never reads the org setting, and would explain why toggling the setting and restarting changes nothing (@cardwink above).

This also confirms @cardwink's host_not_allowed on registry.npmjs.org / pypi.org despite those hosts being in the container's own no_proxy list: I see the same, and curl --noproxy '*' does not help either, so interception is transparent and there is no in-container workaround.

Correction to my earlier comment (and to @fitohc's suggestion): reusing older tasks is no longer a workaround. Tasks created before the regression are now blocked as well.

Adding a data point that lines up with @P-tite-tete's per-session-provisioning finding, plus a clean way to test it.

Same account, same Mac, two projects, opposite results:

• Pre-existing project (running a while): github.com → 000, git push → fatal: … Received HTTP code 403 from proxy after CONNECT. Anthropic API still reachable — only non-API hosts blocked.
• Freshly-created project (same Pro account, same machine, minutes later): example.com → 200, api.github.com → 200, and an authenticated api.github.com/user → 200. A real git ls-remote returned a commit hash. Full egress, no filtering proxy.

So the difference tracked to which session got provisioned with the filtering proxy, not the org setting, the machine, the network, or the client version — consistent with @P-tite-tete's control (proxy present vs. absent on the same Mac/build/minute) and with #34690 (the session proxy token never reads the org "All domains" setting).

Practical read for anyone stuck: creating a new project has been landing a clean provision for us — but since it's decided per session, it's not guaranteed, so test before relying on it. And per @P-tite-tete, reusing an old task is no longer a workaround — pre-regression tasks are getting blocked too.

A 10-second test (read-only, no push) to tell a good session from a bad one:

for h in https://example.com https://github.com https://api.github.com; do
  printf '%-28s %s\n' "$h" "$(curl -s -o /dev/null -w '%{http_code}' --max-time 15 "$h")"
done
# 000 = blocked by the proxy; 200/301/400 = reachable.
# Blocked sessions also show it in the container's own env:
env | grep -iE 'proxy|CCR_' ; curl -sD - -o /dev/null https://registry.npmjs.org/ | grep -i x-deny-reason

On a blocked session you'll see the injected https_proxy=http://127.0.0.1:…, CCR_*_PROXY_ENABLED=1, and x-deny-reason: host_not_allowed; on a good one, no proxy vars and a clean 200. curl --noproxy '*' doesn't help — interception is transparent, so there's no in-container workaround; you need a session that was provisioned without the proxy (or push from a normal terminal outside the sandbox).

Workaround that worked for us: toggle the org setting off and back on.

Following up on my previous comment (two accounts in the same Team org — the owner's container unproxied and working, a member's container proxied with an empty allowlist).

Steps, as org owner: Admin settings → Capabilities → Allow network egress: toggle OFF, save, toggle back ON. The domain allowlist was already "All domains" and was left untouched. Then start a brand new Cowork task on the affected member account — existing tasks keep the old policy.

Before (18:37 UTC, member account):

CCR_AGENT_PROXY_ENABLED=1
https_proxy=http://127.0.0.1:34231

$ curl -D - https://registry.npmjs.org/
HTTP/2 403
x-deny-reason: host_not_allowed
Host not in allowlist: registry.npmjs.org.

After (18:53 UTC, same member account, new task):

CCR_AGENT_PROXY_ENABLED=1
https_proxy=http://127.0.0.1:36517      # new port = new session

$ curl -D - https://registry.npmjs.org/
HTTP/2 200
server: cloudflare
{}

The proxy is still injected and still enforcing — what changed is that the allowlist is now populated. That fits the JWT-provisioning theory in #34690: the org setting was sitting at its default value (the admin page literally labels it "Default") and never materialized into the session policy; writing it explicitly appears to materialize it. If that is the mechanism, every org that never touched this toggle is exposed, which would explain the volume of reports here.

Caveat: I cannot fully exclude a server-side fix landing in that 16-minute window. Someone else on the thread trying the toggle would settle it — it costs 30 seconds.

One more thing that helps while blocked: per the admin page, "Network egress controls do not apply to web search, web fetch, or MCP connectors." Confirmed — WebFetch, remote MCP connectors and the Chrome extension keep working inside an affected container. Only the sandbox shell and package installs are dead.

Correction to my workaround comment above: existing tasks recovered as well, not only newly created ones. A task started this morning that had lost all egress is now reaching example.com (200), our internal ERP host (200) and oauth2.googleapis.com (404 at the root, i.e. the host answers) without being restarted.

So the policy is re-evaluated continuously rather than frozen at session provisioning — which makes a server-side fix landing in that same window at least as likely an explanation as the toggle itself. Anyone trying the toggle should report whether it helps, and whether they see it take effect on an existing task.

Same symptom, macOS desktop app (Cowork), September 2026.

Setup: Settings → Capabilities → Code execution and file creation → "Allow network egress" enabled, domain allowlist set to All domains. Fresh Cowork session started after changing the setting (and after a full app restart + reboot).

Result: all egress to my own domain is still blocked, from both the cloud sandbox and shell commands executed on the local machine:

proxy refused CONNECT to ha.example.com:443: HTTP/1.1 403 Forbidden
x-deny-reason: blocked-by-allowlist

Same 403 via the host's LAN IP, so it's the sandbox proxy, not DNS or the target (the host is reachable fine from a normal terminal and from Claude Code local sessions on the same machine).

Also confirming the sibling bug anthropics/claude-code#38984: adding the domain under "Additional allowed domains" has no effect either. As it stands there is no way to reach a self-hosted service from Cowork regardless of settings; MCP connectors (which route through Anthropic's proxy) are the only thing that gets through.

Same problem