CoworkVMService cannot set its own SCM recovery actions ("Access is denied") -> a crash stays down until reboot

Summary

On Windows, the packaged CoworkVMService (binary cowork-svc.exe, signed "Anthropic, PBC") attempts to configure its own Service Control Manager crash-recovery actions at every startup and is denied by the OS. As a result the service has no failure/recovery actions, and -- in its own logged words -- "a crashed service will stay down until reboot." This contributes to the recurring pattern where a Claude desktop update or a service crash on Windows requires a full reboot to recover.

Environment

• OS: Windows 11 Home 10.0.26200
• Claude (desktop, MSIX/AppX): package Claude_..._pzs8sxrjxfjjc, version 1.52386.0.0
• Service binary: C:\Program Files\WindowsApps\Claude_1.52386.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

What the service logs at startup (verbatim)

2026/09/10 23:05:02 Starting CoworkVMService as Windows service
2026/09/10 23:05:02 Claude VM Service starting...
2026/09/10 23:05:02 [Server] Service ready. Listening on \\.\pipe\cowork-vm-service
2026/09/10 23:05:02 Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.

Corroborating service configuration

sc qc CoworkVMService:

TYPE               : 210  WIN32_PACKAGED_PROCESS
START_TYPE         : 2   AUTO_START
BINARY_PATH_NAME   : "...\Claude_1.52386.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
DEPENDENCIES       : staterepository
SERVICE_START_NAME : LocalSystem

sc qfailure CoworkVMService:

RESET_PERIOD (in seconds) : 0
REBOOT_MESSAGE            :
COMMAND_LINE              :
(no failure actions configured)

Root cause

The service is a packaged service (TYPE 210 WIN32_PACKAGED_PROCESS). Its running identity (LocalSystem, but under package context) lacks SERVICE_CHANGE_CONFIG rights on its own service object, so the ChangeServiceConfig2 call it makes to install SERVICE_CONFIG_FAILURE_ACTIONS fails with Access is denied. This happens on every boot.

Impact

• If cowork-svc.exe crashes, the SCM does not restart it (no recovery actions), so it stays down until the user reboots.
• Related and more visible to users: because the service is version-stamped and holds its install folder, an in-place MSIX update that stages a new version cannot cleanly finalize while the old service is running, and users end up rebooting to recover. Lack of self-recovery compounds this.

Suggested fixes (any one)

1. Declare failure/recovery actions in the package/service definition (installed by the packaging/installer context that has rights), instead of self-configuring at runtime.
2. Set the service's security descriptor to grant SERVICE_CHANGE_CONFIG to the running identity so the runtime call succeeds.
3. If self-restart can't be granted, downgrade the log from a silent warning to a documented, actionable message and provide a supported non-reboot recovery path.

Note

This is distinct from the harmless vmcompute.dll / HcnEnumerateNetworks 0x800706d9 / "HCS not initialized" lines on machines with Virtual Machine Platform disabled -- those are expected and unrelated. The recovery-actions denial occurs regardless of VM Platform state.