›_ Claude Code Issues
Claude Code Issues / #30861

[BUG] Cowork macOS: MITM egress proxy blocks all non-API domains regardless of allowlist settings

Status Open
Maintainer reply None cached
Activity 10 comments · opened Mar 4, 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?

Cowork's MITM egress proxy blocks all non-API domains regardless of the network egress allowlist configuration. The VM itself boots and connects successfully — the API is reachable — but all other web requests (WebSearch, WebFetch, curl) are rejected by the proxy with blocked-by-allowlist.

This is not a network/connectivity issue. The VM has full network access to Anthropic's API. The proxy is selectively blocking everything else, and no combination of allowlist settings changes this behaviour.

Environment

  • Claude Desktop 1.1.4328 (d8e391) 2026-02-25T17:04:36.000Z
  • macOS (Apple Silicon)
  • Pro plan
  • No VPN, no third-party firewall, no network extensions

What Should Happen?

Domains added to the egress allowlist (or "All domains") should be permitted through the MITM proxy. WebSearch and WebFetch tools should work in Cowork.

Error Messages/Logs

### Error Messages/Logs

From `cowork_vm_node.log` — VM boots and connects fine:

2026-02-26 22:07:21 [info] [VM] Network status: CONNECTED
2026-02-26 22:07:22 [info] [VM] API reachability: REACHABLE
2026-02-26 22:07:22 [info] [VM:start] Startup complete, total time: 5444ms


The spawn config shows `allowedDomains=23`, which does not correspond to any setting I have configured.

From Cowork session, when asked to reach google.com:
> "No luck — google.com is blocked by the network egress proxy. So internet access isn't available right now."

Steps to Reproduce

Steps to Reproduce

  1. Open Claude Desktop Settings → Capabilities
  2. Enable "Allow network egress"
  3. Set domain allowlist to "All domains" (or any custom domain list)
  4. Quit Claude Desktop (Cmd+Q), reopen
  5. Open a new Cowork session
  6. Ask Cowork to search the web or fetch any non-Anthropic URL
  7. All requests fail — blocked by egress proxy

Troubleshooting Already Performed

  • Tried "All domains" — blocked
  • Tried "Package managers only" + manually adding google.com — blocked
  • Deleted ~/Library/Application Support/Claude/vm_bundles/, let VM rebuild from scratch — blocked
  • Full quit and reopen between every settings change — blocked
  • Verified no VPN, no network extensions (System Settings → Login Items & Extensions → Network Extensions is empty)
  • macOS firewall is off
  • Confirmed egress settings are not stored in claude_desktop_config.json or config.json on disk — they appear to be server-side or JWT-embedded, which may explain why local changes have no effect

Related Issues

  • #30112 — identical symptoms, marked invalid and duplicate-chained to #11897 which is a different platform (web sandbox, not Cowork desktop VM)
  • #21706 — "All domains" sets a * pattern that the app's own validation rejects
  • #18854 — MITM proxy blocking api.anthropic.com (same proxy, different domain)
  • #19087 — additional allowed domains not included in JWT allowlist

The common thread across all of these is that the MITM proxy inside the Cowork VM does not respect the allowlist configuration set in the UI. #30112 was closed as invalid ("not related to Claude Code") — but there is no other repo to file Cowork bugs against. If there is a better channel, please redirect rather than close.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.1.4328 (Cowork)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

The allowedDomains=23 value in the spawn config is the key clue — the proxy is receiving a domain list, but either the list doesn't contain the right domains, or the proxy is ignoring it. The fact that this value doesn't change regardless of UI settings suggests the configuration pipeline from UI → server → JWT → VM proxy is broken somewhere upstream of the VM itself.

cowork_vm_node.log

View original on GitHub ↗

10 Comments

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/30112
  2. https://github.com/anthropics/claude-code/issues/23818
  3. https://github.com/anthropics/claude-code/issues/21706

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

gethooo · 5 months ago

the egress setting is being overwritten by the online account settings. When i manually change the setting in config.json to true, as soon as I go online it is flipping to false. My online settings also allow network egress, all domains

But nobody will see this because its been set to invalid again. Where are we supposed to post cowork bugs then?

neddy · 5 months ago

Yeah, I agree, this is annoying and is stopping me from being able to do work...

pebblesdt · 5 months ago

please fix asap, bad searching experience all together

hooolio · 4 months ago

@MarshallOfSound could you please take a look at this issue?

You were assigned to #18854 which involves the same Cowork MITM egress proxy. Wondering if you could take a look at this one?

The config pipeline between admin UI egress settings and the proxy JWT appears broken -- "all domains" and custom domain allowlists have no effect on what the proxy enforces.

Also, is there a better place to file Cowork-specific bugs? The github-actions bot keeps marking these as "invalid" since there's no separate Cowork repo.

Thanks for your time!
Aaron

ombreze · 4 months ago

WebFetch test in Cowork — April 11, 2026

Confirming #30861 is still reproducible two months after the initial report. Tested 10 public sites via WebFetch in a single Cowork session with default settings.

| Domain | Result |
|---|---|
| anthropic.com | ✅ works |
| github.com | ✅ works |
| wikipedia.org | ❌ EGRESS_BLOCKED |
| facebook.com | ❌ EGRESS_BLOCKED |
| google.com | ❌ EGRESS_BLOCKED |
| netlify.com | ❌ EGRESS_BLOCKED |
| lemonde.fr | ❌ Claude Code is unable to fetch from... |
| vogue.com | ❌ Claude Code is unable to fetch from... |
| nytimes.com | ❌ Claude Code is unable to fetch from... |
| reddit.com | ❌ Claude Code is unable to fetch from... |

Two distinct failure modes:

  1. Proxy egress block (Wikipedia, Facebook, Google, Netlify) — matches #30861 exactly. The MITM proxy rejects these domains regardless of allowlist settings.
  2. Generic "unable to fetch" (Le Monde, Vogue, NYT, Reddit) — different error shape, no explanation. All four are news/media sites. This may be a separate tool-level restriction not covered by #30861.

Notes:

  • GitHub passing while Wikipedia fails suggests the default allowlist is non-empty but arbitrarily narrow.
  • User impact is high: Cowork is effectively unusable for any task that involves reading mainstream web content.
  • If the second failure mode is an intentional restriction, the error message should say so explicitly.
hannahmckeand · 3 months ago

Same issue, macOS, All domains setting has no effect

JayWatHL · 3 months ago

Adding a fresh repro on macOS Cowork as of 2026-05-08 — this is closely related to #37824 (closed two days ago) but the symptom is back / never went away for new scheduled tasks on my install.

Working — task SKILL at ~/Documents/Claude/Scheduled/<old-task>/SKILL.md (created earlier this year). From its scheduled-run bash sandbox:

$ curl -v --proxy http://localhost:3128 https://<company>.cloud.looker.com/
< HTTP/1.1 200 OK

Failing — task SKILL at ~/Desktop/Shared with Claude/Scheduled Tasks/<new-task>/SKILL.md (created via create_scheduled_task today). Same curl command, same target host, same Cowork install:

$ curl -v --proxy http://localhost:3128 https://<company>.cloud.looker.com/
< HTTP/1.1 403 Forbidden
< X-Proxy-Error: blocked-by-allowlist

The proxy at localhost:3128 is socat tunneling to /sessions/<session>/tmp/claude-http-*.sock, so the allowlist enforcement is happening on the host side of that Unix socket — i.e. inside the Cowork desktop app, not in the sandbox itself.

What I tried that didn't change behavior:

  • Removing ~/Downloads from the failing task's Working folders panel.
  • Creating fresh tasks in fresh folders under ~/[Shared with Claude folder]/.
  • Manually re-running the task multiple times.
  • Comparing every visible knob in the Cowork UI between the working and failing task pages — Connectors panel, Skills, Working folders. The Connectors panel shows the same single Chrome — Browser 1 entry on both, so whatever's gating egress isn't surfaced in the per-task UI on my install.

What I think is happening, based on this issue + #23818 + #37824: the per-session JWT contains a hardcoded host allowlist that ignores user/admin "Allowed domains" settings. Tasks created before the most recent allowlist change have JWTs that include this host; tasks created after don't. Same target host, same workspace, same machine — only difference is when the task was registered.

Repro: create any scheduled task today via create_scheduled_task — it lands at ~/[Shared with Claude folder]/Scheduled Tasks/<taskId>/SKILL.md and its scheduled-run bash sandbox returns 403 blocked-by-allowlist on curl --proxy http://localhost:3128 https://<any-non-Anthropic-domain>/, while older scheduled tasks at ~/Documents/Claude/Scheduled/ hitting the same host through the same proxy return 200.

Wahacer · 3 months ago

Same issue, macOS, All domains setting has no effect

lcampbell33 · 3 months ago

+1 on hitting this. Affects all Cowork/scheduled-task egress to non-API domains.

Config that did NOT resolve it:

  • Claude Desktop → Settings → Capabilities → "Allow network egress" = ON
  • Domain allowlist = "All domains"
  • macOS Privacy & Security → Full Disk Access → all "claude" entries toggled ON
  • ~/.claude/settings.json → sandbox.allowedDomains = ["dream-clean-team.vercel.app"]
  • Restarted Claude Desktop after each change

Log line (consistent across attempts):
HTTP/1.1 403 Forbidden
X-Proxy-Error: blocked-by-allowlist

Hits this on POST to dream-clean-team.vercel.app (a Vercel-hosted Next.js app under my own org). Same request from regular curl outside the Cowork sandbox succeeds. api.anthropic.com and github.com both reachable from inside the same Cowork session, so the proxy itself is working — appears to be allowlist-evaluation that's broken.

macOS 14.x / Claude Desktop latest. Happy to send a HAR or strace if useful.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

This issue appears in the ranked issue list on these topic pages, alongside a backlog trend for the whole topic.

IDE & terminal integration →Network & proxy errors →

Browse all Claude Code issue topics →