Windows: CoworkVMService can't set its own crash recovery ("Access is denied") — once it dies, only a reboot brings Claude back

I had to reboot my machine three times in one workday (Sept 1) to get Claude Desktop running again. Digging through logs afterwards I found something I don't see reported yet.

The packaged Windows service (CoworkVMService / cowork-svc.exe) logs this warning every single time it starts, in C:\ProgramData\Claude\Logs\cowork-service.log:

Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.

There's a matching warning when it stops ("failed to disarm recovery actions for this stop... Access is denied"). So the service itself is telling us that if it ever dies uncleanly, Windows won't bring it back — and that's exactly what I experienced: once the service was down, the app wouldn't start at all, and nothing short of a reboot fixed it.

How it played out: I run Claude Desktop hard — multiple Claude Code sessions with subagents and MCP servers going at once. The window died three times that day. Twice the log shows GPU process gone at the moment of death (11:29:12 and 12:50:44); the third time it just stopped logging entirely. At the 12:50 death the app's own memory line read:

[process-memory] tree_rss_sum=15216MB electron(14)=2597MB children(251)=12618MB ... sys_free=21688MB/65209MB

After each death the main process stayed alive with no window, so clicking Claude just produced "Claude is being used by another program", and main.log shows:

second-instance: suppressing duplicate argv
Not main instance, returning early from app ready

Killing things in Task Manager didn't help much — there were a dozen claude.exe processes — and once the kill sweep caught the service, it stayed down per the warning above. A pending MSIX update (1.40609.0.0 → 1.40609.1.0) was also in the mix, which I gather is covered by #89912 / #89692 / #89648 / #89687, and the GPU/orphan side looks like #90105. The recovery-actions warning is the piece I haven't seen filed anywhere, and it seems to be what turns every one of these wedges into a full reboot.

Environment: Claude Desktop MSIX 1.40609.0.0 → 1.40609.1.0, Windows 11 Pro 10.0.26200, x64, 64 GB RAM.