CoworkVMService fails to configure/disarm SCM recovery actions ("Access is denied"), can lock app files on update and require a full reboot

Environment

• OS: Windows 11 Pro, build 10.0.26200
• Claude desktop app: MSIX/Store install, package Claude_1.46388.2.0_x64__pzs8sxrjxfjjc
• Relevant component: CoworkVMService Windows service (display name "Claude"), bundled with the app for the Cowork/cloud-VM feature

Description

Periodically the Claude desktop app fails to launch, with Windows showing an "another program is using this app" style error. The only way I've found to recover is a full system reboot — killing the visible claude.exe processes from Task Manager doesn't fix it.

Looking at Event Viewer (Application log, provider CoworkVMService), every single start/stop cycle of the service logs two warnings:

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 is consistent (100% reproduction rate on every service restart I checked) and timestamps align with app relaunch/update cycles.

Suspected root cause

The service appears to lack the rights to call ChangeServiceConfig2 on its own SCM service object (both to arm recovery actions on start, and to disarm them before a controlled stop). Because it can't disarm its own auto-restart policy before stopping, if a stop takes too long during app auto-update/package servicing, SCM may auto-restart the service while the MSIX package is being serviced, re-locking files the updater needs to replace. That produces the "in use" error and blocks the app from launching until a reboot force-terminates everything holding the lock.

Impact

App becomes completely unusable until the machine is rebooted. This has happened multiple times.

Workaround found

Manually stopping CoworkVMService (Stop-Service CoworkVMService -Force, requires admin) and killing any leftover claude.exe processes releases the lock and lets the app relaunch normally — no reboot needed. Restarting the service afterward (Start-Service CoworkVMService) restores Cowork functionality.

Suggested fix

• Grant the service's SID/account proper ACL rights on its own SCM service object so ChangeServiceConfig2 succeeds, or
• Perform recovery-action configuration from an elevated installer/parent process instead of from within the packaged service itself, and
• Ensure the service stop path doesn't leave the app's package files locked if a controlled stop overruns during update servicing.