[BUG] Claude VM workspace does not launch for ARM64 Claude Code.

[DarrylC73]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

[BUG] Claude VM workspace does not launch for ARM64 Claude Code.
Error: Failed to start Claude's workspace VM connection timeout after 60 seconds 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.

What Should Happen?

Claude Code should run the virtual machine

Error Messages/Logs

Error: Failed to start Claude's workspace VM connection timeout after 60 seconds 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.

Steps to Reproduce

Clean install of ARM64 Claude

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.63 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

No response

[github-actions]

Found 2 possible duplicate issues:

1. [BUG] Cowork ARM64: VM boots but guest never connects — "VM connection timeout after 60 seconds #39161
2. [BUG] Cowork: VM boots but guest never starts coworkd on Windows ARM64 (build 1.1.8629) #38945

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

[spinozza77]

Environment: Windows ARM64 (Snapdragon), no VPN, no antivirus/firewall
Issue: Cowork VM never connects. Error: "VM connection timeout after 60 seconds"
Steps already tried:

Restarted Claude app
Restarted computer
Reinstalled workspace via the link in the error message

History: First got a message saying Cowork wasn't available for ARM64. Then was prompted to download something. After that, the timeout error started appearing consistently.
Result: Cowork has never successfully launched on this machine.

[Stonespike]

Environment: Windows ARM64 Surface 12, Windows 11 Pro 25H2 build 26200.8037, no VPN.
Issue: Cowork VM never connects.
Error: "VM connection timeout after 60 seconds"

Steps already tried:

• Restarted app
• Restarted computer
• Reinstalled workspace
• Full clean uninstall via PowerShell
• Enabled Hyper-V and HypervisorPlatform manually.

Diagnostics: CoWorkVMService is Running (StartType: Automatic), but Get-VM returns nothing — the VM is never instantiated.
Result: CoWork has never successfully launched on this machine.

[parm485-create]

This issue still persists after few updates

[DarrylC73]

This issue still exists, please dont close

[shanleykk-arch]

issue still persists for me, i have followed all the above, FYI its same type of issue if use bluestacks or anything else that needs vm on the ARM machines

[adityasanghvi94-sketch]

Same issue for me - Windows ARM64 (Snapdragon), Claude Desktop version 1.1.9669, VM service fails to start after coworkd auto-updated on March 30, daemon console log is empty on all failed boots, one successful session on March 30 at 18:21 before the update took effect on subsequent boots.

[mariansan]

Is there a timeline for this issue to get solved? Windows ARM64, Surface Pro

[gordongeraghty]

Reproducing on Surface Laptop (Snapdragon X Plus) — VM boots fine, guest-side callback never arrives

Same issue on Microsoft's own ARM64 reference hardware. VM infrastructure boots cleanly in ~2s, then guest connection polling times out at 60s on every attempt.

Environment

Item | Value -- | -- Device | Microsoft Surface Laptop 13" (1st Ed, Snapdragon) CPU | Snapdragon X Plus, 8-core @ 3.30 GHz OS | Windows 11 Home 10.0.26200 (build 26200, ARM64) RAM | 15.6 GB Claude Desktop | 1.2581.0.0 ARM64 (Microsoft Store) Hyper‑V | vmcompute + HvHost Running Install type | MSIX (Microsoft Store)

cowork_vm_node.log excerpt — clean attempt on a fresh bundle after admin vmcompute bounce + bundle wipe:

2026-04-15 15:51:13 [info] [VM:start] Beginning startup, bundlePath=...\vm_bundles\claudevm.bundle
2026-04-15 15:51:13 [info] [VM:start] Bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
2026-04-15 15:51:13 [info] [VM:start] smol-bin.arm64.vhdx copied successfully
2026-04-15 15:51:14 [info] [VM:start] Windows VM service configured
2026-04-15 15:51:14 [info] [VM:steps] create_network completed (4ms)
2026-04-15 15:51:14 [info] [VM:steps] create_vm_config completed (320ms)
2026-04-15 15:51:17 [info] [VM:steps] vm_boot completed (2242ms)
2026-04-15 15:51:17 [info] [VM:steps] add_plan9_shares completed (20ms)
2026-04-15 15:51:27 [info] [VM:start] Still waiting for guest connection... 10209ms elapsed, 21 polls
2026-04-15 15:51:37 [info] [VM:start] Still waiting for guest connection... 20348ms elapsed, 41 polls
2026-04-15 15:51:47 [info] [VM:start] Still waiting for guest connection... 30562ms elapsed, 61 polls
2026-04-15 15:51:58 [info] [VM:start] Still waiting for guest connection... 40779ms elapsed, 81 polls
2026-04-15 15:52:08 [info] [VM:start] Still waiting for guest connection... 50900ms elapsed, 101 polls
2026-04-15 15:52:17 [error] [VM:start] Connection timeout, last completed step: add_plan9_shares
2026-04-15 15:52:17 [error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds

Key observations

• Every infrastructure step on the host side succeeds (bundle copy, VM service config, network, VM config, vm_boot, add_plan9_shares). The host thinks it did its job correctly.
• vm_boot completes in ~2s — the VHDX is being accepted by Hyper-V.
• After add_plan9_shares, the host polls for the guest agent. Five full 10s polling intervals pass with zero guest response. If the guest were booting slowly, you'd expect a late connection; instead there's total silence.
• Pattern is consistent across 4+ attempts today with different VM instance IDs (d7379363-a728-450e-b714-5b5507b442a5, 3dad6186-c18e-421a-b042-5a458560ee42, etc.) — rules out a one-off glitch.
• Each timed-out attempt leaves an orphan vmwp process holding smol-bin.vhdx, causing subsequent attempts to fail with the earlier VM is already running / EBUSY symptom until vmcompute is bounced (admin). This is a compounding bug — users who click "retry" in the UI get stuck in the lock-loop.

What I've already tried (all failed)

• doneRestart Claude Desktop (quit via tray, kill WindowsApps processes, relaunch)
• doneRestart-Service CoworkVMService -Force
• doneStop-Service vmcompute -Force + restart (releases orphan VM's VHDX lock)
• doneWipe %APPDATA%\Claude\vm_bundles + %APPDATA%\Claude\claude-code-vm and re-extract
• doneClicking "reinstall the workspace" in the UI error banner
• doneRan the full sequence above with all of the above, admin-elevated, in a single clean attempt

Every variation produces the same add_plan9_shares → 60s silence → timeout pattern.

Suggested remediation priorities (for the team)

1. Get logs from inside the guest — the guest agent is clearly not reaching the point of dialling back. Is smol-bin.arm64.vhdx actually executing init? Is the Plan 9 / vsock listener binding? A console/serial dump of the guest kernel on ARM64 would be conclusive.
2. Decouple "VM failed to start" from "VM orphan cleanup" — the current behaviour leaks a vmwp per failed attempt, turning a recoverable startup error into a lock-out requiring admin intervention. Adding an unconditional hcsdiag kill on timeout would at minimum stop the bleeding.
3. Surface a clearer UI state when the guest-side agent isn't coming up — currently the "reinstall the workspace" button suggests bundle corruption, which it isn't; it's a guest-runtime problem.

Happy to provide additional logs (main.log, HCS event logs, guest-side dumps if there's a way to extract them) — just ask.

[github-actions]

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