Repository navigation
Cowork: CoworkVMService crashes repeatedly, API unreachable from VM on Windows 11 Insider (MSIX) #25505
Description
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
- Rebooting Windows
- Restarting Claude Desktop multiple times
- Reinstalling the workspace (via the UI button) — multiple times
- Disconnecting NordVPN
- Manually starting
CoworkVMService(crashes when app connects) - Manually setting DNS on
vEthernet (cowork-vm-nat) - Deleting VM disk files (sessiondata.vhdx, rootfs.vhdx, smol-bin.vhdx) for fresh rebuild
- 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
- [BUG] [Cowork] Windows: VM starts successfully but crashes within 5 minutes, service unrecoverable (Win 11 Pro, Hyper-V) #25206 — VM crashes within 5 minutes on Windows
- Cowork Windows - VM gets wrong DNS server, API unreachable #25088 — VM gets wrong DNS server
- [BUG] Cowork VM uses DNS from disconnected adapter on Windows, causing API unreachable #25144 — DNS from disconnected adapter
- Cowork VM fails on Windows 11 Home: wrong DNS config, missing sessiondata.vhdx, no NAT #24962 — Wrong DNS, missing sessiondata.vhdx, no NAT
- [BUG] Cowork tab not showing on Windows 11 Pro x64 — "yukonSilver" marked as unsupported + CoworkVMService cannot be removed #25136 — yukonSilver unsupported + CoworkVMService removal
- [BUG] Cowork Windows - CSP blocks a-api.anthropic.com, VM starts but API unreachable (Win 11 25H2) #25024 — CSP blocks API on Windows
Activity
github-actions commentedon Feb 13, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
github-actions commentedon Feb 17, 2026
This issue has been automatically closed as a duplicate of #25144.
If this is incorrect, please re-open this issue or create a new one.
🤖 Generated with Claude Code
github-actions commentedon Feb 24, 2026
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.