[BUG] Cowork cloud sessions ignore "Allow network egress: All domains" and enforce a narrow built-in allowlist; all third-party API calls from scripts fail (403 at CONNECT) on both the cloud shell and the local VM shell

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?

Product: Claude Cowork (desktop app, Windows) running cloud sessions linked to the local computer
Platform: Windows 11, Claude Desktop app, cloud sessions
Session where the evidence below was collected: session_0197JESTAvV1oMzCqDJX1y3G
First observed: Wednesday, September 9, 2026, approximately 2:55 PM Pacific
Still reproducing: Friday, September 11, 2026 (every session since)
Labels requested: area:cowork, area:networking, bug, has-repro, platform:windows, regression

Summary

Since the afternoon of September 9, 2026, every Cowork session on this account refuses outbound HTTPS connections to any host outside a small built-in allowlist. Only GitHub gets through. The account's network egress setting is "Allow network egress: ON, Domain allowlist: All domains" and has been for the entire period. It was set that way on the morning of September 9 when the same scripts, in the same project, reached the same hosts without error. Nothing on the user side changed.

The block applies to both execution paths a Cowork session has:

1. The cloud container shell (Anthropic-hosted VM).
2. The local device_bash shell running inside the Cowork VM on the user's own Windows machine, which is routed through the same egress policy even though the machine itself has unrestricted internet.

The practical effect is that a Cowork session can no longer run any script that calls a third-party API. Every script-driven integration in every project on this account (a CRM API at services.leadconnectorhq.com, a billing API at api.voipbills.com, and pip for dependencies) fails at the proxy before the request leaves the session.

Toggling the egress setting off and on, and cycling the allowlist from All domains to None and back, did not change the behavior.

This matches a cluster of open, unanswered issues going back to March 2026 that report the "All domains" setting not being honored by the Cowork egress proxy. The difference here is a clean before/after on a single account with no configuration change, which points at a server-side regression on or about September 9.

Environment

| Item | Value |
|---|---|
| Client | Claude Desktop app for Windows, Cowork mode |
| Session type | Cloud session, linked to local computer |
| Cloud shell | Linux container, outbound via agent proxy at 127.0.0.1:42469, CA bundle /root/.ccr/ca-bundle.crt |
| Local shell | device_bash inside the Cowork Hyper-V VM on the Windows machine, a connected local folder |
| Egress setting (desktop app) | Allow network egress: ON. Domain allowlist: All domains |
| Egress setting (claude.ai in browser) | Same, All domains |
| Windows update KB5124008 | Was installed, then uninstalled and verified absent (separate, already-known Cowork sandbox bug). Local VM boots and mounts folders normally. Not a factor here. |
| MCP connectors | Continue to work (they route through Anthropic's servers, not the session egress) |

Timeline

| When (Pacific) | What |
|---|---|
| Sept 9, morning through ~2:55 PM | Same project, same session type, same egress setting. CLI package installed via pip, CRM API and billing API both reachable from both shells. Migration work in progress (custom fields created, 341 billing records pulled and analyzed). |
| Sept 9, ~2:55 PM | Mid-session, every CONNECT starts returning 403 from both shells. No user action preceded it. |
| Sept 9, evening | Local Cowork VM also lost folder mounts (no Plan9 drive shares mounted). Traced to Windows update KB5124008 (separate bug, GitHub #92984). |
| Sept 10 | KB5124008 uninstalled, verified absent, rebooted. Local VM mounts folders again. Egress still blocked. |
| Sept 11, 12:50 AM onward | Fresh sessions. Egress blocked from the first request. GitHub 200, everything else 000/403. |
| Sept 11, ~1:55 AM | User toggles egress off/on, allowlist None then All domains. Retest: unchanged. |
| Sept 11 | Cloud environment at claude.ai also shows All domains. Unchanged from before. |

A new session does not clear it. This is not a per-session glitch.

What Should Happen?

All five hosts return a real HTTP status (200, 301, 401, 404, anything from the origin), because the allowlist is set to All domains and the UI says "Claude can access all domains on the internet."

And more generally: the session egress gateway should honor the account's egress setting (All domains / Custom list) on both the cloud container shell and the local Cowork VM shell, instead of enforcing a fixed built-in allowlist. See Requested action under Additional Information.

Error Messages/Logs

Only `api.github.com` connects. Every other host fails at the CONNECT stage and never reaches the origin.

**Cloud shell, 2026-09-11 01:10 UTC:**

https://api.github.com/                       200
https://www.google.com/                       000
https://example.com/                          000
https://api.openai.com/                       000
https://services.leadconnectorhq.com/         000


**Cloud shell, 2026-09-11 02:05 UTC (after the user toggled egress off/on and allowlist None/All domains):**

https://services.leadconnectorhq.com/    000
https://api.voipbills.com/               000
https://pypi.org/simple/click/           403
https://api.github.com/                  200


**Local `device_bash` shell, same time:**

https://services.leadconnectorhq.com/    000
https://api.voipbills.com/               000
https://pypi.org/simple/click/           000

(`curl` exit code 56, "Failure with receiving network data": the CONNECT was refused.)

**Agent proxy status (`/__agentproxy/status`), excerpt:**

{
 "enabled": true,
 "selective": false,
 "standalone": false,
 "toolScoped": false,
 "recentRelayFailures": [
  {"ts": "2026-09-11T01:03:54.240Z", "kind": "connect_rejected",
   "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
   "host": "services.leadconnectorhq.com:443"},
  {"ts": "2026-09-11T01:03:54.512Z", "kind": "connect_rejected",
   "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
   "host": "api.voipbills.com:443"},
  {"ts": "2026-09-11T01:10:52.648Z", "kind": "connect_rejected",
   "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
   "host": "www.google.com:443"},
  {"ts": "2026-09-11T01:10:52.917Z", "kind": "connect_rejected",
   "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
   "host": "example.com:443"},
  {"ts": "2026-09-11T01:10:53.196Z", "kind": "connect_rejected",
   "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
   "host": "api.openai.com:443"},
  {"ts": "2026-09-11T02:05:37.333Z", "kind": "connect_rejected",
   "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
   "host": "services.leadconnectorhq.com:443"},
  {"ts": "2026-09-11T02:05:37.586Z", "kind": "connect_rejected",
   "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
   "host": "api.voipbills.com:443"}
 ]
}


**Verbose curl showing the refusal happens at the proxy, before TLS to the origin:**

* Establish HTTP proxy tunnel to services.leadconnectorhq.com:443
> CONNECT services.leadconnectorhq.com:443 HTTP/1.1
> Host: services.leadconnectorhq.com:443
< HTTP/1.1 403 Forbidden


**How it surfaces to a user (misleading):**
- The CRM CLI installer (`pip install` of the package) fails with pip `ProxyError('Cannot connect to proxy.', OSError('Tunnel connection failed: 403 Forbidden'))` for `/simple/pip/` and `/simple/click/`, then `No matching distribution found for click>=8.0.0`. Looks like a pip problem. It is not.
- The CLI's token refresh (to `securetoken.googleapis.com`) reports the token "may be expired." It is not; the refresh request never left the proxy.
- A real credential failure returns a real `401` from the origin. These all return `000`.

Steps to Reproduce

1. On an account with Allow network egress: ON and Domain allowlist: All domains, start a Cowork session from the Windows desktop app with a local folder connected.
2. In the cloud shell, run:

``
for u in https://services.leadconnectorhq.com/ https://api.voipbills.com/ https://www.google.com/ https://example.com/ https://api.github.com/; do
printf "%-40s " "$u"; curl -s -o /dev/null -w "%{http_code}\n" --max-time 10 "$u"
done
``

1. In the local device_bash shell, run the same loop.
2. Query the agent proxy's own status endpoint:

``
curl -sS "$HTTPS_PROXY/__agentproxy/status"
``

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Cowork cloud sessions worked through 2026-09-09 ~2:55 PM PT (same desktop app build)

Claude Code Version

Claude Desktop app for Windows (Cowork), current build as of 2026-09-11; not a CLI install

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Impact

Every project on this account relies on scripts that call third-party APIs directly: a CRM API (services.leadconnectorhq.com, authenticated with a per-account API token), a billing API (api.voipbills.com), and pip for dependencies. All three are unusable in every Cowork session since September 9, in every project.

Concrete work blocked right now:

• A CRM migration of 336 companies and 321 contacts, fully planned and dry-run, cannot execute.
• Every other project that uses the same API scripts is in the same state.
• The per-session installer for the CRM CLI cannot even install because PyPI is refused.

MCP connectors still work because they bypass the session network, but connectors require a per-call approval and expose no bulk operations, so they do not replace direct API scripts for anything beyond a handful of edits.

The only workaround is to run Python natively on Windows outside Cowork, driven by job files dropped in a synced folder. That has to be rolled into every project and removes the direct feedback loop that made Cowork useful. It is a downgrade forced by the platform, not a fix.

What was ruled out

• Credentials. Never reach the origin. 000 at CONNECT, not 401 from the API.
• Windows update KB5124008 / local VM. Uninstalled, verified, rebooted. The local VM mounts folders and runs commands. The egress block persists in both the local VM and the cloud container, so it is not a local sandbox problem.
• Session-specific state. Multiple fresh sessions across two days, all blocked from the first request.
• User configuration. Allow network egress ON, All domains, confirmed in the desktop app and at claude.ai, unchanged from when it worked. Toggling it had no effect.
• The target hosts. services.leadconnectorhq.com and api.voipbills.com are reachable from the same Windows machine's browser and from any other network. Google and example.com are blocked the same way, so it is not host-specific.
• A published outage. status.claude.com shows only the Windows KB5124008 Cowork incident. Nothing about egress.

Prior reports of the same defect

• #34690 (Mar 15, 2026): "Allow network egress: All domains" setting not reflected in session proxy JWT. Reporter decoded the session token and found a hardcoded list of ~205 hosts and no allow-all flag. Same symptom as here. No response.
• #48114 (Apr 14, 2026): Cowork Windows, WebFetch egress proxy blocks all domains regardless of "All domains" allowlist setting. Open, no response.
• #30861 (Mar 4, 2026): Cowork macOS, MITM egress proxy blocks all non-API domains regardless of allowlist. Labeled invalid ("doesn't seem to be related to Claude Code") and left. It is a Cowork bug filed in the only public tracker Cowork has.
• #30112, #38984, #23818, #33386: allowlist entries and Admin Capabilities settings not applied to Cowork egress; subdomain matching broken.
• Reddit r/ClaudeAI, Sept 9, 2026: "Can you still create LOCAL (non-cloud) Cowork projects? Mine are all going to the cloud now." Same day this account broke; multiple users report the cloud-by-default switch.

The pattern across six months: the UI promises All domains, the proxy enforces a fixed allowlist, and the reports get no engineering response. This report adds a single-account regression with a timestamp, which should make it possible to correlate against a deploy on September 9. The mechanism appears to be: the session VM (cloud container and the local Cowork VM alike) routes all egress through Anthropic's gateway, and that gateway enforces a fixed, narrow allowlist regardless of the account's "All domains" setting.

Requested action

1. Fix the defect: make the session egress proxy honor the account's "All domains" (and Custom) allowlist setting, on both the cloud container and the local Cowork VM path. If the JWT minted at session start is the mechanism (per #34690), the allow-all flag is missing from it.
2. Identify what changed on September 9, 2026, around 21:55 UTC that moved this account from working to blocked with no configuration change, and check whether other accounts were affected the same way.
3. Interim: if a per-account allowlist can be applied manually while the fix ships, add services.leadconnectorhq.com, api.voipbills.com, pypi.org, and files.pythonhosted.org for this organization.
4. Acknowledge the prior reports (#34690, #48114, #30861 and the others) instead of closing them as invalid. They describe this bug.
5. Document the actual behavior. The Cowork help center says sessions run in the cloud with no local option; the Claude Code docs say the cloud environment's Network access level controls egress. Neither says that a Cowork session ignores the setting. Users are spending days diagnosing a platform defect as if it were their own configuration.

Available to reproduce on request, provide additional proxy logs, or test a fix. The evidence above was collected inside Cowork session session_0197JESTAvV1oMzCqDJX1y3G on September 11, 2026.