[BUG] Windows: packaged-service DACL grants SERVICE_CHANGE_CONFIG only to NT SERVICE\AppXSvc — CoworkVMService can never arm its own recovery actions (root-cause detail for #85840)

[!NOTE] Update 2026-08-31 — root cause resolved; please triage together with #85840. #85840 (opened 2026-08-11, six independent machines) reports the same defect with better impact evidence — WER 1002 hangs, 7034 service deaths, in-flight Cowork work lost. Treat that as the primary issue; I'd have commented there instead had I found it before filing. What this issue uniquely establishes, in the analysis below and cross-posted to #85840: - The ACE holding SERVICE_CHANGE_CONFIG is NT SERVICE\AppXSvc, not the service's own virtual SID — six reports across both threads pasted that SID and read it the other way, and the proposed sdset workarounds were built on that reading. - The descriptor is Windows' stock DACL for packaged services, proven by a byte-identical sdshow on an unrelated third-party packaged service. Not vendor-set, not machine-specific, not fixable client-side. - System event 7045 fires multiple times per day here, so any local ACL edit is reverted by the next package re-registration. - Therefore fix (c) in #85840 — claude.exe bounds the wait and calls StartService itself — is the one that works: the stock DACL grants SERVICE_START to Authenticated Users, verified unelevated. Original report follows unchanged.

---

CoworkVMService never succeeds in configuring/disarming its SCM recovery actions — "Access is denied" on every start and every stop, since install

Product: Claude Desktop for Windows (Microsoft Store / MSIX)
Version observed: 1.37937.1.0 (Claude_1.37937.1.0_x64__pzs8sxrjxfjjc)
OS: Windows 11 Pro 26200
Service: CoworkVMService (DisplayName "Claude"), StartMode Auto, binary inside the package:
C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

Summary

The service emits this warning on every stop:

Warning: failed to disarm recovery actions for this stop: open service: Access is denied.

…and this one on every start:

Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.

The wording shows the service intends to disarm its SCM recovery actions before a stop, specifically so that a slow stop does not get the service auto-restarted while the MSIX package is being serviced. That protection has never once worked on this machine.

C:\ProgramData\Claude\Logs\cowork-service.log contains 79 occurrences of this warning, the first at 2026-04-23 15:19:49 (the day the app was installed) and the most recent at 2026-08-26 12:40:36. There is no successful case anywhere in four months of logs.

Why this matters

The service's binary lives inside the MSIX package directory and the service runs with StartMode=Auto, so it keeps running after the app is closed. Package servicing therefore has to stop it before it can replace the package folder. The service appears to know this is racy — hence the disarm attempt — but the disarm cannot execute, so whatever safety margin was designed in is absent on every update.

This is a latent defect independent of whether a given update happens to succeed: a designed safeguard is failing silently and permanently, and the only trace is a Warning line in a log file no user will read.

Not a duplicate of #53247

#53247 (and #76357, closed as its duplicate) diagnose an orphaned Silo / Job Object, identified by Microsoft-Windows-AppModel-Runtime/Admin Event 215/208 with HRESULT 0x80070020.

On this machine those failure events do not occur at all — the AppModel-Runtime/Admin log contains only Information events (201/210/211/217, container created / process added / container destroyed) across the entire history, including through a successful in-place update from 1.37937.0.0 to 1.37937.1.0 on 2026-08-26 11:57.

So this report is not the Silo/Job-Object path. It is about the service's own recovery-action handling failing unconditionally, which no existing issue in the tracker appears to cover.

Reproduction

100% reproducible on this machine, and likely on any standard (non-elevated) Store install:

1. Get-Content "$env:ProgramData\Claude\Logs\cowork-service.log" | Select-String "Access is denied"
2. Every service start and stop in the file carries the warning.
3. sc.exe qfailure CoworkVMService confirms the consequence — no failure actions are configured:

SERVICE_NAME: CoworkVMService
        RESET_PERIOD (in seconds)    : 0
        REBOOT_MESSAGE               :
        COMMAND_LINE                 :

Expected

Either the service can manage its own recovery actions (the ACL on the service object grants the needed access to the account it runs as), or the code path is removed and the servicing race is handled another way — but it should not ship a safeguard that fails on 100% of invocations while only logging a warning.

Notes

• Reported symptom that led to this investigation was the familiar intermittent "another program is currently using this file" on update, but I could not capture that failure directly in the logs, so I am deliberately not claiming causation here. The verifiable finding is the unconditional Access is denied.
• Environment paths, account name, and SID have been redacted from the excerpts above.