CoworkVMService cannot configure its own SCM recovery actions; app unlaunchable until reboot (Windows)

Summary

CoworkVMService (the Claude desktop app's Windows service) fails to configure its own SCM recovery actions with ERROR_ACCESS_DENIED (5) on every start. The service therefore has no failure actions at all, so when it crashes it is never auto-restarted and the Claude app cannot be launched until the machine is rebooted.

The service's own log states the consequence:

Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access denied.

This happened to me: the app refused to open and a full power cycle was the only fix.

Environment

• Windows 11 Pro, build 26200
• Package Claude_1.32885.1.0_x64__pzs8sxrjxfjjc
• Service CoworkVMService ("Claude"), cowork-svc.exe, runs as LocalSystem, AUTO_START

Evidence

System log (Service Control Manager, 7034) - the only two occurrences in 7 days:

2026-08-20 00:15:03  The Claude service terminated unexpectedly.
2026-08-20 00:16:51  The Claude service terminated unexpectedly.

Application log (CoworkVMService) - repeats on every service start, present on 13, 14, 16, 19 and 20 August:

failed to configure SCM recovery actions; if the service crashes it will not
restart until the machine reboots: open service: Access denied.

failed to disarm SCM recovery actions for this stop; ... open service: Access denied.

No recovery actions are configured:

> sc.exe qfailure CoworkVMService
SERVICE_NAME: CoworkVMService
        RESET_PERIOD (in seconds)    : 0
        REBOOT_MESSAGE               :
        COMMAND_LINE                 :

Root cause

> sc.exe sdshow CoworkVMService
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)

• Authenticated Users (AU) get CC LC SW RP WP DT LO CR RC - no DC (SERVICE_CHANGE_CONFIG).
• The only principal holding DC is the service SID S-1-5-80-1949724575-....
• There is no ACE for BA (Builtin\Administrators) at all.

So the service runs as LocalSystem but its token does not carry the service SID unless the service is configured with a service SID type (SERVICE_SID_TYPE_UNRESTRICTED); without it, opening its own service for write access is denied - exactly what it logs on every start. And an elevated administrator cannot repair it externally either, because Administrators have no ACE:

> sc.exe failure CoworkVMService reset= 86400 actions= restart/5000/restart/10000/restart/30000
[SC] OpenService FAILED 5:
Access denied.

(run from an elevated console - same result)

Impact

Any crash of CoworkVMService makes the Claude desktop app unlaunchable until the user reboots. There is no user-visible explanation; the app simply refuses to open.

Suggested fixes

Any one of these closes it:

1. Set the service SID type to SERVICE_SID_TYPE_UNRESTRICTED, so the service's token carries the SID its DACL already grants DC to.
2. Have the installer write the failure actions at install time, instead of the service attempting it on every start.
3. Add an ACE granting DC to BA so administrators can repair it externally.

Workaround for affected users

AU does hold RP (start), so a reboot is not required - starting the service by hand is enough and needs no elevation:

sc.exe start CoworkVMService