[BUG] Cowork Windows - CSP blocks a-api.anthropic.com, VM starts but API unreachable (Win 11 25H2)
Status Fixed / completed
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 11 comments · opened Feb 11, 2026 · closed Feb 26, 2026
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 ENOENTSteps to Reproduce
- Install Claude Desktop v1.1.2685.0 on Windows 11 25H2 via MSIX
- Log in with a Max plan account
- Switch to Cowork tab
- Attempt any task
- VM boots, connects network, installs SDK, then reports API UNREACHABLE
- 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"
11 Comments
Same issue.
Logs are smoking gun. See commentary after logs.
Content Security Policy within Claude (claude.ai-web.log)
API Unreachable after successful network connect (cowork_vm_node.log)
Environment: Windows 11 Pro (24H2), WSL2 installed, Hyper-V available. I have PIA but not running or active.
Symptoms: Chat works fine. Cowork fails 100% of the time with "Cannot connect to Claude API from workspace."
What I verified:
HNS NAT network (
cowork-vm-nat) exists with correct subnet (172.16.0.0/24). DNS on VM endpoint is correct (ISP DNS, not hardcoded). IP forwarding enabled on both cowork-vm-nat and Wi-Fi adapters. Windows Firewall fully disabled made no difference. Changing DNS to 1.1.1.1/8.8.8.8 made no difference. WSL updated with default version set to 2.What the logs show:
VM boots in ~9 seconds, network status reaches CONNECTED, and the SDK installs successfully — proving outbound connectivity works. API reachability immediately goes PROBABLY_UNREACHABLE → UNREACHABLE. Separately, the app-level CSP blocks
a-api.anthropic.com— it's missing from theconnect-srcdirective.Conclusion: The VM has working network connectivity (it downloads and installs the SDK), but the MITM proxy or CSP configuration is blocking API calls specifically. This appears to be a configuration issue on Anthropic's side, not a user networking problem.
More info from cowork_vm_node.log, looks like it's trying to run MacOS networking commands.
Same error here
Same issue.
Worked around this by disabling the Ethernet adapter (I am using a docking station, so Ethernet #2 is the active), delete the cowork-vm-nat adapter, and then uninstall and install a fresh copy of Claude Dekstop. Then reenable the Ethernet adapter.
Disable-NetAdapter -Name "Ethernet" -Confirm:$false
Get-HnsNetwork | Where-Object { $_.Name -like "cowork*" } | Remove-HnsNetwork
Enable-NetAdapter -Name "Ethernet" -Confirm:$false
Same mistake here
The DNS config tweak at https://github.com/anthropics/claude-code/issues/24918#issuecomment-3888977751 fixed this for me. It definitely should be addressed in setup though.
Hi.
I had the same issue on Cowork.
I somehow bypassed by enabling developper options
Same issue here on Windows 11 (Build 10.0.26200), Intel Core Ultra 7 155H.
After extensive debugging, I've identified the root cause more precisely:
The MITM proxy never starts. The VM boots successfully, gets network connectivity, and the HNS cowork-vm-nat network is correctly configured (172.16.0.0/24), but no proxy process ever binds to any port on the host. Without the proxy, the VM cannot inject OAuth tokens, so API reachability stays UNREACHABLE.
Evidence: netstat -ano | findstr "LISTENING" shows nothing on any expected proxy port (8877, 8888, 3128, 9090) after Cowork starts.
This appears caused by MSIX sandbox restrictions ([MSIX] Filesystem virtualization active confirmed in main.log) blocking the proxy from binding to the Hyper-V network interface.
Environment:
Windows 11 Build 26200
Hyper-V: Enabled
WSL2 Ubuntu 24.04: Working fine, curl -I https://api.anthropic.com returns HTTP/2 404 (reachable) from WSL2
HNS cowork-vm-nat network: Present and correctly configured
Installed via MSIX (Windows Store package)
Workaround request: Is there a non-MSIX direct .exe installer available that bypasses the sandbox restrictions?
Also the same for me:
CSP Issue:
2026-02-19 19:17:49 [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-19 19:17:49 [error] Fetch API cannot load https://a-api.anthropic.com/v1/m. Refused to connect because it violates the document's Content Security Policy.
2026-02-19 19:17:49 [error] Error sending segment performance metrics TypeError: Failed to fetch
2026-02-19 19:19:29 [error] Uncaught Error: Minified React error #418; visit https://react.dev/errors/418?args[]=HTML&args[]= for the full message or use the non-minified dev environment for full errors and
additional helpful warnings.
API Connection Issue
2026-02-19 20:15:28 [info] [VM:steps] load_swift_api started
2026-02-19 20:15:28 [info] [VM:steps] load_swift_api completed (0ms)
2026-02-19 20:15:36 [info] [VM:network] Not connected, will show error in 30000ms if not resolved
2026-02-19 20:15:41 [info] [VM] API reachability: PROBABLY_UNREACHABLE
2026-02-19 20:16:07 [info] [VM] API reachability: UNREACHABLE
2026-02-19 20:16:07 [warn] [VM:network] API is unreachable
My current setup
App Version 1.1.3647 on Windows 11 Pro (24H2)
Hyper-V and Virtual Machine Platform enabled
ICS networking confirmed working correctly
DNS resolving correctly through 172.16.0.1
Routes and firewall confirmed not blocking traffic
(also tried disabling disconnected network adapters, enabling IP forwarding, and set DNS on the vEthernet (cowork-vm-vnet) adapter to 1.1.1.1/8.8.8.8)
What Claude said
Notice it's a-api.anthropic.com, not api.anthropic.com. The Electron app's Content Security Policy is missing a-api.anthropic.com from its connect-src whitelist, so the app itself is blocking the VM's API calls before they even hit the network. This has nothing to do with your network configuration — everything you've set up is correct.
This is entirely on Anthropic's side to fix — the CSP header in the Windows Electron build needs to be updated to include https://a-api.anthropic.com. It was fixed on macOS previously but wasn't carried over to the Windows build.
Updating my status to the comment I made above. Cowork is now working in our environment after installing version 1.1.4328.0. We enabled:
-Virtual Machine Platform
-Hyper-V
-Windows Hypervisor Platform (we previously just had the first two enabled, but cowork was still failing until we enabled this)
We have tried on three Windows 11 Pro machines so far that were having issues, and they're working now. We did not have to disable any disconnected network interfaces or enable IP forwarding this time around.
Note, when I first installed the app, Cowork was having the API connection issue. I disabled the disconnected network interface that the VM was seeing and enabled IP forwarding (along with enabling VPM/Hyper-V features), and it worked for a day. However, cowork eventually stopped working and ran into the API connection issue again with the workarounds no longer working. It appeared that the app update broke it? The app went through at least five more updates until this version started working. We were checking and troubleshooting daily. Unfortunately, I didn't note what the original app version I was on. I just hope that this stays working and won't run into the API connection issue again with a future update.
We are using the Claude MSIX (x64) installer from the following and pushing the installation via Intune:
https://support.claude.com/en/articles/12622703-deploy-claude-desktop-for-windows
Hey folks, v1.1.4328 should contain a rather effective fix for these networking issues some users were facing. Please update and you should be able to use Cowork 🥳
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.