[BUG] Cowork — "Additional allowed domains" allowlist non-functional
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Description:
The "Additional allowed domains" field under Organization Settings → Capabilities → Code execution with "Domain allowlist" set to "Package managers only" appears to have no effect. All custom domain entries are silently ignored by the sandbox proxy. Network egress to allowed domains is
What we tried:
Added every variation: *.docs.google.com, docs.google.com, *.google.com, google.com — none worked
Started fresh Cowork sessions after each change
"Allow all domains" works correctly (immediately after setting and restarting Claude Cowork, so it's also not a caching issue), confirming the infrastructure is fine
_Working:_
curl https://pypi.org/ → 200
curl https://github.com/ → 200
_Blocked (403 from proxy / no response):_
curl https://docs.google.com/ → blocked
curl https://google.com/ → blocked
curl https://www.google.com/ → blocked
Again, all of these blocked curls work as soon as "All domains" are allowed, so it's not an infra issue.
Conclusion:
The "Package managers only + additional domains" mode works for the baseline, but custom entries added via the UI are never applied. The field appears broken.
What Should Happen?
Network egress is allowed to allowed domains in whitelist
Error Messages/Logs
Steps to Reproduce
- In Admin Settings → Capabilities → Code execution, set domain allowlist to "Package managers only" and add one or more custom domains (e.g. google.com, *.google.com, docs.google.com)
- Start a new Cowork session
- Run the following curl commands:
These work (package manager baseline):
curl https://pypi.org/ # → 200
curl https://github.com/ # → 200
# These are blocked despite being in the allowlist:
curl https://google.com/ # → blocked
curl https://www.google.com/ # → blocked
curl https://docs.google.com/ # → blockedClaude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude 1.1.8629 (befdfc) 2026-03-24T22:13:01.000Z
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
Claude Cowork
Showing cached comments. Read the full discussion on GitHub ↗
6 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 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.
I tested this the egress only works for the
ownerof the org, a standarduseris 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.comandscript.googleusercontent.com. Both domains have been in my allowlist for over a month and were working fine until recently.Environment:
script.google.com,script.googleusercontent.comSymptoms:
The domains are confirmed present in the allowlist UI. No changes were made on my end.
Timeline:
host_not_allowedconfirmedThis 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.