CoworkVMService fails to configure its own crash-recovery action (Access is denied), so the desktop app doesn't self-heal after a crash

CoworkVMService fails to configure its own crash-recovery action ("Access is denied"), so the desktop app doesn't self-heal after a crash

Environment

• Windows 11 Home, build 26200.9445
• Claude desktop app version 1.52386.6.0 (MSIX package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc)
• Service: CoworkVMService ("Claude" VM Service), binary cowork-svc.exe, runs as LocalSystem

What happened

The desktop app became unresponsive/closed and would not reopen. Restarting the machine fixed it.

Checking the Application event log around the time of the incident shows CoworkVMService
repeatedly failing to configure its own SCM recovery actions on every start/stop cycle:

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.

This happened 3 times in ~5 minutes (09:32:31, 09:34:06, 09:36:57) before a full reboot resolved
it, suggesting the service (or the app trying to relaunch it) was stuck retrying without success.

Root cause (confirmed via sc.exe sdshow CoworkVMService)

The service's own security descriptor does not grant it SERVICE_CHANGE_CONFIG (DC) against
itself for the security principal its LocalSystem-run process actually gets evaluated under:

D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)

• The first ACE (Authenticated Users) grants CC,LC,SW,RP,WP,DT,LO,CR,RC — no DC.
• The second ACE is scoped to what looks like the service's own per-service SID

(S-1-5-80-...), which does include DC/WD/WO — but that SID is only present in a
process token when the service's SidType is configured to include it (sc.exe qsidtype).
Since the service runs as plain LocalSystem without that SID active in its token, it only
gets evaluated against the first ACE (via Authenticated Users membership) — which lacks the
config-change right it's trying to exercise on itself at startup.

So on every start, cowork-svc.exe calls what's presumably ChangeServiceConfig2 (to set
SERVICE_CONFIG_FAILURE_ACTIONS_FLAG / restart-on-crash) against its own service handle, and
that call is denied by the DACL the installer shipped. ERROR_CONTROL on the service is IGNORE
already, so there's no OS-level safety net either — if the process ever actually crashes, nothing
restarts it until a full reboot, which matches the reported symptom exactly.

Suggested fix

Either:

1. Ship the MSIX installer with a DACL that grants LocalSystem (SY) explicit

SERVICE_CHANGE_CONFIG on CoworkVMService, e.g. add (A;;CCDCLCSWRPWPDTLOCRRC;;;SY), or

1. Set the service's SidType to unrestricted so its own per-service SID (already granted the

right rights in the shipped DACL) is actually present in its token at runtime, or

1. Have cowork-svc.exe open its own service handle with the access it actually has, and skip

trying to configure recovery actions on itself if SERVICE_CHANGE_CONFIG isn't available,
rather than logging a warning and leaving that safety net silently unconfigured every time.

Happy to provide the full event log export if useful.