Windows: CoworkVMService (cowork-svc.exe) crashes silently and stays down until reboot — recovery actions never armed (Access denied), app reinstall wipes manual config

Summary

The Cowork VM Windows service (cowork-svc.exe, service name CoworkVMService, display name "Claude") terminates unexpectedly (Service Control Manager event 7034) and stays down until the machine reboots, because the service fails to configure its own SCM recovery actions. While it is down, Cowork sessions show "Unable to access your computer" ("Impossible d'accéder à votre ordinateur") with no hint that the local service is dead, so the user's only apparent fix is rebooting the PC — in my case, daily.

Environment

• Claude desktop app 1.46388.4 (MSIX / Microsoft Store install, migrated from Squirrel)
• Windows 11 Home, build 10.0.26200, locale fr-FR
• AMD Ryzen 5 5600H (iGPU) + Radeon RX 5500M, 32 GB RAM
• Electron 42.10.0 / Chrome 148.0.7778.280 (from the app's debug info export)

Observed crashes (local time, UTC−4)

Three unexpected service terminations in 10 days, from the System event log:

| Date | SCM 7034 | Notes |
|---|---|---|
| 2026-08-27 19:44:09 | "Le service Claude s'est terminé de façon inattendue" | |
| 2026-09-04 11:12:22 | same | |
| 2026-09-06 11:02:50 | same | App MoAppHang (WER 1002, claude.exe) follows 4 seconds later at 11:02:54, simultaneous with a main-process event-loop-stall of 3537 ms in webrequest:before-send-headers |

cowork-service.log shows no error at any crash time — logging just stops mid-stream and resumes at the next service install (looks like an unlogged panic / hard exit). No WER APPCRASH report is generated for cowork-svc.exe either, so there is no dump to attach.

Why it stays down (the design part of the bug)

1. At every start/stop the service logs:

``
Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.
Warning: failed to disarm recovery actions for this stop: open service: Access is denied.
``
So SCM recovery is never armed and a crash leaves the service dead.

1. Recovery actions cannot be set persistently by an admin either: the app reinstalls the service each session (repeated SCM 7045 events) and toggles start type Automatic↔Disabled (7040), wiping any manually configured failure actions.
2. The desktop app does not detect/restart the dead service; sessions just show "Unable to access your computer" until the user reboots.

Workaround I deployed (validated)

User-level scheduled task triggered by System event 7034 (Service Control Manager) that runs sc.exe start CoworkVMService after 5 s. Verified end-to-end: taskkill /F /IM cowork-svc.exe → 7034 logged → task fires → service back to Running in ~6 s, sessions reconnect. This confirms that simply restarting the service is a full recovery — SCM failure actions set at install time (or app-side detection) would fix this properly.

Suggested fixes

• Grant/arrange the permissions the service needs to arm its own SCM recovery actions at install (it already tries), or set FailureActions from the elevated installer.
• Have the app detect a dead CoworkVMService and restart it (it already has start rights) instead of surfacing a generic "cannot access your computer".
• Make cowork-svc.exe log panics/fatal errors before exiting so crashes are diagnosable.

Additional context

• A diagnostic log export (generated 2026-09-06 15:10 UTC via the in-app log export) covering all three crash windows is available on request.
• Possibly unrelated, from the same export: GPU acceleration is fully disabled in the app on this machine (gl=none, angle=none, skiaBackendType: None, all adapters inactive) — hybrid AMD graphics with mismatched driver versions plus a "Trigger 6" USB display adapter; the app runs software-rendered.