[BUG] [Cowork] sandbox.network.allowedDomains ignored — external APIs blocked (api.zotero.org, crossref.org, etc.)

Status Open
Reported on v2.1.78
Maintainer reply None cached
Activity 6 comments · opened Mar 23, 2026

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

  1. Open Claude Cowork (desktop app) and start a session with any project folder
  2. 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"

  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
  1. Create .claude/settings.json in the project folder with:
{
  "sandbox": {
    "network": {
      "allowedDomains": ["api.zotero.org", "*.zotero.org"]
    }
  }
}
  1. Ask Claude to retry the same curl command — still returns 403.

Project-level allowedDomains has no effect.

  1. Ask Claude to run env | grep -i proxy and ss -tlnp to 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_

View original on GitHub ↗

6 Comments

mojo-elaichi · 6 months ago

Plus 1

nicolasc-1 · 6 months ago

Plus 1

seigenwillig · 6 months ago

Plus 1

msmobileapps · 5 months ago

+1 — hitting this hard on macOS Cowork with api.github.com specifically. Adding concrete data because the three +1s above are all Windows/WSL and this issue is labeled has repro already, so what's missing is cross-platform signal and an agent/plugin-level repro.

Environment

  • Platform: macOS 14.x, Claude Cowork desktop (not WSL)
  • VM: Linux sandbox, egress forced through http://localhost:3128
  • Scheduled-task runtime (not interactive) — this is how MSApps runs daily ops

Identical failure signature

$ curl -v --max-time 5 https://api.github.com/
> CONNECT api.github.com:443 HTTP/1.1
< HTTP/1.1 403 Forbidden
< X-Proxy-Error: blocked-by-allowlist

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.json with sandbox.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 gh health 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 because gh itself talks to api.github.com. No amount of re-installing the binary (apt, tarball, go install) fixes it: the network policy blocks the endpoint gh depends on. sudo is also broken in the VM (/etc/sudo.conf uid/ownership) so even apt isn't usable.

We've been forced to route every gh invocation 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.com specifically matters for Cowork

  • It's gh's only API endpoint — no workaround at the binary level
  • It's how virtually every GitHub-related agent, skill, and plugin in the marketplace reads repo state
  • github.com already being allowlisted while api.github.com isn't creates a confusing half-open state: git clone works, but gh repo list doesn't
  • The docs at https://docs.claude.com/en/docs/claude-code/sandboxing list github.com and api.github.com as commonly-used domains Claude Code supports — so the Cowork divergence from standard Claude Code here is especially surprising

Minimum ask (in priority order)

  1. Add api.github.com, raw.githubusercontent.com, codeload.github.com to the Cowork managed allowlist — they're non-controversial and match what standard Claude Code already supports.
  2. Fix the broader bug (this issue's actual title): make project-level sandbox.network.allowedDomains respected 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.

msmobileapps · 5 months ago

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 push to github.com (which IS on the allowlist) as transport. VM-side is a 119-line POSIX bash shim — no gh, 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 api call 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.

csmykay · 5 months ago

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.