[BUG] Cowork — VM boots but guest never connects; HNS network silently not created (Windows 11 ARM64 / Snapdragon X)

Open 💬 0 comments Opened Jun 12, 2026 by wouter27jan-bot

Summary

"Failed to start Claude's workspace — VM service not running" → after fixing Windows features, error shifts to "VM connection timeout after 60 seconds". VM boots successfully but the guest never connects. Root observation: Get-HnsNetwork returns nothing even though the app logs create_network completed (0ms) — network creation appears to fail silently. All documented community fixes exhausted.

Environment

  • Device: Snapdragon X (Windows on ARM64), Qualcomm FastConnect 6900 Wi-Fi
  • OS: Windows 11 ARM64
  • Claude Desktop: 1.12603.1.0 (MSIX, Claude_1.12603.1.0_arm64__pzs8sxrjxfjjc)
  • AV: Windows Defender only
  • Disk: ~293 GB free
  • Windows features: VirtualMachinePlatform Enabled; HypervisorPlatform + Microsoft-Windows-Subsystem-Linux enabled on 2026-06-12 (were Disabled — first-stage fix per #64592) + wsl --update + reboot
  • Services: vmcompute Running, hns Running, CoworkVMService Automatic (starts, then VM start fails)

Timeline / what was tried

  1. 2026-06-11/12: "VM service not running. The service failed to start." Restart app + reboot: no effect.
  2. Enabled HypervisorPlatform + WSL (dism) + wsl --update + reboot → service now starts, VM boots; error becomes "VM connection timeout after 60 seconds".
  3. Get-NetNat was empty → created cowork-vm-nat (172.16.0.0/24, Active:True). No effect.
  4. Deleted vm_bundles entirely; fresh bundle downloaded (version 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a), checksums validated. First boot: all steps complete through add_plan9_shares, then Still waiting for guest connection... → Connection timeout, last completed step: add_plan9_shares.
  5. Subsequent auto-retries fail earlier with smol-bin.vhdx locked by running VM (EBUSY), skipping copy → stale VM holds disk; retries time out at last completed step: load_swift_api.
  6. Restart-Service CoworkVMService -Force to clear stale VM → clean attempt, same guest-connection timeout.
  7. Restart-Service hns -Force + service restart → Get-HnsNetwork still returns no networks at all, same timeout.

Key evidence

  • App log: create_network completed (0ms) on every attempt, yet Get-HnsNetwork shows zero HNS networks and no host adapter ever gets a 172.16.0.x address.
  • No 172.16.x subnet conflict (no VPN, no other adapters on that range).
  • VM itself boots fine (vm_boot completed 491ms; plan9 shares added on fresh-bundle boot).
  • Event log: Service Control Manager "The Claude service terminated unexpectedly" prior to feature fix; no Hyper-V/HNS errors logged in the failure window afterwards.

Hypothesis

On this ARM64 configuration the HNS network creation in CoworkVMService fails (or is skipped) without surfacing an error, leaving the guest with no path to the host; guest-connection polling then times out at the hard-coded 60 s.

Relation to existing issues

Extends the #64592 / #54891 / #61559 cluster (Windows feature dependency — that part of the fix worked here) but adds an ARM64-specific silent HNS failure mode.

Available on request

  • %APPDATA%\Claude\logs\cowork_vm_node.log (full)
  • Get-HnsNetwork, Get-NetNat, ipconfig /all, dism feature list, Event Viewer extracts

View original on GitHub ↗