CoworkVMService crashes silently (no clean shutdown, no auto-recovery) — mid-session work lost, twice in one day

Environment

• Claude desktop app version: 1.46388.4.0 (Windows Store package Claude_pzs8sxrjxfjjc)
• claude.exe also seen crashing separately: version 2.1.257.0, WER event RADAR_PRE_LEAK_64 at 08:01:29 AM
• OS: Windows 11 Home Single Language 10.0.26200
• Log source: C:\ProgramData\Claude\Logs\cowork-service.log, Windows Application event log

What happened
CoworkVMService (the Windows service backing the VM/worktree agent backend) crashed twice in one day without warning, at 10:07:08 AM and 11:03:21 AM local time. Both sessions running at the time were killed mid-task and had to be restarted, losing in-progress work and conversation context that had to be redone — this cost significant time, rework, and usage quota.

Evidence

1. Both restarts skip the normal clean-shutdown sequence. Every prior restart in the log (09/03–09/05) shows:

Service stop requested
Shutdown signal received...
[Server] Stopping server...
[Server] Server stopped
Service stopped.
Starting CoworkVMService as Windows service

Today's two restarts jump straight to Starting CoworkVMService as Windows service with none of the above — i.e., the process died rather than stopped cleanly.

1. Every startup, including both crash-restarts, logs:

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

The service cannot grant itself permission to configure Windows SCM auto-restart-on-failure, so nothing brings it back after a crash — it requires a manual restart every time.

1. No crash dump or exception is captured in the Application event log for cowork-svc.exe itself around either timestamp — the process appears to disappear rather than fault in a way Windows Error Reporting catches.

1. Two active Claude Code sessions were mid-task when this happened; their transcripts show a hard cutoff (last event stops mid-flight) followed by a fresh SessionStart re-initialization in a different session directory a few minutes apart — consistent with the service crash forcing an unplanned restart rather than a normal user-initiated new session.

Impact
In-progress work had to be redone from scratch after each crash, and conversation context built up over the session was lost. This happened twice in a single day on the same machine.

Requested fix

• Root-cause why cowork-svc.exe is crashing (no dump available on my end — happy to provide more logs if there's a way to capture one).
• Fix the "Access is denied" on configuring service recovery actions, so a crash doesn't require a manual restart to notice and recover from.