[BUG] Cowork — "Additional allowed domains" allowlist non-functional

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/30112
2. https://github.com/anthropics/claude-code/issues/37970
3. https://github.com/anthropics/claude-code/issues/30861

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

It's not the same as #30112. That one talks about "All domains" failing, which works here.
It's not the same as #37970, as that talks about local JSON settings while here's it's about organisation-wide settings (and again, with "All domains" it works).
It's not the same as #30861 because again that talks about local settings, not organisation settings.

work as soon as "All domains" are allowed

I tested this the egress only works for the owner of the org, a standard user is still not able to access even if the org wide setting is "All domains" allowed.

@knub can you please try and replicate my findings ?

Same issue, macOS, Domain allowlist setting has no effect

Same issue here — claude.ai Projects (not Cowork)

I've been using a custom skill that calls a Google Apps Script (GAS) Web App via script.google.com and script.googleusercontent.com. Both domains have been in my allowlist for over a month and were working fine until recently.

Environment:

• Platform: claude.ai (Projects feature, not Claude Code / Cowork)
• Domain allowlist mode: Custom domains specified in project network settings
• Domains added: script.google.com, script.googleusercontent.com

Symptoms:

curl -v https://script.google.com/macros/s/<SCRIPT_ID>/exec?action=list

< HTTP/2 403
< x-deny-reason: host_not_allowed
Host not in allowlist

The domains are confirmed present in the allowlist UI. No changes were made on my end.

Timeline:

• May 15, 2026: Skill was working normally (last confirmed successful call)
• May 20, 2026: Sandbox null-byte bypass vulnerability publicly disclosed
• After May 20: Silent fix applied by Anthropic — domains in allowlist started being blocked
• June 2, 2026: 403 host_not_allowed confirmed

This suggests the regression may be a side effect of the sandbox security fix applied after the May 20 disclosure. The timing matches exactly.

This matches the pattern in this issue exactly — custom domain entries appear to be silently ignored by the sandbox proxy. Would appreciate any update on a fix or workaround short of enabling "All domains".

---
Note: English is not my first language. This comment was written with the assistance of an AI(Claude.ai).

Adding another case from an Enterprise org (Aleph).

Environment:

Plan: Claude Enterprise
Platform: Cowork (web)
OS: macOS
Use case: We are trying to call an internal n8n webhook from a Cowork agent as part of an automation workflow. The domain is added to the allowlist under Organization Settings → Capabilities → Code execution.

Symptoms:

curl -s -X POST https://xxxxxxxx/webhook/cowork-test
→ Exit code 56 (connection reset) or
→ X-Proxy-Error: blocked-by-allowlist
The endpoint is confirmed live and reachable from outside the sandbox (200 OK from terminal). The block is exclusively coming from within the Cowork sandbox.

Also confirming aryan-think's observation: We can reproduce the same behaviour with "All domains" mode. It works for the org owner but regular users in the same org are still blocked. This means even the nuclear option ("All domains") is not a viable workaround for teams where end users are non-owners.

Impact: This is blocking a production use case where Cowork agents need to trigger internal automation workflows via webhook. Without a working allowlist, the entire integration pattern (Cowork → n8n → internal tools) is not viable.

Any ETA on a fix would be much appreciated.

Also hitting this on Claude Code on the web (sandbox container), not just Cowork —
several Claude Code reports were closed as duplicates of this one, so adding the repro here.

Mode: Package managers only, with example-org.com, *.example-org.com and two
unrelated third-party API domains on the additional list.

Every preset host connects (registry.npmjs.org → 200). Every host that appears only
on the additional list gets 403 on CONNECT. The sandbox behaves as though the additional
list is empty. (storage.googleapis.com connects, but it's a preset artifact host too,
so it isn't evidence the list works.)

Rules out:

• Stale container — created well after the domains were saved.
• Wildcard encoding — the plain non-wildcard entries fail identically.
• DNS / site-side — resolves fine; 403 comes on CONNECT, before the origin.
• Tool-specific — curl and WebFetch fail the same way from the same container.

Happy to supply session IDs or re-test after any change.

Bug report: "Additional allowed domains" not enforced in Cowork sessions

Product / surface: Claude Cowork, desktop app Related existing reports: anthropics/claude-code issue #38984 ("Cowork — 'Additional allowed domains' allowlist non-functional") and #51400 (closed as a duplicate of the same root cause). This report adds a fresh, independent reproduction of the same bug from a different workflow.

Summary

The "Additional allowed domains" field under Organization Settings → Capabilities → Code execution does not take effect. A custom domain added to this allowlist is still blocked by the session's outbound network policy, while the default package-manager domains continue to resolve normally. The only setting that actually changes the behavior is switching to "Allow all domains."

Steps to reproduce
In a Cowork session, publish a design (Claude Design canvas) using the Artifact tool. The published page is served from a per-artifact subdomain of frame.claudeusercontent.com.
In the same session, ask Claude to read the artifact back, or to update/republish it (both require reaching <artifact-id>.frame.claudeusercontent.com).
The request fails with:

"this environment's network allowlist blocks <artifact-id>.frame.claudeusercontent.com... To allow direct artifact reads here, add *.frame.claudeusercontent.com to the environment's allowed domains."

Go to Organization Settings → Capabilities → Code execution, and add *.frame.claudeusercontent.com to Additional allowed domains. Save.
Retry the same read/update in the session (or a fresh session).
Expected behavior

Once *.frame.claudeusercontent.com is added to the allowlist, the session should be able to reach it.

Actual behavior

The domain remains blocked with the identical error message, as if the allowlist entry was never applied.

Impact

Claude cannot safely update a Design Canvas artifact it previously published in the same conversation, because a safe update requires reading the artifact back first (to avoid silently overwriting a newer version someone else saved), and that read is blocked by this bug. The only available workarounds are:

Publishing a brand-new artifact each time instead of updating the existing one, which loses the stable, shareable link.
Manually extracting the live page's HTML from outside the sandbox (e.g. via browser DevTools) and uploading it back into the conversation — unreasonable for routine iterative design work, and in practice difficult for non-technical users to do reliably (cross-origin iframes block a plain "View Source").
Account context
Organization ID: af22a343-a8e7-48ad-8c71-d70983703bd9
Blocked domain in this instance: 04b2f90c-db34-4e7b-90e0-34c4f97db584.frame.claudeusercontent.com

Another instance of this, different domains — same failure pattern.

Setup: Free/Pro/Max plan, personal claude.ai/settings/capabilities (not org/admin-managed). "Allow network egress" enabled, "Domain allowlist" set to "Package managers only," with custom domains added under "Additional allowed domains": boards-api.greenhouse.io, api.lever.co, api.ashbyhq.com, careers.ef.com, jobs.gv.com, and others — bare hostnames, no scheme/path.

Confirmed saved: all domains show correctly in the settings UI after saving and reloading the page.

Result: WebFetch to every one of these domains returns EGRESS_BLOCKED, including the ones explicitly on the allowlist. Started a fresh conversation after the settings change — same result, ruling out session caching. This wasn't checked seconds after saving either — same failure well after the change, so not a propagation-delay issue.

Matches this thread's conclusion exactly: the baseline "Package managers only" domains work, but nothing added via "Additional allowed domains" is actually reaching the enforced allowlist. Happy to provide more repro detail if useful.

Does this setting apply to "Routines" as well? If yes, I still continue to get EGRESS_BLOCKED even after maintaining a domain in here.

I also have observed this issue

[BUG] Cowork cloud sandbox: egress policy ignores org network settings entirely

— allowlisted domains AND "Allow all domains" both 403 at the proxy

Plan: Claude Team/Enterprise, Cowork cloud sandbox.

Summary
The sandbox egress proxy denies all destinations except its built-in package-manager
bypass, regardless of the org's Domain-allowlist setting. Named allowlisted domains
are blocked, and switching the mode to "Allow all domains" does not help — which is
more severe than #38984 (where "Allow all domains" is reported to work).

Egress test from the cloud sandbox (2026-09-11)
| Host | Category | Result |
|---|---|---|
| pypi.org, files.pythonhosted.org | package managers | REACHABLE (200) |
| storage.googleapis.com | on our allowlist | BLOCKED (403 CONNECT) |
| linkedin.com, www.linkedin.com | on our allowlist | BLOCKED (403 CONNECT) |
| www.google.com, example.com | not allowlisted | BLOCKED (403 CONNECT) |

Timeline (same GCS host, same allowlist entry)

• 2026-09-10 ~13:30 UTC: real signed-PUT uploads to storage.googleapis.com returned

200 (many objects incl. one 8.5 MB) — enforcement working.

• 2026-09-10 22:00 UTC onward: 403 at CONNECT, continuously, across 4+ fresh sessions.

Interventions that did NOT restore egress

• Delete + re-add the allowlisted domain (force re-provision).
• Full machine reboot (which also re-applied Windows updates) + fresh session.
• Switching mode "Package managers only" → "Allow all domains" + fresh session.

Error signature
curl: (56) CONNECT tunnel failed, response 403; proxy: connect_rejected — the egress
proxy denied the CONNECT (organization policy), host storage.googleapis.com:443.
The 403 is at the proxy CONNECT — requests never reach Google (not a GCP-side denial;
a control package-manager host on the same proxy succeeds).

Impact (enterprise)
A concurrent regression (device_bash / Plan9 mount broken by Windows KB5124008, #92984)
has forced our estate into degraded mode where the cloud sandbox is the ONLY write path
to our own Cloud Storage. Every persisted memory type routes through one signed upload,
so this stalls the entire memory/register mirror per session and accrues parity debt.
Two Anthropic-side/environment regressions now compound on one estate.

Ask
Restore application of the org Domain-allowlist to the sandbox egress proxy (both named
domains and "Allow all domains"); treat as P1 for enterprise. Session IDs / proxy logs
available privately.

Refs: #38984 (allowlist non-functional — but for us All-domains also fails), #92984.

Confirming this on Windows, and adding a repro that takes my own configuration out of the picture.

Setup: Windows 11 Pro 25H2. Max (individual) plan, with a separate Platform (API) organization on the same account. Mode set to "Package managers only" with several *.example.com style entries saved.

That account shape may be the whole story. Anthropic support confirmed both contexts exist and noted that Cowork's network policy is normally the organization-level setting, resolved when the sandbox is provisioned. A Platform/API org is not a Team seat org, so the allowlist UI may be writing somewhere the provisioning layer never reads. That would explain the package-manager failure too: with no policy resolving, the sandbox would fall back to a bare default instead of the mode's documented baseline. If you are hitting this, please post your plan and org shape — if the failures cluster on non-Team contexts, that locates it.

Same as the original report: every custom entry is refused at the proxy on CONNECT with request blocked: no rule or allowlist entry allows host "<host>".

The addition: the documented package-manager baseline is refused too. pypi.org, files.pythonhosted.org and registry.npmjs.org all return the same 403, in "Package managers only" mode. No custom entry is involved in that one, so it cannot be explained by pattern syntax or by a saved-but-not-applied list. Note this differs from the original report, where package managers worked. That difference seems worth chasing.

It reproduces in both sandboxes, through two different proxies. The cloud container says no rule or allowlist entry allows host. The desktop sandbox (device_bash, localhost:3128) says Connection blocked by network allowlist. Same outcome, different implementation.

Ruled out: session-creation snapshot (a brand new session with the domains already saved reproduces it), pattern syntax (bare and wildcard both), and destination health (the same host answers normally from Claude Code on the same laptop).

Not a blanket block. api.anthropic.com is reachable in both sandboxes and api.github.com in the cloud container, so the allowlist mechanism works. It just does not contain the documented baseline or anything the admin added.

Happy to provide proxy logs or run specific probes.