[BUG] Desktop auto-updater quit-and-installs while a Cowork task is running, killing the VM mid-task — updater should defer while VM sessions are active

Environment

• OS: macOS 26 (Darwin 25.6.0), Apple Silicon (M5), 16 GB RAM
• Claude Desktop: 1.10628.0 → 1.10628.2 (auto-update rollout window Jun 3–4, autoDownloadInBackground=true)
• Cowork VM SDK: 2.1.160 / 2.1.161
• Plan: Max

Summary

Three consecutive Cowork task attempts across two days each died 20–45 seconds after starting. From the user's chair this presents as "Cowork crashes every task." Nothing actually crashes: in every attempt the VM boots clean and the task starts — then the Desktop auto-updater quit-and-installs the pending update, the quit handler runs cowork-vm-shutdown, and the running task is killed.

The failure window is exactly the update-rollout window: once 1.10628.2 finished installing (by killing the last task attempt), no update was pending and the next task ran perfectly to completion on the same machine, same config.

Evidence chain (from logs only)

1. No real crashes anywhere. Crashpad store empty; no DiagnosticReports entries; every quit ran a graceful beforeQuit cleanup.

2. The VM is healthy on every attempt (cowork_vm_node.log, attempt of Jun 4 07:10 ET):

07:10:44 [VM:steps] vm_boot completed (753ms)
07:10:51 [VM] Network status: NOT_CONNECTED      ← transient, resolves <1s
07:10:51 [VM] Network status: CONNECTED
07:10:52 [VM] API reachability: REACHABLE
07:10:52 [VM:steps] sdk_install completed (0ms)   ← SDK 2.1.160
07:10:52 [VM:start] Startup complete, total time: 9384ms

3. Every VM death is the app quitting. All 10 VM shutdowns Jun 2–4 log isAppQuit: true / "App quit, stopping VM". Zero other shutdown causes:

cowork_vm_swift.log:  2026-06-03 12:59:33 Stopping VM (isAppQuit: true)...
cowork_vm_swift.log:  2026-06-03 13:01:43 Stopping VM (isAppQuit: true)...
cowork_vm_swift.log:  2026-06-04 07:11:27 Stopping VM (isAppQuit: true)...

4. The quits are the auto-updater installing. main.log + ShipIt:

main.log:  2026-06-04 07:11:19 [updater] Update downloaded and ready to install { releaseName: 'Claude 1.10628.2' }
main.log:  2026-06-04 07:11:27 beforeQuit: handler fired, going down          ← task VM had been up 35s
ShipIt_stderr.log:  2026-06-04 07:11:43 Successfully launched application at file:///Applications/Claude.app/

The Jun 3 12:59:32 quit fired 2 seconds after the space-creation URL reload (Reloading current URL: 'https://claude.ai/space/<id>') with 1.10628.0 pending since 06:06 — so the install trigger appears tied to window reload / perceived-idle moments, which is precisely when a user has just kicked off a Cowork task.

5. Control case: after 1.10628.2 was fully installed and the updater check came back empty, the next Cowork task on the same machine booted in 11.9 s (SDK 2.1.161), reached Startup complete, spawned guest processes, and ran with no issue.

Repro

1. Have an update pending (Update downloaded and ready to install in main.log).
2. Create a Cowork space / start a task (VM boots, task starts).
3. Updater quit-and-installs within seconds-to-minutes → onQuitCleanup: cowork-vm-shutdown kills the running task.

Expected behavior

The updater should defer quitAndInstall while the Cowork VM has active sessions/tasks (or prompt before restarting, or checkpoint-and-resume the task across the restart). A user-visible "update will install when your task finishes" state would also resolve the perception problem — three kills in a row reads as "Cowork is fundamentally broken," when the subsystem is actually fine.

Ruled out

• Memory pressure / jetsam (no events; 16 GB machine but VM memory fine)
• VM image/network corruption (e2fsck clean, boots clean every attempt, API reachable)
• MCP/extension config (crashes predate config changes; VM doesn't consume that config)

Related

• #43719 — auto-update wiped Cowork session disk. Same root family (updater acting while the VM is/was active); different blast radius (data loss vs. task kill). Together they suggest the updater currently has no awareness of Cowork VM state at all.