Windows: CoworkVMService fails to configure crash-recovery ("Access is denied") — service stays down until full reboot, blocking Claude Desktop startup

Environment

• Claude Desktop: 1.44121.4 (Windows)
• OS: Windows 10.0.26200 (Windows 11)
• Service: CoworkVMService, C:\Program Files\WindowsApps\Claude_1.44121.4.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

What happens

On every start, CoworkVMService logs:

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

Because the recovery-action configuration itself fails, Windows Service Control Manager has no auto-restart policy for this service. If it ever exits unexpectedly, it stays down — Claude Desktop can no longer reach it over \.\pipe\cowork-vm-service and reports something is preventing it from starting. The only recovery is a full machine reboot, which re-triggers the service's Automatic startup.

This is not a one-off: the same warning appears 42 times in C:\ProgramData\Claude\Logs\cowork-service.log, i.e. every service start since logging began, and I hit the resulting hard-stop twice today.

Log excerpt

2026/09/03 11:32:41.148277 Starting CoworkVMService as Windows service
2026/09/03 11:32:41.151621 Claude VM Service starting...
2026/09/03 11:32:42.152165 [Server] Signature verification initialized
2026/09/03 11:32:42.153054 [Server] Named pipe server listening
2026/09/03 11:32:42.153054 Service ready. Listening on \.\pipe\cowork-vm-service
2026/09/03 11:32:42.153560 Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.

Likely cause

The service appears to call something like ChangeServiceConfig2 (SERVICE_CONFIG_FAILURE_ACTIONS) on itself at startup, which needs SERVICE_CHANGE_CONFIG access on its own SCM handle. If the service runs under an account/token that doesn't hold that right on its own service object (or a security policy strips it), the call fails silently into this warning, and failure-action configuration is simply never applied.

Impact

When the underlying VM/session process crashes for any other reason, there's no recovery path short of a full OS reboot — disruptive on a machine that's otherwise up and running.

Suggested fix

Either grant the service account SERVICE_CHANGE_CONFIG on its own service (e.g. via an SDDL security descriptor set at install time with sc.exe sdset), or set the failure-action policy from the installer/MSI at service-creation time rather than from within the running service.