[BUG] [Cowork] sandbox.network.allowedDomains ignored — external APIs blocked (api.zotero.org, crossref.org, etc.)
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?
Summary
In Cowork mode, the sandbox proxy blocks all external API calls that are not on Anthropic's managed allowlist. Project-level sandbox.network.allowedDomains settings are completely ignored, making it impossible for users to add domains they need (e.g. Zotero, CrossRef, OpenAlex).
Environment
- Product: Claude Cowork (desktop app)
- VM: Linux (Ubuntu 22, bubblewrap sandbox)
- Network: only loopback interface (127.0.0.1), all traffic via socat proxies on :3128 (HTTP) and :1080 (SOCKS5)
Reproduction
Any outbound API call to a domain not in Anthropic's managed allowlist fails with:
HTTP/1.1 403 Forbidden
X-Proxy-Error: blocked-by-allowlist
Example:
curl -v --proxy "http://localhost:3128" "https://api.zotero.org/users/.../items"
# → HTTP 403 — X-Proxy-Error: blocked-by-allowlist
What I tried
Created .claude/settings.json in the project with:
{
"sandbox": {
"network": {
"allowedDomains": ["api.zotero.org", "*.zotero.org"]
}
}
}
→ No effect. The proxy still returns 403.
This is consistent with allowManagedDomainsOnly: true being set in Cowork's managed settings, which per the docs causes "Domains from user, project, and local settings are [to be] ignored."
Domains currently blocked (confirmed)
| Domain | Status |
|---|---|
| api.zotero.org | ❌ 403 blocked |
| crossref.org | ❌ 403 blocked |
| openalex.org | ❌ 403 blocked |
| semanticscholar.org | ❌ 403 blocked |
| api.github.com | ❌ 403 blocked |
| unpaywall.org | ❌ 403 blocked |
Domains that work
| Domain | Status |
|---|---|
| github.com | ✅ 200 |
| pypi.org | ✅ 200 |
| api.anthropic.com | ✅ accessible |
What Should Happen?
Respect project/user allowedDomains (preferred)
When a user adds domains to sandbox.network.allowedDomains in their project .claude/settings.json, those domains should be reachable from the Cowork VM,
exactly as they are in standard Claude Code.
// .claude/settings.json
{
"sandbox": {
"network": {
"allowedDomains": ["api.zotero.org", "crossref.org"]
}
}
}
After adding this file, curl https://api.zotero.org/... should succeed instead
of returning 403 blocked-by-allowlist.
In standard Claude Code, this already works: accessing a new domain triggers a
user-facing prompt ("Allow api.zotero.org?"), and the user can permanently allow
it. Cowork skips that prompt entirely and silently blocks everything — no
notification, no way to whitelist.
Why this matters
Cowork is explicitly positioned as a tool for research and writing workflows.
Blocking all academic APIs while providing no mechanism for users to add trusted
domains creates a hard wall against the primary use case. Users are forced to run
workaround scripts locally outside Cowork, which defeats the purpose of the
agentic integration.
Standard Claude Code handles this gracefully with a permission prompt. Cowork
should offer at minimum an equivalent mechanism.
Error Messages/Logs
Steps to Reproduce
Steps to reproduce
- Open Claude Cowork (desktop app) and start a session with any project folder
- Ask Claude to run the following bash command:
> "Run this command: curl -v --max-time 10 https://api.zotero.org/users/6269472/items?limit=1"
- Claude executes it internally and returns:
* Uses proxy env variable https_proxy == 'http://localhost:3128'
* Trying 127.0.0.1:3128...
* Connected to (nil) (127.0.0.1) port 3128 (#0)
* Establish HTTP proxy tunnel to api.zotero.org:443
> CONNECT api.zotero.org:443 HTTP/1.1
> Host: api.zotero.org:443
> User-Agent: curl/7.81.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 403 Forbidden
< Content-Type: text/plain
< X-Proxy-Error: blocked-by-allowlist
* Received HTTP code 403 from proxy after CONNECT
* CONNECT phase completed!
* Closing connection 0
curl: (56) Received HTTP code 403 from proxy after CONNECT
- Create
.claude/settings.jsonin the project folder with:
{
"sandbox": {
"network": {
"allowedDomains": ["api.zotero.org", "*.zotero.org"]
}
}
}
- Ask Claude to retry the same curl command — still returns 403.
Project-level allowedDomains has no effect.
- Ask Claude to run
env | grep -i proxyandss -tlnpto confirm:
- All traffic is forced through socat proxies on localhost:3128 (HTTP) and localhost:1080 (SOCKS5)
- The VM has no network interface other than loopback (127.0.0.1)
- The HTTP proxy enforces a strict allowlist with no user-configurable mechanism to extend it
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude Code version 2.1.78
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
WSL (Windows Subsystem for Linux)
Additional Information
_No response_
6 Comments
Plus 1
Plus 1
Plus 1
+1 — hitting this hard on macOS Cowork with
api.github.comspecifically. Adding concrete data because the three +1s above are all Windows/WSL and this issue is labeledhas reproalready, so what's missing is cross-platform signal and an agent/plugin-level repro.Environment
http://localhost:3128Identical failure signature
Host probe on our sandbox (today, 2026-04-20), confirms the allowlist shape described in the OP:
| Host | VM result |
|------|-----------|
|
github.com| ✅ 200 ||
objects.githubusercontent.com| ✅ reachable ||
api.github.com| ❌ 403 blocked-by-allowlist ||
raw.githubusercontent.com| ❌ 403 blocked-by-allowlist ||
release-assets.githubusercontent.com| ❌ 403 blocked-by-allowlist ||
codeload.github.com| ❌ 403 blocked-by-allowlist ||
proxy.golang.org| ❌ 403 blocked-by-allowlist ||
cli.github.com,packages.cli.github.com| ❌ 403 blocked-by-allowlist |.claude/settings.jsonwithsandbox.network.allowedDomains: ["api.github.com"]has no effect, same as the OP.Concrete agent-level repro (public plugin)
We ship a public Claude plugin that runs a daily
ghhealth check as a scheduled task:https://github.com/MSApps-Mobile/claude-plugins/tree/main/plugins/github-cli-health-check
Every automation step —
gh auth status,gh repo list,gh api rate_limit— fails inside the Cowork VM becauseghitself talks toapi.github.com. No amount of re-installing the binary (apt, tarball,go install) fixes it: the network policy blocks the endpointghdepends on.sudois also broken in the VM (/etc/sudo.confuid/ownership) so even apt isn't usable.We've been forced to route every
ghinvocation through the Desktop Commander MCP (running on the host Mac, outside the sandbox), which defeats the purpose of the agentic integration — scheduled tasks shouldn't need a host-side MCP to reach GitHub.Why
api.github.comspecifically matters for Coworkgh's only API endpoint — no workaround at the binary levelgithub.comalready being allowlisted whileapi.github.comisn't creates a confusing half-open state:git cloneworks, butgh repo listdoesn'tgithub.comandapi.github.comas commonly-used domains Claude Code supports — so the Cowork divergence from standard Claude Code here is especially surprisingMinimum ask (in priority order)
api.github.com,raw.githubusercontent.com,codeload.github.comto the Cowork managed allowlist — they're non-controversial and match what standard Claude Code already supports.sandbox.network.allowedDomainsrespected in Cowork, or surface the interactive permission prompt that standard Claude Code uses.Happy to provide a full session transcript of the diagnostic run if useful.
Ran into this while building a Cowork agent that wires into GitHub. Built a workaround for anyone else blocked on it:
https://github.com/MSApps-Mobile/gh-bridge
Uses GitHub Actions as an HTTPS-to-API proxy, with
git pushtogithub.com(which IS on the allowlist) as transport. VM-side is a 119-line POSIX bash shim — nogh, no Python, no special setup beyond a PAT and a private bridge repo. ~15–35s round-trip per call.Verified end-to-end from inside the Cowork VM sandbox against a real
gh apicall this week on Claude Code v2.1.114.Happy to delete the repo the moment this issue closes. Would love an ETA — the block meaningfully constrains what agents can do from inside the VM, and is one of the larger gaps between the Cowork and Routine runtimes.
This is just silly, I just paid for a new subscription for Claude Teams and I can't even use Co-work to communicate with external sites because of this proxy feature. I thought this was ready for the main stage.