Cowork VM: guest_vsock_connect fails after rootfs auto-update (SDK 2.1.32 → 2.1.34)

Summary

After the Cowork VM rootfs image auto-updated (SDK 2.1.32 → 2.1.34), the workspace VM fails to start with "VM connection timeout after 60 seconds". The VM boots successfully but the guest agent (coworkd) never connects back via vsock.

After resetting the VM bundle, a secondary error occurs: "user adoring-keen-mayer should already exist but does not" — because stale session data references a user from the old VM that no longer exists in the fresh one.

Environment

• macOS 26 (Darwin 25.2.0), Apple Silicon
• Claude Desktop (latest as of 2026-02-11)
• VM SDK: 2.1.34
• Previously working SDK: 2.1.32

Reproduction

The issue occurred automatically after the VM rootfs image was updated:

1. Cowork workspace was working normally on 2026-02-06 (SDK 2.1.32)
2. On 2026-02-10 ~19:28, rootfs.img was auto-updated (new origin hash: fc96f5bc6a7aeee6e651437eba3c76d0fe9a16f3)
3. From 2026-02-10 19:58 onward, every VM startup attempt fails at guest_vsock_connect
4. Persists across Claude Desktop restarts, computer restarts, and Claude Desktop reinstallation

Log evidence

From cowork_vm_swift.log — last successful connection vs. failures:

# Last success (Feb 6):
[VM] 2026-02-06 12:56:49 [info] VM startup step: guest_vsock_connect started
[VM] 2026-02-06 12:56:55 [info] Guest connected
[VM] 2026-02-06 12:56:55 [info] VM startup step: guest_vsock_connect completed
[VM] 2026-02-06 12:56:56 [info] Guest ready
[VM] 2026-02-06 12:56:57 [info] SDK installed successfully: version=2.1.32

# First failure after rootfs update (Feb 10):
[VM] 2026-02-10 19:58:29 [info] VM startup step: guest_vsock_connect started
# ← never completes, no "Guest connected" ever appears

# Pattern repeated ~10 times on Feb 11 with identical result

From cowork_vm_node.log:

2026-02-11 14:28:41 [error] [VM:start] Connection timeout, last completed step: vm_boot
2026-02-11 14:28:41 [error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds

The coworkd.log (guest console) has no entries after Feb 10 16:17 (before the rootfs update), confirming the guest agent never starts in the new image.

Workaround

Two-step reset required (with Claude Desktop quit):

Step 1 — Delete the VM bundle:

rm -rf ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/

Step 2 — Delete stale session data (otherwise you get "user ... should already exist but does not"):

rm -rf ~/Library/Application\ Support/Claude/local-agent-mode-sessions/*

Then relaunch Claude Desktop. It recreates the VM bundle and sessions from scratch.

Notes

• Reinstalling Claude Desktop does NOT fix this, since the VM bundle and session data in Application Support are preserved
• The stuck VM process consumed 99%+ CPU while waiting for the guest connection
• The stale session error is a secondary issue: after resetting the VM bundle, the old sessions reference a user/home directory that doesn't exist in the new VM. Ideally the app would handle this gracefully (e.g., recreate the user or prompt to start a fresh session)