[BUG] Cowork Windows - CSP blocks a-api.anthropic.com, VM starts but API unreachable (Win 11 25H2)

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 on Windows consistently fails with "VM connection timeout after 60 seconds." The VM boots successfully, network connects, and SDK installs ... but the API is unreachable due to a Content Security Policy (CSP) issue in the Electron app that blocks a-api.anthropic.com.

This is the Windows equivalent of #18006 (CSP missing a-api.anthropic.com in connect-src), which was fixed on macOS but not carried to the Windows build.

Additionally, the network diagnostics code runs macOS commands (/sbin/ifconfig, /usr/sbin/scutil, /usr/sbin/kextstat) on Windows, producing ENOENT errors and labeling output as "Comprehensive macOS Diagnostics."

What Should Happen?

CSP should include a-api.anthropic.com / api.anthropic.com in the connect-src directive so the VM can reach the API after startup. Network diagnostics should use Windows-appropriate commands (ipconfig, netsh, etc.) instead of macOS binaries.

Error Messages/Logs

From claude.ai-web.log ... CSP blocking API:

2026-02-11 09:05:16 [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.
2026-02-11 09:05:16 [error] Fetch API cannot load https://a-api.anthropic.com/v1/m. Refused to connect because it violates the document's Content Security Policy.

From cowork_vm_node.log — VM starts fine, API unreachable:

2026-02-11 09:29:31 [info] [VM:start] Startup complete, total time: 22996ms
2026-02-11 09:29:31 [info] [Keepalive] Starting (interval=2000ms)
2026-02-11 09:29:34 [info] [VM] API reachability: PROBABLY_UNREACHABLE
2026-02-11 09:29:58 [info] [VM] API reachability: UNREACHABLE
2026-02-11 09:29:58 [warn] [VM:network] API is unreachable

From cowork_vm_node.log — macOS diagnostics running on Windows:

2026-02-11 09:34:24 [info] [networkDiagnostics] === Comprehensive macOS Diagnostics ===
2026-02-11 09:34:24 [error] [networkDiagnostics] Failed to run /sbin/ifconfig: Error: Failed to spawn /sbin/ifconfig: spawn /sbin/ifconfig ENOENT
2026-02-11 09:34:24 [error] [networkDiagnostics] Failed to run /usr/sbin/scutil: Error: Failed to spawn /usr/sbin/scutil: spawn /usr/sbin/scutil ENOENT
2026-02-11 09:34:24 [error] [networkDiagnostics] Failed to run /usr/sbin/kextstat: Error: Failed to spawn /usr/sbin/kextstat: spawn /usr/sbin/kextstat ENOENT

Steps to Reproduce

1. Install Claude Desktop v1.1.2685.0 on Windows 11 25H2 via MSIX
2. Log in with a Max plan account
3. Switch to Cowork tab
4. Attempt any task
5. VM boots, connects network, installs SDK, then reports API UNREACHABLE
6. After ~60s, "VM connection timeout after 60 seconds" error is displayed

Claude Model

Other

Is this a regression?

No, this never worked

Last Working Version

N / A

Claude Code Version

N/A

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• Related to #18006 (same CSP bug on macOS, apparently fixed for Mac but not carried to the Windows build)
• Related to #24918 (another Windows Day 1 Cowork failure)
• The VM itself works perfectly — boots, gets network, installs SDK in ~12-23 seconds
• Regular Chat mode works fine, only Cowork is affected
• Environment has Defender ASR rules and Intune management, but these are not the cause — the failures are internal to the Claude Desktop app
• Full Hyper-V is not enabled, but WSL2 runs fine via VirtualMachinePlatform and the VM boots successfully, so this is not a virtualization issue
• CoworkVMService is installed and running (Automatic start). Hyper-V Host Compute Service (vmcompute) is also running. No issues with VM infrastructure.
• Windows Firewall has explicit allow rules for Claude in both inbound and outbound directions
• There is no local proxy listener for VM egress traffic. On macOS, the MITM proxy listens on a localhost port (see #18854) to route VM API calls through the host. On Windows, no such listener exists — the only TCP connection from Claude is a single outbound connection to Anthropic for the web UI.
• Zero references to proxy, port, socket, vsock, or hvsock appear anywhere in the Windows logs, unlike macOS where the MITM proxy and vsock infrastructure are extensively logged. This suggests the VM egress proxy layer may not be fully implemented in the Windows build.
• No coworkd log (guest-side log from inside the VM) exists, so there is no visibility into what the VM is doing when it attempts to reach the API
• Network diagnostics code runs macOS-only commands (/sbin/ifconfig, /usr/sbin/scutil, /usr/sbin/kextstat) on Windows, producing ENOENT errors and labeling output as "Comprehensive macOS Diagnostics"