Cowork: CoworkVMService crashes repeatedly, API unreachable from VM on Windows 11 Insider (MSIX)
Description
Cowork fails to start on Windows 11 Pro Insider (Build 26220). The CoworkVMService Windows service crashes repeatedly, and even when the VM successfully boots, the Anthropic API is unreachable from inside the VM.
The error shown in the UI is:
VM service not running. The service failed to start. Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace or share your debug logs to help us improve.
Environment
- OS: Windows 11 Pro Insider Build 26220 (10.0.26220)
- CPU: 13th Gen Intel Core i9-13900K (32 cores)
- RAM: 63.77 GB (30.8% used)
- Disk: 442 GB total, 15.18 GB free (96.6% used)
- Claude Desktop: v1.1.2998 (MSIX package:
Claude_1.1.2998.0_x64__pzs8sxrjxfjjc) - Claude Code SDK: v2.1.40
- Electron: 40.4.0 / Node 24.13.0
- Hyper-V: Enabled (
HvHostandvmcomputeservices running) - WSL2: Running (Ubuntu 24.04)
- NordVPN: Installed (tested with VPN both connected and disconnected — same result)
Observed Behavior
Issue 1: yukonSilver incorrectly marked as unsupported
From the very first launch through Feb 13, the log repeatedly shows:
[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
This persisted across app restarts for weeks (Jan 30 through Feb 13). Despite this, on Feb 13 the VM eventually did download and start (see Issue 2).
Issue 2: API unreachable from inside VM
When the VM successfully boots, the API reachability check fails every time:
[VM] API reachability: PROBABLY_UNREACHABLE
[VM] API reachability: UNREACHABLE
[VM:network] API is unreachable
Root cause identified: The vEthernet (cowork-vm-nat) adapter has no IPv4 DNS servers configured. The VM NAT adapter only has placeholder IPv6 fec0 addresses. Meanwhile, the host has working DNS on Wi-Fi (8.8.8.8, 8.8.4.4) and Ethernet (192.168.0.1).
DNS configuration at time of failure:
vEthernet (cowork-vm-nat) IPv4: {} (empty - no DNS!)
vEthernet (cowork-vm-nat) IPv6: {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3}
Wi-Fi IPv4: {8.8.8.8, 8.8.4.4}
Ethernet IPv4: {192.168.0.1}
Manually setting DNS on the NAT adapter did not resolve the issue because of Issue 3.
Issue 3: CoworkVMService crashes/stops repeatedly
The CoworkVMService (type: WIN32_PACKAGED_PROCESS, binary: cowork-svc.exe) starts but then terminates unexpectedly.
Windows Event Log (System):
The Claude service terminated unexpectedly. It has done this 1 time(s).
Cycle observed:
- Service starts (manually or via Claude Desktop)
- VM module loads successfully
- Claude Desktop connects and triggers
stopVM/deleteVMBundle - Service crashes
- Subsequent attempts only show
[VM] Loading vmClient... Module loaded successfullybut never attempt VM startup
After manually starting the service and waiting 10+ seconds, it stays running on its own. But as soon as Claude Desktop interacts with it, it crashes.
Issue 4: DCOM permission error in MSIX app container
Windows Event Log (System) at 06:38:14:
The application-specific permission settings do not grant Local Activation permission
for the COM Server application with CLSID {2593F8B9-4EAF-457C-B68A-50F6B8EA6B54}
and APPID {15C20B67-12E7-4BB6-92BB-7AFF07997402} to the user THIAGO-PC\THIAGO
running in the application container Claude_1.1.2998.0_x64__pzs8sxrjxfjjc
This suggests the MSIX sandbox is preventing proper COM communication between the desktop app and the Hyper-V compute service.
Steps to Reproduce
- Install Claude Desktop v1.1.2998 (MSIX) on Windows 11 Pro Insider Build 26220
- Open Claude Desktop
- Navigate to Cowork tab
- Click to start a Cowork session
- Observe "VM service not running" error
What I Tried
- [x] Rebooting Windows
- [x] Restarting Claude Desktop multiple times
- [x] Reinstalling the workspace (via the UI button) — multiple times
- [x] Disconnecting NordVPN
- [x] Manually starting
CoworkVMService(crashes when app connects) - [x] Manually setting DNS on
vEthernet (cowork-vm-nat) - [x] Deleting VM disk files (sessiondata.vhdx, rootfs.vhdx, smol-bin.vhdx) for fresh rebuild
- [x] None of the above resolved the issue
Key Log Excerpts
cowork_vm_node.log — Download failure on first attempt
[error] [download] VM download failed: Request error: net::ERR_QUIC_PROTOCOL_ERROR
[error] [VM:start] Startup failed: Error: Request error: net::ERR_QUIC_PROTOCOL_ERROR
cowork_vm_node.log — VM starts but API unreachable
[VM:start] Startup complete, total time: 10859ms
[Keepalive] Starting (interval=2000ms)
[VM] API reachability: PROBABLY_UNREACHABLE
...
[VM] API reachability: UNREACHABLE
[VM:network] API is unreachable
cowork_vm_node.log — Spawned processes immediately exit
[Process:c810d29b] Spawn confirmed, flushing 2 buffered stdin chunks
[CoworkVMProcess:c810d29b] kill called with signal: SIGTERM
[Process:c810d29b] Exited, code=0, signal=null, duration=597ms, oom=false
[CoworkVMProcess:c810d29b] kill failed with error: Error: RPC error -1: process already exited
Related Issues
- #25206 — VM crashes within 5 minutes on Windows
- #25088 — VM gets wrong DNS server
- #25144 — DNS from disconnected adapter
- #24962 — Wrong DNS, missing sessiondata.vhdx, no NAT
- #25136 — yukonSilver unsupported + CoworkVMService removal
- #25024 — CSP blocks API on Windows
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗