Cowork — all tasks stuck "running" (locked composer) after hard reboot

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Reporter: Sebastian Lissarrague (PayPal Claude users org)
Date: 2026-06-08
App: Claude Desktop 1.11187.4 · macOS 15.5 (Darwin 25.5.0), Apple Silicon

Summary
After a hard reboot, every existing Cowork task shows a perpetual "running" spinner with a
locked / non-interactive composer (no Send, no Stop, no buttons at all). New chats are unaffected.
The state survives full app quit AND multiple clean cold boots.

Impact
All ~40 existing Cowork tasks are unusable (cannot type, cannot stop, cannot interact). Work product is
intact on disk; only the live task threads are frozen.

Root cause (from logs)
The hard power-off left the Cowork VM's virtual disk unclean. On every Claude launch the VM runs e2fsck
and "recovers" all tasks back into a running state, but the per-task host loops never re-attach — so
each task's composer stays locked waiting on a turn with no process behind it.

Evidence — ~/Library/Logs/Claude/coworkd.log (repeats every launch):
[coworkd] running e2fsck on /dev/nvme1n1
[coworkd] user recovery complete: recovered=40 skipped=1 failed=0
Five such recovery cycles across ~33 min of launches (21:31 / 21:34 / 21:36 / 21:38 / 22:04 UTC).

~/Library/Logs/Claude/cowork_vm_node.log shows repeated [startVM] VM already connected +
[Keepalive] Already running. No per-task host-loop processes are present on the host (only MCP servers).
launchctl shows no watchdog — recoveries map to manual app launches, not a self-restart loop.

Confirmed NOT the cause (already ruled out)
Not renderer cache: cleared GPUCache + Code Cache, relaunched — no change.
Not window/zoom geometry: window fully on-screen (1320×1108 @ x:1262 on a 3840×2160 display).
Not a wedged MCP server: all MCP servers initialize clean.
Not host-side task state: searched IndexedDB / Local Storage / Session Storage for any task
running-flag — none found. The stuck state lives inside the VM and is restored on every recovery.

Reproduction
Have multiple Cowork tasks.
Hard-reboot / hard power-off the Mac (unclean VM shutdown).
Relaunch Claude → VM runs e2fsck, recovers all tasks → every task opens "running" with a dead composer.

What did NOT fix it
Full Cmd+Q + relaunch (x multiple)
Full macOS reboot
Clean cold boot left untouched 2–3 min to let recovery settle
GPUCache / Code Cache clear

Requested fix
A way to clear the stale per-task "running" lock on VM recovery (recovery should reset tasks to idle,
not restore them as in-flight). Recovery reports failed=0, so task data is intact and recoverable.

Do NOT want
A VM rebuild that wipes the ~40 task sandboxes — the histories are the asset.

Diagnostics available on request
coworkd.log, cowork_vm_node.log, cowork_vm_swift.log under ~/Library/Logs/Claude/.

What Should Happen?

Claude desktop text boxes shouldn't be frozen and should accept typing into them

Error Messages/Logs

Steps to Reproduce

Reproduction
Have multiple Cowork tasks.
Hard-reboot / hard power-off the Mac (unclean VM shutdown).
Relaunch Claude → VM runs e2fsck, recovers all tasks → every task opens "running" with a dead composer.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code 2.1.169

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Warp

Additional Information

_No response_