[BUG] Cowork ARM64: VM boots but guest never connects — "VM connection timeout after 60 seconds

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/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

is there a solution for this issue? i am facing exactly the same issue

is there a solution for this issue? i am facing exactly the same issue

Nothing yet, developers need to fix it.

Adding a +1 on Windows 11 Home ARM64, OsBuildNumber 10.0.26200, Claude Desktop 1.2581.0.0 (latest MSIX, ARM64). Failure mode is identical to the canonical report — VM boots, add_plan9_shares completes in ~16 ms, guest never opens the HvSocket back to the host, 60 s timeout.

Posted a fuller writeup with logs + a positive control (WSL2 boots fine on the same machine with the same VBS / HVCI / Secure Launch posture, ruling out host-side hypervisor breakage as the cause) on #45480.

Last week it is working correct but then after an update of claude Desktop it failed, is there a way to downgrade to older versions ?

+1, still broken on Snapdragon X Plus / Windows 11 Home ARM64 (Build 26200) as of Claude Desktop 1.3109.0.

Key data point: the broken VM image (smol-bin.arm64.vhdx) has been frozen at the same hash for ~3 weeks across multiple Claude Desktop releases:

| Date | Claude Desktop | VM image hash |
|---|---|---|
| 2026-03-24 (OP) | 1.1.8629.0 | fb30784dadb34104626c8cf6d8f90dd47cd393cc |
| 2026-04-16 | 1.3036.0 | 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d |
| 2026-04-17 (today) | 1.3109.0 | 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d |

Anthropic shipped one updated VM image since the original report, but every release since has bundled the same broken 5680b11b… image. App-side updates can't fix this — the kernel/init in the Linux guest never reaches the point of opening the HvSocket back to the host.

Latest log from today (%APPDATA%\Claude\logs\cowork_vm_node.log):

2026-04-17 16:51:28 [info] [VM:start] Bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
2026-04-17 16:51:29 [info] [VM:steps] vm_boot completed (102ms)
2026-04-17 16:51:29 [info] [VM:steps] add_plan9_shares completed (3ms)
2026-04-17 16:51:39 [info] [VM:start] Still waiting for guest connection... 10227ms elapsed, 21 polls
...
2026-04-17 16:52:29 [error] [VM:start] Connection timeout, last completed step: add_plan9_shares
2026-04-17 16:52:29 [error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds
2026-04-17 16:52:29 [info] [VM:start] Skipping auto-reinstall (already attempted once)

coworkd.log is 0 bytes — the daemon never starts inside the guest, matching the failure mode in #38945.

Workspace reinstall (delete vm_bundles\claudevm.bundle + restart) does not help because the freshly-copied image is still the same broken 5680b11b… bits from Program Files\WindowsApps. A new ARM64 VM image needs to be shipped.

Re: @jtuttas's regression report — interesting that it worked for you previously and broke after an update. On this Snapdragon X Plus it has never worked across any version.

It worked for me for two sessions, i installed WSL but its broken again. This is what claude told me ARM64 Hyper-V on Snapdragon X is fragile across sleep cycles — the hypervisor loses track of the VM, the guest clock desyncs, TLS handshakes fail, and the host sees "VM running, guest silent." Your ssh.log shows seven powerMonitor resume / unlock-screen events between yesterday afternoon and this morning. Each sleep/resume is a coin flip on whether Cowork survives. Now no matter what i tried its not working

Environment: Windows 11 ARM64 (build 26200), Claude desktop 1.8555.0, corporate-managed machine

Root cause confirmed via logs: VBS fully enabled with Credential Guard + HVCI enforced (policy, not user-configurable). This slows Hyper-V VM boot to ~150s on this hardware, but the guest connection timeout is 60s — so Claude always gives up before the guest agent is ready.

Observed timeline:

• T+0s — VM boot starts
• T+0–25s — rootfs.vhdx decompression (HVCI overhead)
• T+60s — Claude times out, triggers auto-reinstall
• T+~90s — Linux guest finishes booting (confirmed in Hyper-V worker log)
• T+~150s — Guest negotiates VTL0 virtual PCI channel

The SSH manager log shows only re-initializations, never a successful connection — the timer fires before the guest can answer.

Workaround: Waiting ~3 min after app launch before using Cowork allows the retry cycle to catch the VM in a ready state.

Ask: Increase the guest connection timeout (or implement retry-without-reinstall) for machines where VBS/HVCI is active. The current 60s is ~2.5× too short for this config.

Same here, can confirm on ARM64.

Hitting the identical "VM connection timeout after 60 seconds" on a Snapdragon
machine. The app and the rest of Cowork run fine (chat and connectors all work),
but the workspace itself never connects, so the sandboxed shell and anything
depending on it is dead. Worked through the usual fixes (full quit and relaunch,
reboot, workspace reinstall) with no change.

My hardware and OS build are close to OP's (Lenovo Snapdragon, Windows 11 build
26200), so this looks like a clean reproduction on near-identical kit. Two things
that differ and might help narrow it down:

1. Install method. I'm on the standard .exe installer from claude.com, not a

manual MSIX via Add-AppxPackage. Same VM timeout regardless, so the failure
doesn't seem tied to the MSIX install route.

1. Version. I'm on 1.9659.2.0, a much newer release line than OP's 1.1.8629, so

this is still happening months on and a newer build hasn't fixed it.

Environment
OS: Windows 11 Pro 25H2, build 26200.8457
Architecture: ARM64 (Snapdragon X Plus X1P42100, Qualcomm Oryon), 32 GB RAM
Device: Lenovo IdeaPad Slim 5 14Q8X9
Claude Desktop version: 1.9659.2.0
Install method: Standard .exe installer from claude.com
Symptom: app and Cowork chat work, workspace VM times out after 60s on every start

Surface error is identical to OP: "VM connection timeout after 60 seconds".

Attaching my main, cowork_host_loop_debug and cowork_vm_node logs so you can see
the full startup sequence and where it stalls.

main.log

cowork_host_loop_debug.log

cowork_vm_node.log

Any further update on this???

I'm regretting buying a Claude Pro subscription and installing the Claude Desktop app on my HP OmniBook 5 laptop.

Processor Snapdragon(R) X - X126100 - Qualcomm(R) Oryon(TM) CPU (2.96 GHz)
Installed RAM 16.0 GB (15.6 GB usable)
Graphics card Qualcomm(R) Adreno(TM) X1-45 GPU (128 MB)
Storage 141 GB of 954 GB used
System type 64-bit operating system, ARM-based processor

Error in Cowork:

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.

The error "Failed to start Claude's workspace, VM connection timeout after 60 seconds" keeps coming. Do we have a fix for this?

+1, same failure — Windows 11 Pro 25H2 ARM64, Snapdragon X Plus

Confirming this exact failure signature on another machine. Environment:

• Device: Snapdragon X Plus ARM64 (Windows 11 Pro, version 25H2, build 26200.7462)
• Claude Desktop: 1.24012.9.0 (arm64 MSIX)
• Hyper-V: Confirmed enabled and working (vmms running, Get-VM/Get-HnsNetwork all functioning normally) — ruled out as a Windows-host-side config issue before filing this

Log (cowork_vm_node.log)

[VM:steps] vm_boot completed (1064ms)
[VM:steps] add_plan9_shares started
[VM:steps] add_plan9_shares completed (7ms)
[VM:start] Still waiting for guest connection... 10213ms elapsed, 21 polls
[VM:start] Still waiting for guest connection... 20393ms elapsed, 41 polls
[VM:start] Still waiting for guest connection... 30510ms elapsed, 61 polls
[VM:start] Still waiting for guest connection... 40699ms elapsed, 81 polls
[VM:start] Still waiting for guest connection... 50853ms elapsed, 101 polls
[error] [VM:start] Connection timeout, last completed step: add_plan9_shares
Startup failed: Error: VM connection timeout after 60 seconds

Matches the pattern described in this thread and #44007: VM boots, add_plan9_shares completes cleanly, then the guest agent never responds — stalls silently until the 60s timeout regardless of how many polls occur (101 polls / ~51s of waiting here before cutoff).

Troubleshooting already ruled out

• Hyper-V freshly enabled + confirmed working (vmms service running, Get-VM functional)
• Get-HnsNetwork / Get-NetNat show no conflicts or missing NAT rules
• Full Claude Desktop restart
• Workspace reinstall via in-app option
• No VPN/tunnel adapters active

Given this happens after add_plan9_shares with zero guest-side activity afterward, it really looks like the guest kernel/agent is stalling inside the ARM64 VM image itself rather than a host networking/config problem. Happy to grab additional diagnostics (e.g. hcsdiag, VM console output) if it'd help triage.