[BUG] Cowork Windows: API unreachable behind NTLM proxy — no egress proxy implementation on Windows (systematic diagnosis)

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

Environment

• OS: Windows 11 Enterprise (x64, AD domain, NTLM/Kerberos auth)
• Claude Desktop: 1.1.6452.0 (MSIX)
• Shell: PowerShell 7
• Proxy: px-proxy on 127.0.0.1:3128 (NTLM auth), using PAC file
• Network: Corporate NTLM proxy with SSL inspection (Fortigate)
• Host IP range: 172.18.x.x/24 (corporate LAN)
• DNS: Internal DNS servers (external resolution only works through proxy)
• VirtualMachinePlatform: enabled, full Hyper-V not installed

What's Wrong?

Cowork tab shows error: "Fehler beim Starten von Claudes Arbeitsbereich — Die Claude-API kann von Claudes Workspace aus nicht erreicht werden." (API unreachable from workspace). Regular Chat mode works perfectly.

Root cause: Two independent bugs prevent Cowork from functioning on Windows behind a corporate NTLM proxy:

1. Missing VM egress proxy on Windows: On macOS, Claude Desktop runs a local MITM proxy that routes all VM traffic through the host. On Windows, this proxy infrastructure is absent — the VM connects via Hyper-V Sockets but has no way to reach the internet through the host's NTLM-authenticated proxy. In this corporate environment, even DNS resolution for external hosts fails without the proxy, making API access from the VM impossible.

1. CSP missing a-api.anthropic.com: The Electron app's Content Security Policy blocks connections to a-api.anthropic.com on Windows (fixed on macOS per #18006 but not ported to Windows).

Even if the CSP were fixed, the VM would still be unable to reach the API behind a corporate NTLM proxy because there is no proxy-aware egress path.

Related Issues

• #29367 (OPEN) — Same fundamental issue (cntlm/NTLM proxy, different corporate network). Our diagnosis confirms there is no MITM proxy listener on Windows.
• #25024 (CLOSED) — CSP blocks a-api.anthropic.com on Windows. We see the identical error.
• #18854 (CLOSED) — macOS equivalent; the MITM proxy exists but its allowlist was misconfigured. On Windows, the proxy doesn't exist at all.
• #24918 (CLOSED) — Similar symptom on Windows 11 Home.
• #18006 (CLOSED) — CSP fix on macOS, not ported to Windows.

---

Systematic Diagnosis Results

1. VM Infrastructure — Working

PS> Get-Service CoworkVMService, vmcompute | Select Name, Status, StartType
Name             Status  StartType
----             ------  ---------
CoworkVMService  Running Automatic
vmcompute        Running Manual

PS> hcsdiag list
cowork-vm
    VM, Running, <GUID>, cowork-vm

VM boots, connects, and installs SDK successfully.

2. No VM Network Layer on Windows

PS> Get-HnsNetwork          # (empty — no HNS networks)
PS> Get-HnsEndpoint         # (empty — no HNS endpoints)
PS> Get-VMSwitch            # cmdlet not recognized (Hyper-V management tools not installed)
PS> Get-NetNat              # (empty — no NAT configured)
PS> Get-NetAdapter -IncludeHidden
# Only physical Intel Ethernet adapter — NO vEthernet, NO Hyper-V virtual switch, NO WSL adapter

The VM has no visible network adapter, no HNS network, no VMSwitch, no NAT. Communication with the host is via Hyper-V Sockets (vsock) only.

VM is fully opaque — exec not supported:

PS> hcsdiag exec cowork-vm ip addr   # (as local admin)
Die Anforderung wird nicht unterstützt.

Even with admin privileges, hcsdiag exec returns "request not supported" — not "access denied". The VM type does not support shell access at all.

3. No MITM Proxy Port on Windows

Tested from two separate user accounts (admin and regular user):

PS> Get-Process *claude* | ForEach-Object {
    netstat -ano | Select-String "LISTENING" | Select-String "\s$($_.Id)$"
}
# (empty — Claude processes open ZERO listening ports)

PS> Get-Process *cowork* | ForEach-Object {
    netstat -ano | Select-String "\s$($_.Id)$"
}
# cowork-svc.exe (Session 0) has NO network connections at all

On macOS, Claude Desktop runs an internal MITM proxy that tunnels VM egress traffic. On Windows, no such proxy port exists. Verified by enumerating all listening ports on localhost — only px-proxy on port 3128 is present. Claude processes have zero listeners.

4. Proof: Without Proxy, No Network Access at All

PS> curl.exe -x http://127.0.0.1:3128 -s -o NUL -w "HTTP: %{http_code} Time: %{time_total}s\n" https://api.anthropic.com/v1/messages
HTTP: 405 Time: 0.074s    # API reachable through proxy, responds normally

PS> curl.exe --noproxy "*" -v --connect-timeout 5 https://api.anthropic.com
* Could not resolve host: api.anthropic.com
curl: (6) Could not resolve host: api.anthropic.com

Critical finding: Without proxy, not even DNS resolution works for external hosts. The corporate network requires all traffic (including DNS for external domains) to go through the NTLM-authenticated proxy. The VM, which has no proxy configuration, cannot resolve api.anthropic.com — let alone connect to it.

5. Key Log Entries (cowork_vm_node.log)

2026-03-13 09:36:13 [info] [VM] Network status: CONNECTED
2026-03-13 09:36:15 [info] [VM:steps] sdk_install completed (1918ms)
2026-03-13 09:36:15 [info] [VM:start] Startup complete, total time: 330574ms
2026-03-13 09:36:18 [info] [VM] API reachability: PROBABLY_UNREACHABLE
2026-03-13 09:36:41 [info] [VM] API reachability: UNREACHABLE
2026-03-13 09:36:41 [warn] [VM:network] API is unreachable
...
2026-03-13 09:54:46 [info] [Spawn:vm] OAuth token approved with MITM proxy
2026-03-13 09:56:22 [info] [Process:...] Exited, code=0, signal=null, duration=97160ms, oom=false

Sequence: VM boots -> network CONNECTED (vsock to host) -> SDK installs -> API check fails -> OAuth token approved via MITM proxy -> session spawned -> session killed after ~97s.

The OAuth token approval succeeds (presumably passed through vsock), but actual API traffic from inside the VM cannot egress through the corporate NTLM proxy.

6. Additional CSP Issue (claude.ai-web.log)

[error] Connecting to 'https://a-api.anthropic.com/v1/m' violates the following Content Security Policy
directive: "connect-src 'self' https://api.segment.io https://*.segment.io https://*.segment.com
https://a-cdn.anthropic.com https://*.google.com https://*.facebook.com https://*.facebook.net
https://*.doubleclick.net". The action has been blocked.

This CSP error appears repeatedly (related to #25024). a-api.anthropic.com is missing from the connect-src directive in the Windows Electron build.

7. cowork-svc.exe Details

Path: C:\Program Files\WindowsApps\Claude_<version>\app\resources\cowork-svc.exe
Session: 0 (service context)
Parent PID: services.exe
Working Set: ~38 MB
Network connections: NONE

The service runs but opens no network sockets — it communicates with the VM via Hyper-V Sockets only and delegates network egress to... nothing, on Windows.

8. Historical: yukonSilver Status

Before the MSIX was manually provisioned, the logs showed:

[warn] Skipping VM warm download - YukonSilver not supported
    (Cowork erfordert, dass Claude Desktop mit unserem modernen Installer installiert wird)

After manual provisioning via Add-AppxProvisionedPackage, the VM boots but hits the network issue described above.

---

Falsification Tests Performed

| Hypothesis | Test | Result |
|---|---|---|
| "Maybe Claude opens a proxy port we missed" | Enumerated all listening ports on localhost from two accounts (admin + regular user) | Confirmed absent: Zero Claude/Cowork listeners |
| "Maybe the VM has a routable IP network" | Checked HNS, VMSwitch, NetNat, all adapters (incl. hidden) | Confirmed absent: No VM network infrastructure visible |
| "Maybe we can look inside the VM" | hcsdiag exec as local admin | "Request not supported" — VM is fully opaque |
| "Maybe the problem isn't the proxy" | curl with and without proxy to api.anthropic.com | Confirmed: With proxy -> HTTP 405 (API responds). Without proxy -> DNS resolution fails entirely. |

Suggested Fix

Implement the MITM proxy egress layer on Windows (equivalent to macOS implementation) that:

1. Listens on a localhost port or uses Hyper-V Sockets to proxy traffic
2. Tunnels VM traffic through the host's network stack
3. Respects the host's proxy configuration (system proxy settings or explicit proxy like px-proxy/cntlm)
4. Also fix CSP connect-src to include a-api.anthropic.com / api.anthropic.com on Windows

Steps to Reproduce

1. Install Claude Desktop on a Windows machine behind a corporate NTLM proxy
2. Open Cowork tab
3. VM boots, network shows CONNECTED, SDK installs
4. API reachability immediately shows UNREACHABLE
5. Cowork session fails — cannot send/receive messages

Claude Model

Opus

Is this a regression?

No, this never worked

Claude Code Version

Claude Desktop 1.1.6452.0 (Windows MSIX)

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell