CoworkVMService fails to configure SCM recovery actions (Access denied) — no auto-restart after crash

Description

On Windows, the Claude Code background service CoworkVMService (display name "Claude") logs the following warnings in the Application event log shortly after startup:

Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access is denied.
Claude VM Service: failed to disarm SCM recovery actions for this stop; if the stop overruns, the service may be auto-restarted during package servicing: open service: Access is denied.

sc.exe qfailure CoworkVMService confirms no recovery actions are configured (RESET_PERIOD: 0, no restart action).

Impact

When the underlying VM/sandbox service crashes, it does not restart automatically. The Claude Code desktop app then fails to relaunch normally — the only workarounds are:

1. Manually restarting the service from an elevated PowerShell (Restart-Service CoworkVMService), or
2. Rebooting the machine.

Re-running the installer (which is what a typical user would try first) does not fix the underlying issue.

Attempted fix

Ran the following from an elevated (Administrator) PowerShell to manually configure recovery actions:

sc.exe failure CoworkVMService reset= 86400 actions= restart/5000/restart/5000/restart/5000

Result:

[SC] OpenService: ошибка: 5:
Отказано в доступе.

(Access is denied, error 5) — even when running PowerShell as Administrator.

By contrast, Restart-Service CoworkVMService (start/stop) succeeds fine as Administrator — only SERVICE_CHANGE_CONFIG appears to be denied, suggesting the service's security descriptor intentionally restricts config changes to a narrower principal than local Administrators (likely by design, for sandbox integrity), but this also seems to prevent the service's own self-configuration of recovery actions at install/start time, which is presumably the intent of that warning log in the first place.

Expected behavior

Either:

• The service should be able to configure its own recovery actions on start (whatever principal it runs as should have SERVICE_CHANGE_CONFIG rights on itself), so it restarts automatically after a crash, or
• If that's intentionally locked down, the installer/updater should set sane recovery actions (e.g. restart on failure) at install time instead of relying on runtime self-configuration.

Environment

• OS: Windows 11 Home 10.0.26200
• Service: CoworkVMService (display name "Claude"), StartType: Automatic