[BUG] Cowork (macOS): session start hangs forever at "Preparing session…" on a long-lived VM — coworkd silent since boot, no timeout or error

Summary

On macOS, a Cowork session can hang indefinitely at Preparing session… with no error, no timeout and nothing in the logs. The session-start request is issued to a long-lived Cowork VM and is never answered. Restarting the app reboots the VM and fixes it. Nothing short of that recovers.

This looks like the same class as #91496 and #92921 (silent Cowork hangs), but it's a different trigger: it happens before the first turn, on macOS, on a VM that had been up for ~20h and whose coworkd had logged nothing since boot.

Environment

• macOS (Apple Silicon, M1 Pro), Claude Desktop, early-August 2026 build
• Observed 2026-08-05. It hasn't been re-verified on the current build (2.9939.2), because reproducing it needs a VM that has been up for many hours.

Observed

• The chat stayed on Preparing session… for at least 10 minutes (checked at 4m48s and again at 10m).
• main.log shows that the session start was issued. Nothing else followed, and there was no error:

``
19:04:54 [info] Starting local session local_… in /home/<vm-user>
19:04:54 [warn] Transcript not found for session local_… (cliSessionId: none)
19:12:10 [warn] Transcript not found for session local_… (cliSessionId: none)
``

• The Cowork VM process was alive but inert: up 20h24m, 0.2% CPU, holding vm_bundles/claudevm.bundle/{rootfs,sessiondata}.img.
• coworkd.log had last been written 73,317s (~20.4h) earlier, meaning nothing had been logged since the VM booted.
• The session needed a new VM user. coworkd had only recovered the pre-existing users at boot (recovered=4 skipped=1) and never created the new one.
• The session's uploads/ directory was created but stayed empty, because the attached ZIP never staged. Uploads had worked on earlier days.
• audit.jsonl held only the user message. There was no assistant turn and there were no tool calls.
• The main process was healthy: main.log was being written (age 20s) and the Electron libuv threadpool had plenty of free workers. This is not a main-process stall.

After restarting the app

19:14:56 Guest ready
19:14:57 API reachability: REACHABLE
19:14:58 SDK installed successfully: version=2.1.221
coworkd.log age: 37s   (was ~73,000s before restart)

The session record and the prompt survived the restart. The un-staged upload did not, so it had to be re-attached.

Expected

1. Session start should time out and show an actionable error (with a retry or VM-restart option) rather than spinning forever.
2. coworkd liveness should be health-checked before a session is dispatched to a long-lived VM, and a wedged VM should be restarted automatically.

Detection one-liner (for anyone hitting this)

echo $(( $(date +%s) - $(stat -f %m ~/Library/Logs/Claude/coworkd.log) ))s   # hours-old while a session is "preparing" => wedged

Note: com.apple.Virtualization.VirtualMachine.xpc is also used by Docker Desktop. To confirm which process is Claude's VM, use lsof -p <pid> | grep claudevm.bundle.