Skip to content

Cowork: CoworkVMService crashes repeatedly, API unreachable from VM on Windows 11 Insider (MSIX) #25505

Closed as duplicate

Description

@thiagovictorino

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 (HvHost and vmcompute services 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:

  1. Service starts (manually or via Claude Desktop)
  2. VM module loads successfully
  3. Claude Desktop connects and triggers stopVM / deleteVMBundle
  4. Service crashes
  5. Subsequent attempts only show [VM] Loading vmClient... Module loaded successfully but 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

  1. Install Claude Desktop v1.1.2998 (MSIX) on Windows 11 Pro Insider Build 26220
  2. Open Claude Desktop
  3. Navigate to Cowork tab
  4. Click to start a Cowork session
  5. 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

Activity

  1. github-actions commented on Feb 13, 2026

    @github-actions

    Found 3 possible duplicate issues:

    1. [BUG] Cowork VM uses DNS from disconnected adapter on Windows, causing API unreachable #25144
    2. Cowork Windows - VM gets wrong DNS server, API unreachable #25088
    3. Cowork VM fails on Windows 11 Home: wrong DNS config, missing sessiondata.vhdx, no NAT #24962

    This issue will be automatically closed as a duplicate in 3 days.

    • If your issue is a duplicate, please close it and 👍 the existing issue instead
    • To prevent auto-closure, add a comment or 👎 this comment

    🤖 Generated with Claude Code

  2. added
    duplicateThis issue or pull request already exists
    and removed
    bugSomething isn't working
    platform:windowsIssue specifically occurs on Windows
    on Feb 17, 2026
  3. github-actions commented on Feb 17, 2026

    @github-actions

    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

  4. github-actions commented on Feb 24, 2026

    @github-actions

    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.

  5. locked as resolved and limited conversation to collaborators on Feb 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    duplicateThis issue or pull request already exists

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions