CoworkVMService restarts silently kill running scheduled-task sessions mid-turn — no recovery actions configured

Summary:
On Windows, the CoworkVMService ("Claude VM Service") restarts under memory pressure, silently terminating any Claude session that happens to be running at that moment — including scheduled/background tasks. The affected session leaves no error in its transcript; it simply stops after the last tool result. lastRunAt for the scheduled task still shows as completed, so there is no way to detect the failure from the task metadata alone.

Evidence (gathered 2026-08-19 on a Windows 11 machine, 16 GB RAM):

• Service log (C:\ProgramData\Claude\Logs\cowork-service.log) shows the sequence: Persistent RPC: connection ended: failed to read length: EOF → Service stop requested → Service ready (~90s later). The app-side RPC connection drops first; the service restart follows.
• This coincided with heavy memory pressure: system free RAM at 250–900 MB out of 16 GB during the affected windows, with 15–30+ concurrent claude.exe processes from scheduled-task sessions.
• Frequency of service stops escalated day over day: 2 (08-17) → 5 (08-18) → 11 (08-19), roughly doubling daily as background task load grew.
• Multiple scheduled sessions died in the same ~8-second window on separate occasions, confirming this isn't isolated to one task — it kills whatever happens to be running when the restart occurs.
• One task killed mid-run was itself a monitoring/cleanup task, meaning the safety-net task can be taken down by the same failure it's meant to guard against.

The part that concerns us most:
Every service startup logs this warning:
Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.

We checked the service's security descriptor (sc.exe sdshow CoworkVMService) — SERVICE_CHANGE_CONFIG is granted only to a specific internal service SID, not to Authenticated Users/Administrators. So even a local admin cannot configure Windows Service Recovery actions via services.msc or sc.exe failure — this looks like a deliberate security hardening choice, not a bug, but it means if the service ever crashes instead of stopping cleanly, it stays down until the whole machine reboots — and nothing currently detects or alerts on that, since Windows' own recovery mechanism is unavailable to us.

What would help:

1. Either build in the service's own recovery-action configuration at install time (so it self-heals from a crash without needing external sc.exe access), or
2. Expose a supported way to detect "service is down and won't restart" from within the app/scheduled-tasks system, so a stuck fleet doesn't fail silently, or
3. Reduce the RPC-connection sensitivity to short-term memory pressure so a busy-but-healthy machine doesn't trigger a full service bounce that kills unrelated running sessions.

Environment: Windows 11, Claude Desktop app version 1.32885.1 (MSIX/Windows Store install), heavy scheduled-task usage (dozens of automated tasks running throughout the day).

Happy to share the raw log excerpts if useful.