[BUG] Cowork macOS: local sandbox VM starts with NO network route (only loopback) and cloud egress proxy returns 403 for every domain, despite "Allow network egress: All domains" — regression since 2026-09-10 ~23:15 UTC

Hi all, I'm seeing the same regression and wanted to add another data point in case it helps narrow down the timing.

Setup: individual Max plan, Claude desktop app on Windows, Cowork cloud sessions. Settings > Capabilities > Domain allowlist is "Package managers only" plus additional domains (including *.googleapis.com). Claude chat with the same settings still works normally.

When it started: I have an hourly scheduled Cowork task that calls Google and Windsor APIs, and it gives a clean before/after:

• 2026-09-10 22:09 UTC run: completed normally (finished 22:16 UTC)
• 2026-09-10 23:10 UTC run: halted on its first network call, oauth2.googleapis.com:443 rejected with 403 on CONNECT
• 00:10, 01:08 and 02:09 UTC runs: same rejections

So for me it broke between 22:16 and 23:10 UTC on September 10. The good run and the failed runs all ran in Anthropic's cloud environment (container version 2.1.268 on the latest run).

What the cloud container shows now:

• Rejected with "gateway answered 403 to CONNECT (policy denial or upstream failure)": connectors.windsor.ai, api.windsor.ai, www.googleapis.com, oauth2.googleapis.com, googleads.googleapis.com, drive.google.com, docs.google.com, raw.githubusercontent.com, api.netlify.com, example.com
• pypi.org returns 403 with the body "Host not in allowlist: pypi.org", even though it's a package-manager domain (the reports above show pypi.org returning 200, so that part differs for me)
• github.com and api.github.com still get through

Separately, the local workspace on Windows fails with the September 8 Windows update message from the status page incident, so neither path works for me right now.

Could someone from Anthropic confirm whether this is being tracked? I'm happy to share session IDs privately if that would help.

Thanks!

Thanks @thewafflethief — that matches my timeline exactly. On macOS the last good session here was ~23:15 UTC on 09-10; everything after that (new sessions, relink, toggling the egress setting, full reinstall) comes up with no route in the local sandbox and 403 on CONNECT from the cloud proxy. Re-checked just now (2026-09-11 02:45 UTC): still broken on both paths. Two independent accounts (Max individual, macOS + Windows) breaking in the same ~1h window, with the setting still showing "All domains" / allowlist, points to a server-side egress policy change rather than anything client-side. I also have a support conversation open (Fin ID 215475892645145) and the AI responder already acknowledged a "platform-side" issue but could not escalate. Would appreciate confirmation from Anthropic that this is tracked.

Same here: macOS (Apple Silicon), Cowork, Allow network egress ON with Domain allowlist "All domains". Broken since 2026-09-11 (UTC) on both paths:

• Cloud container: only api.github.com / github.com / api.anthropic.com get through. pypi.org and registry.npmjs.org return 403 with x-deny-reason: host_not_allowed, and the proxy status shows connect_rejected for everything else.
• Local VM (device_bash): 403 from proxy after CONNECT for every host except api.anthropic.com, including self-hosted internal hosts that worked from the same setup on 2026-09-10.

The in-app browser pane is unaffected.

Another macOS report with the identical fingerprint, adding it since the reports so far are 1x macOS + 1x Windows.

Setup: macOS (Apple Silicon), Claude desktop app, Cowork cloud session linked to the Mac. Settings > Capabilities > Allow network egress: ON, Domain allowlist: "All domains" (UI confirms "Claude can access all domains on the internet"). Verified in the UI while the failure was active, unchanged for weeks.

Cloud container, measured 2026-09-11 11:09 UTC, identical to a run at 10:30 UTC:

api.github.com 200 reachable
api.anthropic.com 404 reachable
pypi.org 403 x-deny-reason: host_not_allowed
files.pythonhosted.org 403 same
registry.npmjs.org 403 same
googleads.googleapis.com CONNECT tunnel failed, 403
oauth2.googleapis.com CONNECT tunnel failed, 403
graph.facebook.com CONNECT tunnel failed, 403
api.openai.com CONNECT tunnel failed, 403
www.google.com CONNECT tunnel failed, 403
example.com CONNECT tunnel failed, 403
raw.githubusercontent.com CONNECT tunnel failed, 403

Exactly the three-host list @spde describes. example.com being denied is the cleanest tell that this is a blanket policy denial rather than anything service-specific.

device_bash (local VM on the Mac) is on the same policy and returns the same 403s, so "run it locally" is not a workaround. The in-app browser pane and MCP connectors are unaffected, which is consistent with them not traversing the sandbox proxy.

A second account on a separate plan, same skills, different credentials, hit the identical failure in the same window on 2026-09-11 and also had it working earlier that day. No setting was changed on either side.

Impact: every skill that calls a third-party API is dead. Google Ads API, Meta Graph API, OpenAI API. These are production advertising workflows.

Nothing on status.claude.com covers this; the only open Cowork incident is the September 8 Windows one, which is a different failure. Happy to provide session IDs privately.

Workaround that restored my workflow: Claude Code CLI on the Mac itself, same Max subscription, no Cowork sandbox — egress is the machine's own network, so SSH, tunnels and third-party APIs all work again.

Steps: (1) curl -fsSL https://claude.ai/install.sh | bash, then run claude and pick "Claude account with subscription"; (2) cd into the project/knowledge folder that already has a CLAUDE.md — Claude Code reads it on start, so the "brain" is the same one Cowork used; (3) copy your Cowork skills to ~/.claude/skills/<name>/SKILL.md; (4) stop the per-command permission prompts with ~/.claude/settings.json: {"permissions": {"defaultMode": "acceptEdits", "allow": ["Read","Edit","Write","Bash(*)","WebFetch"], "deny": ["Bash(rm -rf /*)", "Read(**/.env)"]}}.

First test: booted from CLAUDE.md, SSH'd into a Windows VPS through a Linux jump host and read a production config in under 4 minutes. The only Cowork pieces I'm still missing are the connectors and scheduled tasks (moving them to MCP + cron). Still want the Cowork egress fixed, but this unblocks work today.

Via Claude Code. It also works for me, regardless of whether from CLI or from the app. It's just an issue with an old cowork, I guess.

Another data point — Windows, cloud container only, no local VM in the loop. Two things here look new to this thread.

Earliest hard timestamp so far: 2026-09-10T22:14:10Z. From the container's own proxy log:

{"ts":"2026-09-10T22:14:10.076Z","kind":"connect_rejected",
 "detail":"gateway answered 403 to CONNECT (policy denial or upstream failure)",
 "host":"oauth2.googleapis.com:443"}

That sits just ahead of thewafflethief's bracket (good run finishing 22:16 UTC, next run failing by 23:10). If their 22:09 run made its network calls early in the run, the two are consistent; if not, the rollout was staggered across containers rather than flipped everywhere at once.

It broke under a container that was already running — mid-process, not at provisioning.

This is where our case differs from every report above, which are all "every new session comes up broken." Ours was a long-lived cloud session doing real Google Workspace work as a domain-wide-delegated service account: spreadsheets.batchUpdate structural writes, Docs reads, Drive uploads, all succeeding. The same calls began failing at 22:14:10Z with no new container, no session restart, no settings change and no credential change — the same process kept running straight across the transition, succeeding minutes before and refused after. Still denied 15+ hours later.

So on the cloud path the policy is being evaluated per request, not stamped onto the container at provisioning. #93525's repro notes warn that a stale container keeps its old policy and that you must therefore test only in a freshly provisioned one — that was not true here, and it's worth knowing for anyone trying to correlate the onset against a rollout.

The pypi.org disagreement in this thread has a mundane explanation.

goldenwhaleai sees pypi.org returning 200 while thewafflethief, spde and DennisOmmer90 see 403. Both are correct. pypi.org, files.pythonhosted.org, registry.npmjs.org, index.crates.io, proxy.golang.org and api.anthropic.com sit in the container's no_proxy list, so requests to them take a direct path and never reach the CONNECT gateway to be judged. Whether you see 200 or 403 depends on whether the direct path is filtered as well — i.e. which of the two enforcement points your container has. Here pypi returns 200, and everything that actually traverses the proxy returns 403.

The practical consequence cost me several hours: "package installs still work" is not evidence that the allowlist is intact. I concluded from exactly that signal that this was a Google-specific block. It isn't. curl https://example.com/ through the proxy is the honest one-line probe — which is why DennisOmmer90's point about example.com is the right diagnostic.

For anyone chasing credentials: the tunnel is refused before TLS, so no token, key, scope or connector change can influence it. An unauthenticated request gets the identical 403. Revoking and reconnecting integrations is wasted effort on this one.

Impact matches the other reports, scheduled tasks included — ours reads Google Sheets daily and now dies on its first call — while chat, WebFetch and WebSearch stay perfectly healthy because they route separately. That split is what makes this so easy to misdiagnose.

Still broken as of 2026-09-11T13:18Z.

Update: this has cleared on my account. My hourly scheduled task ran successfully at 19:11 UTC today, and my other Cowork sessions are working again.

Confirming recovery here too (macOS, the original report): at 22:19 UTC on 2026-09-11 the local sandbox came up with a default route again (ip route populated, ping OK, SSH to the VPS on port 22 OK) and the cloud container's proxy now returns 200 for www.google.com and my own tunnelled host. No client change on my side — same app build, same settings. So the outage window for this account was ~23:15 UTC 09-10 → ~22:19 UTC 09-11 (about 23 hours). Leaving the issue open for a root-cause note from Anthropic, since nothing appeared on the status page and the setting was being ignored the whole time.