[BUG] Cowork guest connection timeout after update 1.20186→1.21459 — guest connected 9× same morning on old version, 0× since (Windows 11 Home, low-end hardware)

What's Wrong?

Cowork fails with "VM connection timeout after 60 seconds" on every attempt since the app auto-updated from 1.20186.9.0 to 1.21459.0.0 on 2026-07-14.

Key evidence (from cowork_vm_node.log): the SAME machine, the SAME VM bundle (6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a), the SAME day:

• On 1.20186.9.0 (morning of 2026-07-14): guest connected successfully 9 times (06:53, 07:00, 14:53, 15:02, 15:19, 15:38, 15:56, 16:24, 16:43).
• At 16:43 the guest connected ~66s after boot — 6 seconds past the hardcoded 60s window. The app had already dispatched the failure, but the late connection was adopted on the next attempt ("VM already connected" at 17:00). This shows the machine is only marginally too slow for the 60s window.
• On 1.21459.0.0 (installed later the same day): guest has connected 0 times across 15+ attempts, including right after a clean cold reboot with maximum free RAM, and including 10+ minute quiet waits (no late connection ever arrives anymore).

Host-side steps all succeed every time

create_network completed (1ms-752ms)
create_vm_config completed (~500ms)
vm_boot completed (587ms-2372ms)
add_plan9_shares completed (26ms-115ms)
Still waiting for guest connection... (x100 polls)
Connection timeout, last completed step: add_plan9_shares
Startup failed: Error: VM connection timeout after 60 seconds

The guest is alive after the timeout: vmmem runs at ~500-670MB, and rootfs.vhdx/sessiondata.vhdx were observed being written 6+ minutes after boot. The guest works but never (since the update) reports ready.

Repairs attempted — all failed identically

1. Multiple app restarts and full app quits (clean VM shutdowns confirmed in log)
2. Full Windows reboot — killed a stale/zombie VM instance that was holding smol-bin.vhdx/rootfs.vhdx locks (EBUSY); after reboot, boots are clean, still no guest connection
3. Renamed sessiondata.vhdx — a fresh one (507MB) was created by the app; no change
4. Auto-reinstall path ran earlier the same day (bundle re-extracted from checksum-validated .zst); no change
5. Cold boot with nothing else running (max free RAM); no change

What Should Happen?

1. Increase the guest connection timeout (120-180s) or make it configurable — this machine misses the window by single-digit seconds on the old version.
2. Investigate what changed in 1.21459 guest startup: same bundle + same machine went from 9 successful connections to 0 on the day of the update.
3. Keep adopting late guest connections (the pre-update behavior effectively rescued this machine).

Environment

• Claude Desktop 1.21459.0.0 (MSIX, package Claude_pzs8sxrjxfjjc)
• VM bundle 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a
• Windows 11 Home SL 25H2, build 10.0.26200.8655, x64
• Positivo Duo C4128B-3: Intel Celeron N4020 (2 cores, 1.1GHz), 4GB RAM, eMMC storage (slow, HDD-class)
• VirtualMachinePlatform: enabled; HypervisorPlatform: enabled; hypervisor detected
• winnat kernel driver present (STOPPED at rest); CoworkVMService running
• No third-party antivirus, no VPN; 39GB+ free disk
• Note: machine has a flaky Wi-Fi adapter/driver (occasionally drops and requires reboot); ssh.log shows frequent "network-interface change detected; probing SSH controllers"

Is this a regression?

Yes — worked on 1.20186.9.0 the same morning (9 successful guest connections). Zero successes since 1.21459.0.0.

Likely related open issues

• #44007 — 60s timeout too short for slow-disk systems, guest stalls after add_plan9_shares (same exact log signature)
• #67066 — same signature, all repair paths exhausted (also reports flaky Wi-Fi driver)
• #65128, #42784

Platform / OS / Model

Claude Desktop (Cowork) · Windows · Sonnet/Fable (default)