[BUG] Cowork (Windows): device VM egress ignores the account Domain allowlist - 403 blocked-by-allowlist while set to All domains

[BUG] Cowork (Windows): device VM egress ignores the account Domain allowlist — 403 blocked-by-allowlist on every host while the setting is "All domains"

The desktop device VM that backs device_bash enforces an egress allowlist that the account's own Domain allowlist setting does not govern. With network egress enabled and the allowlist set to "All domains," the VM's proxy still refuses every outbound host, including api.github.com.

Net effect: any workflow that shells out from the device VM to the network is dead — git clone, git push, curl, package installs, DNS.

Environment

• Claude Desktop 1.49585.0.0, Windows 11 25H2 x64
• Settings → Capabilities → Allow network egress: ON
• Settings → Capabilities → Domain allowlist: "All domains" ("Claude can access all domains on the internet")

What the setting says vs. what the VM does

The allowlist control is labelled "Choose which domains the sandbox can access." It appears to govern only the cloud container. The device VM applies a separate, narrower policy with no corresponding UI.

Measured from the same session, same account, at the same time:

| Surface | Host | Result |
|---|---|---|
| Cloud container | api.github.com | 200 |
| Device VM (device_bash) | api.github.com | 403 blocked-by-allowlist |

Proxy transcript from the device VM

The proxy is healthy — this is policy, not plumbing:

$ ss -ltnp | grep -E '3128|1080'
LISTEN 0 5 0.0.0.0:3128 0.0.0.0:* users:(("socat",pid=3,fd=5))
LISTEN 0 5 0.0.0.0:1080 0.0.0.0:* users:(("socat",pid=4,fd=5))

$ curl -sS -v https://api.github.com/
* Connected to (nil) (127.0.0.1) port 3128 (#0)
* Establish HTTP proxy tunnel to api.github.com:443
> CONNECT api.github.com:443 HTTP/1.1
< HTTP/1.1 403 Forbidden
< X-Proxy-Error: blocked-by-allowlist
* Received HTTP code 403 from proxy after CONNECT

$ getent hosts github.com
(no output — DNS also traverses the blocked path)

TCP to the proxy succeeds; the CONNECT is refused by policy. Plain curl without -sS reports 000 / exit 56, which is why this can look like a connectivity failure rather than an allowlist decision — the X-Proxy-Error header is the tell.

Why this is a regression, not a config choice

This path worked on 2026-09-07 under Claude Desktop 1.34493.1.0: a git clone of a private repo ran from inside the device VM, authenticated with a PAT read from a connected folder, and pushed successfully. The same procedure now fails at git clone with no network. The only change in between was the app updating to 1.49585.0.0 on 2026-09-08.

Expected

One of:

1. The device VM honours the account's Domain allowlist, so "All domains" means all domains on both surfaces; or
2. The VM's allowlist is surfaced in Settings as its own control, so it can be configured; or
3. The setting's copy is corrected to state that it governs only the cloud sandbox, and the device VM's fixed allowlist is documented.

Actual

The setting reads "All domains" and the device VM silently refuses everything, with no indication anywhere in the UI that a second policy exists.

Impact

Any documented procedure that runs git or HTTP from the device VM is broken with no user-side remedy, since the only relevant control is already set to its most permissive value. Work can be routed around this — the file bridge (device_stage_files / device_commit_files) is unaffected, and server-side automation reached through MCP connectors is unaffected — but the VM's own network is unusable.

Not related to KB5124008

Worth stating explicitly, since both affect device_bash on Windows: this is independent of the Plan9 share-mount regression in #92984. On this machine the mount was restored by rolling back KB5124008, and $HOME/mnt/<folder> reads and writes normally. Egress from the VM stayed broken across both states.

Offer

Happy to provide full proxy environment dumps, a verbose curl against additional hosts, or a before/after against an older app build if one can be installed side by side.