[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.