›_ Claude Code Issues
Claude Code Issues / #45480

Cowork: VM connection timeout on Windows ARM64 (Snapdragon X Plus)

Status Closed — not planned
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 14 comments · opened Apr 8, 2026 · closed May 28, 2026

Description

Claude Cowork fails to start on Windows ARM64 (Snapdragon X Plus) with "VM connection timeout after 60 seconds." It has never successfully connected — zero successful guest connections across 30+ attempts from March 26 to April 9, 2026.

System Info

  • CPU: Snapdragon X Plus (X1P42100), 8 cores
  • OS: Windows 11 Home ARM64, Build 26200
  • RAM: 32GB
  • Disk: 693GB free
  • Claude version: 1.1348.0.0 (arm64, Microsoft Store)
  • VM config: 4096MB RAM, 2 CPUs allocated

Failure Pattern

The VM boots successfully via HCS, but the Linux guest never establishes an HvSocket connection:

[VM:steps] create_vm_config completed (63ms)
[VM:steps] vm_boot completed (104ms)
[VM:steps] add_plan9_shares completed (3ms)
[VM:start] Still waiting for guest connection... 10130ms elapsed, 21 polls
[VM:start] Still waiting for guest connection... 20293ms elapsed, 41 polls
[VM:start] Still waiting for guest connection... 30474ms elapsed, 61 polls
[VM:start] Still waiting for guest connection... 40645ms elapsed, 81 polls
[VM:start] Still waiting for guest connection... 50849ms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: add_plan9_shares

What I've Tried

  • Restarting the computer (multiple times)
  • Deleting smol-bin.vhdx and letting it recreate
  • Full workspace reinstall (deleted entire vm_bundles directory, fresh re-download) — same timeout
  • Stopping vmcompute service, killing vmwp.exe, restarting services
  • The auto-reinstall ran once on March 26 and failed with the same timeout

Additional Context

  • Hyper-V Host Compute Service (vmcompute) and HvHost are both running correctly
  • The VM boots (vmwp.exe starts), but the ARM64 Linux kernel/init inside the VM appears to fail silently before it can start its agent service
  • Secondary issue: after a failed attempt, vmwp.exe holds a lock on smol-bin.vhdx, causing EBUSY errors on subsequent attempts until vmcompute is stopped and vmwp is killed
  • Cowork was announced for Windows ARM on 2025-03-25; the first attempt on this machine was March 26 and it has never worked since

Relevant Logs

  • cowork_vm_node.log: Every attempt ends with Connection timeout, last completed step: add_plan9_shares
  • cowork-service.log: HCS initializes correctly, VM session created, network configured — all infrastructure works
  • Boot mode: UEFI BootThis+VmbFs (ARM64)
  • Kernel cmdline: initrd=\initrd root=/dev/sda1 rootfstype=ext4 rw panic=10

View original on GitHub ↗

14 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/39161
  2. https://github.com/anthropics/claude-code/issues/39636
  3. https://github.com/anthropics/claude-code/issues/40198

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

Matt73D · 4 months ago

👍

Orionx9xx · 4 months ago

Still failing on v1.1617.0.0 (ARM64)

Upgraded to Claude Desktop v1.1617.0.0
Cowork now reaches "VM connection timeout after 60 seconds"
(previously "VM service not running" on older versions)

Manual sc.exe start CoworkVMService succeeds (STATE 2 START_PENDING)
but Cowork still times out after 60 seconds

Device: Snapdragon X Plus (X1P42100)
OS: Windows 11 Pro ARM64
Claude: v1.1617.0.0

a0915947793-lang · 4 months ago

Device: ASUS Zenbook A14 UX3407QA, Snapdragon X
Cowork Readiness Check result: SUPPORTED (all items pass)
Error: VM connection timeout after 60 seconds
Tried: Reinstall workspace, full reinstall of Claude Desktop, multiple reboots — issue persists with 100% reproduction rate.
Adding my case here to confirm this affects Snapdragon X (not just X Plus/Elite).

abedshelp-boop · 4 months ago

Confirming this is still 100% reproducible on Windows 11 Home ARM64 build 26200 with the current Claude Desktop, 1.2581.0.0 (MSIX, ARM64). All prior reports in this thread are on 1.1348 / 1.1617 / 1.2.234 / 1.2278 — adding 1.2581 as another confirmed-broken version so there's a fresh data point.

Setup

  • OS: Windows 11 Home ARM64, OsBuildNumber 10.0.26200
  • Claude Desktop: 1.2581.0.0 (MSIX Claude_pzs8sxrjxfjjc, arm64)
  • Bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
  • VBS / Device Guard: HVCI + System Guard Secure Launch both running (SecurityServicesRunning: {2, 3}), CodeIntegrityPolicyEnforcementStatus: 2
  • Services: vmcompute running, wslservice running
  • Disk: ~323 GB free on system drive

Failure mode — identical to canonical reports

From %APPDATA%\Claude\logs\cowork_vm_node.log, two consecutive failures (first fresh launch, then the auto-reinstall retry):

2026-04-15 00:20:18 [info] [VM:steps] vm_boot completed (275ms)
2026-04-15 00:20:18 [info] [VM:steps] add_plan9_shares started
2026-04-15 00:20:18 [info] [VM:steps] add_plan9_shares completed (16ms)
2026-04-15 00:20:29 [info] [VM:start] Still waiting for guest connection... 10422ms elapsed, 21 polls
2026-04-15 00:20:39 [info] [VM:start] Still waiting for guest connection... 20698ms elapsed, 41 polls
2026-04-15 00:20:49 [info] [VM:start] Still waiting for guest connection... 31014ms elapsed, 61 polls
2026-04-15 00:21:00 [info] [VM:start] Still waiting for guest connection... 41498ms elapsed, 81 polls
2026-04-15 00:21:10 [info] [VM:start] Still waiting for guest connection... 51797ms elapsed, 101 polls
2026-04-15 00:21:18 [error] [VM:start] Connection timeout, last completed step: add_plan9_shares
2026-04-15 00:21:18 [info] [VM:start] Auto-reinstalling workspace after startup failure
2026-04-15 00:21:18 [info] [deleteVMBundle] Reinstall files deleted (sessiondata.img and rootfs.img.zst preserved)
...
2026-04-15 00:22:26 [error] [VM:start] Connection timeout, last completed step: add_plan9_shares
2026-04-15 00:22:26 [info] [VM:start] Skipping auto-reinstall (already attempted once)

Bundle files all present on disk, timestamps coherent, .zst checksums validated at download. The host side (vmcompute) has no complaint — the VM boots, add_plan9_shares completes in ~16 ms, then the guest just never opens its channel back to the host. No successful boot has ever occurred on this machine — it has failed identically on every attempt since the very first install.

Positive control ruling out host-side hypervisor / HVCI / VBS / Secure Launch

I wanted to rule out Memory Integrity / HVCI / System Guard Secure Launch / general HCS breakage on this build, so I booted WSL2 on the same machine while Cowork was failing:

> wsl --exec uname -a
Linux <host> 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:31:42 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

WSL2 uses the same vmcompute / HCS VM hosting stack that Cowork uses, with the same HVCI / VBS / Secure Launch posture active. It boots and returns output from inside the guest cleanly. Therefore on this machine:

  • ❌ HVCI / Memory Integrity is not the cause
  • ❌ System Guard Secure Launch is not the cause
  • ❌ VBS / DeviceGuard is not the cause
  • ❌ The general HCS guest→host channel on ARM64 build 26200 is not broken
  • ❌ Hypervisor firmware / SLAT / virtualization features are not the problem

The failure is isolated to Cowork's own vmlinuz + initrd + guest init inside vm_bundles/claudevm.bundle/. Whatever keeps the ARM64 Linux guest from reaching the point where it opens the HvSocket back to the host is specific to Anthropic's custom guest image on this build, not the Windows-side platform.

Things tried that didn't help (matches the rest of the thread)

  • Deleting .auto_reinstall_attempted to unblock the auto-repair retry loop — it re-ran the reinstall, failed identically, re-set the flag
  • Full kill of the Claude Desktop process tree between attempts (with vmmem confirmed exited)
  • Claude Desktop version upgrade mid-session (1.2278.0.0 → 1.2581.0.0) — same failure on both versions
  • Stale IDE lock cleanup, bundle dir inspection, service status checks — all fine

Suggestion

A guest-side serial console log (e.g. console=hvc0 / earlyprintk dumped to a file next to cowork_vm_node.log) would let affected users tell you whether the ARM64 guest is:

  • (a) kernel-panicking during boot,
  • (b) hanging on initrd,
  • (c) failing at a specific init / service step, or
  • (d) completing boot but failing to open the HvSocket for some reason.

Right now the logging stops at the host polling loop, so everyone in this thread is guessing. Happy to enable any debug flag / env var you point me at and share the output.

tbizot · 4 months ago

Confirmed: VM connection timeout on Windows ARM64

I'm experiencing the same issue with Claude Cowork on Windows ARM64.

System Specifications

  • Device: TBZ-LAPTOP (Surface Laptop 13in 1st Ed with Snapdragon)
  • Processor: Snapdragon X Plus (8-core) @ 3.30 GHz
  • RAM: 16.0 GB (15.6 GB usable)
  • GPU: Qualcomm Adreno X1-45 GPU
  • Storage: 477 GB SSD
  • System Type: 64-bit operating system, ARM processor

Windows Specifications

  • Edition: Windows 11 Professional
  • Version: 25H2
  • Build: 26200.8117
  • Installed: 05/02/2026

Error Message

Impossible de démarrer l'espace de travail de Claude.
VM connection timeout after 60 seconds

Troubleshooting Attempted

  • Restarted Claude Desktop
  • Restarted the computer

The issue persists. This appears to be the same VM connection timeout problem affecting other Windows ARM64 devices. Please let me know if you need additional logs or system information to help diagnose this issue.

PPapucar · 4 months ago

Same issue occurring for Snapdragon X Plus, HP OmniBook 5, Windows 11, ARM64, Claude Store version 1.3109.0.0.

Root cause
The log shows the failure happens at exactly the same step every time: `add_plan9_shares completed → guest connection never arrives → 60-second timeout.
Here's the sequence of every failed attempt:

vm_boot completes fine (1-2 seconds) ✓
add_plan9_shares completes fine (~25-90ms) ✓
Then: "Still waiting for guest connection..." polling every 500ms
After 60 seconds: Connection timeout, last completed step: add_plan9_shares

The VM is booting. The host is serving the file shares. What's failing is the vsock/Hyper-V channel between the host and the Linux guest — the guest can't call home to say "I'm alive." That's an ARM64/Hyper-V plumbing issue on the Snapdragon X Plus, not something you can fix with wsl --install or a restart.
The EBUSY "VM is already running" errors you see later in the log are a downstream symptom, not the cause — after a failed startup, the VM process lingers and locks smol-bin.vhdx, so subsequent attempts can't even begin. The original failure is always the guest-connection timeout.

anamayela80 · 4 months ago

no solution for this yet, i have the same in my windows surface

wberko · 4 months ago

experiencing the same issue:

Processor Snapdragon(R) X Plus - X1P42100 - Qualcomm(R) Oryon(TM) CPU (3.24 GHz)
Installed RAM 16.0 GB (15.6 GB usable)
System type 64-bit operating system, ARM-based processor

edizyediren1-eng · 4 months ago

👍

github-actions[bot] · 3 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

tomasvolek · 2 months ago

Adding another +1 confirming this is still 100% reproducible on Claude Desktop 1.7196.0.0 (MSIX, ARM64) — the latest version on Microsoft Store as of June 2026. The original report covered versions through 1.2581.0.0 and the StepCodex writeup confirmed up to 1.4758.0.0; this adds a fresh data point that the regression persists in 1.7196.

Setup

  • OS: Windows 11 ARM64, Build 26200
  • Claude Desktop: 1.7196.0.0 (MSIX Claude_pzs8sxrjxfjjc, arm64)
  • Bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
  • CoworkVMService: Running (verified via Get-Service)
  • VirtualMachinePlatform: Enabled
  • VPN / AV: None / Windows Defender only

Log signature (identical to canonical report)

[VM:steps] vm_boot completed (367ms)
[VM:steps] add_plan9_shares completed (12ms)
[VM:start] Still waiting for guest connection... 10178ms elapsed, 21 polls
[VM:start] Still waiting for guest connection... 50839ms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: add_plan9_shares
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds
[VM:start] Skipping auto-reinstall (already attempted once)

Steps already tried (none successful)

  • Manual Start-Service CoworkVMService (service runs stable, doesn't crash)
  • Full bundle delete + redownload (vm_bundles\ removed, 9 GB rootfs.vhdx re-extracted cleanly)
  • claude-code-vm SDK cache wipe
  • Removed .auto_reinstall_attempted marker
  • Reboot, fresh launch with 5+ minute wait

Notes

  • All other Claude Desktop functionality works on this device (chat, MCP servers, Claude Code CLI) — failure is isolated to Cowork
  • This blocks ARM64 users from a paid feature with no in-app indication that the platform is unsupported; the readiness check still shows all green

Please prioritize either (a) a fix, or (b) a clear "ARM64 not yet supported" banner in the Cowork tab so users don't spend hours troubleshooting an upstream bug.

AzraiIbrahim · 2 months ago

Adding detailed diagnostics for the same issue on Snapdragon X (Windows 11 Pro ARM64, Claude_1.15962.0.0_arm64).

Key finding: VM boots successfully but Linux guest kernel never responds

Full step sequence from cowork_vm_node.log:

  • create_network completed (0ms) ✓
  • create_vm_config completed (153ms) ✓
  • vm_boot completed (92ms) ✓
  • add_plan9_shares completed (6ms) ✓
  • Still waiting for guest connection... [10s, 20s, 30s, 40s, 50s]
  • Connection timeout, last completed step: add_plan9_shares

All prerequisites confirmed:

  • Hyper-V, VirtualMachinePlatform, HypervisorPlatform: all Enabled
  • bcdedit hypervisorlaunchtype: Auto
  • CoworkVMService: Running, Automatic startup
  • Windows 11 Pro (not Home)
  • ARM64-specific installer used

Root cause of this session: a prior session crashed with:
[Server] Persistent RPC: connection ended: message too large: 2065853797 bytes

This left an orphaned VM (confirmed via hcsdiag list, killed with
hcsdiag kill). After clearing it, subsequent attempts follow the
same pattern — VM hardware boots but vmlinuz never completes boot
and never signals ready.

Bundle version: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a

Hypothesis: vmlinuz in claudevm.bundle has a Snapdragon-specific
boot hang. The Windows-side infrastructure works correctly —
the failure is inside the guest kernel.

jpgett · 1 month ago

Confirmed, issues still exist, with Surface Pro 12, SnapDragon X Plus 8-core.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Windows & WSL problems

Browse all Claude Code issue topics →