[BUG] CoworkVMService DACL omits BA/SY permissions, blocking installer upgrades and recovery (root cause for #25136, #48367, #49655)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Root cause: CoworkVMService is created with a DACL that omits permissions for BA (Built-in Administrators) and SY (LocalSystem), making the service unmodifiable and unremovable by anyone except a specific service SID. This blocks every subsequent Claude Desktop installer from upgrading the package, surfacing as RemovePackage failed with HRESULT 0x80073CFA and forcing users into a manual registry-edit + reboot recovery procedure.

This is the underlying cause of several user-facing symptoms reported in #25136, #48367, #49655, and #46179 — those issues describe Access is denied when the installer tries to remove the conflicting service, but none identify the specific DACL that produces the denial.

Evidence: actual DACL on CoworkVMService

Captured via sc.exe sdshow CoworkVMService from an elevated PowerShell session (verified IsInRole(Administrator) = True):

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

Decoded:

| ACE | Trustee | Granted Rights |
|---|---|---|
| (A;;CCLCSWRPWPDTLOCRRC;;;AU) | Authenticated Users | Read, Start, Stop, Query, Interrogate |
| (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-...) | NT SERVICE\<service-sid> | Full Control (incl. DELETE, WRITE_DAC) |
| S:(AU;FA;...;;;WD) | Everyone | Audit only |

Missing entirely:

• (A;;...DC...;;;BA) — Administrators with DELETE
• (A;;...DC...;;;SY) — LocalSystem with DELETE
• (A;;...WD...;;;BA) — Administrators with WRITE_DAC

Consequence: even an elevated Administrator process cannot execute sc.exe delete, sc.exe sdset, or modify the service in any way that requires WRITE_DAC or DELETE. Only the specific service SID (which the user cannot impersonate) has those rights.

Bug persists across versions

After manual recovery (registry deletion + reboot + reinstall to 1.6259.1.0), the new version recreates the service with the identical defective DACL. Output of sc.exe sdshow CoworkVMService on the freshly-installed 1.6259.1.0 is byte-identical to the output captured on 1.5354.0.0. Every future user who upgrades into a state where CoworkVMService already exists will hit this same blocker.

Workaround (validated, ~10 minutes)

# Open PowerShell as Administrator

# 1. Stop the service (if running)
Stop-Service -Name "CoworkVMService" -Force

# 2. Delete the service registry key directly (bypasses SCM DACL check)
Remove-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Recurse -Force

# 3. REBOOT — required to clear SCM cache
Restart-Computer

# 4. After reboot, force-install the new MSIX
Add-AppxPackage -Path "<path-to-Claude.msix>" -ForceApplicationShutdown -ForceUpdateFromAnyVersion

Remove-Item works because the registry ACL on HKLM\SYSTEM\CurrentControlSet\Services\<service> grants Administrators Full Control by default, independent of the per-service DACL stored in SCM memory.

Note: registry-only methods that target the \Security subkey do not work — the DACL is not persisted there; the Security subkey exists but is empty (ValueCount: 0). The DACL is set at runtime via SetServiceObjectSecurity API by the service binary itself, which is why every reinstall reapplies the same defective ACL.

Suggested Fix

When the installer creates CoworkVMService (or when cowork-svc.exe calls SetServiceObjectSecurity at startup), include BA and SY in the DACL with at minimum DELETE and WRITE_DAC rights. Correct minimal SDDL:

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

This preserves all current functionality (the service-specific SID still has Full Control for self-management) while letting the installer and a privileged Administrator clean up or modify the service when needed.

What Should Happen?

The Claude Desktop installer, when running with Administrator privileges, should be able to remove or modify the existing CoworkVMService to allow upgrading the MSIX package without errors.

The DACL on CoworkVMService should grant BA (Built-in Administrators) and SY (LocalSystem) at minimum DELETE and WRITE_DAC rights, so that future installers and system administrators can manage the service.

Concretely, after running the installer:

• RemovePackage should succeed (no HRESULT 0x80073CFA)
• The new MSIX package should install cleanly over the old one
• The splash screen should not freeze for 2-3 minutes
• The application should launch successfully after installation

Error Messages/Logs

## ClaudeSetup.log (failed upgrade attempt 1.5354.0.0 → 1.6259.1.0, elevated context)


2026/05/07 17:09:31.592312 Is elevated: true
2026/05/07 17:09:31.592312 Sideloading enabled: true
2026/05/07 17:09:31.592312 Conflicting service: true
2026/05/07 17:09:35.620255 Removing conflicting CoworkVMService...
2026/05/07 17:09:35.620845 WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
2026/05/07 17:09:35.620845 Checking for existing Claude MSIX packages...
2026/05/07 17:09:35.639102 Removing: Claude_1.5354.0.0_x64__pzs8sxrjxfjjc
2026/05/07 17:09:35.667117 WARNING: Remove failed for Claude_1.5354.0.0_x64__pzs8sxrjxfjjc: RemovePackage failed with HRESULT 0x80073CFA
2026/05/07 17:09:35.676723 Removing (user): Claude_1.5354.0.0_x64__pzs8sxrjxfjjc
2026/05/07 17:09:35.681908 WARNING: Remove failed for Claude_1.5354.0.0_x64__pzs8sxrjxfjjc: RemovePackage failed with HRESULT 0x80073CFA
2026/05/07 17:09:35.681908 Removing (user): Claude_1.6259.1.0_x64__pzs8sxrjxfjjc
2026/05/07 17:09:35.688298 WARNING: Remove failed for Claude_1.6259.1.0_x64__pzs8sxrjxfjjc: RemovePackage failed with HRESULT 0x80073CFA
2026/05/07 17:09:35.688298 Installing MSIX: C:\Users\<user>\AppData\Local\Temp\Claude-2763899071.msix
2026/05/07 17:09:35.692352 Installing via AddPackage (current-user)...
2026/05/07 17:12:48.089484 Elevated process exited with code 0


The installer reports `exit code 0` but the user-facing experience is a 3-minute frozen splash screen ("Installing Claude...") followed by a non-launching application.

## Confirmation that DACL blocks Administrator

Output from elevated PowerShell (verified `IsInRole(Administrator) = True`):


PS C:\Windows\system32> sc.exe delete CoworkVMService
[SC] OpenService FAILED 5:
Access is denied.

PS C:\Windows\system32> sc.exe sdset CoworkVMService "<corrected SDDL>"
[SC] OpenService FAILED 5:
Access is denied.


## Installer commit

`5095e7dddcba4ca974d351ee397e17d204814f07`

## Affected versions observed

- `Claude_1.5354.0.0_x64__pzs8sxrjxfjjc` (pre-existing)
- `Claude_1.6259.1.0_x64__pzs8sxrjxfjjc` (newly installed — DACL recreated identically)

Steps to Reproduce

1. Install any version of Claude Desktop on Windows 11 Pro (24H2 / 25H2) such that CoworkVMService is created
2. From elevated PowerShell, observe: sc.exe sdshow CoworkVMService shows the DACL above
3. Attempt: sc.exe delete CoworkVMService → Access is denied (even as Admin)
4. Run the latest Claude Desktop installer
5. Observe ClaudeSetup.log: warnings about failed to remove conflicting service and RemovePackage failed with HRESULT 0x80073CFA
6. Splash screen appears frozen at "Installing Claude..." for 2-3 minutes; app fails to launch afterward

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

1.5354.0.0 → 1.6259.1.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Note on issue category

This is a Claude Desktop (Windows MSIX) bug, not Claude Code (CLI). The repo template defaults to Claude Code fields, but this issue is in the same area:cowork / area:desktop / area:installation / platform:windows category as #25136, #48367, #49655, and #46179.

Context

The bug was discovered while diagnosing why Claude Desktop wouldn't launch after a Windows auto-update. Investigation through ClaudeSetup.log and PowerShell sc.exe revealed that the root cause is not the launch itself but the upgrade pipeline: the installer cannot remove the old MSIX package because CoworkVMService (which holds resources from the old package) cannot be removed by anyone — including elevated Administrators — due to its defective DACL.

Confirmation that the user has full Administrator privileges

PS C:\Windows\system32> ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
True

Yet sc.exe delete CoworkVMService and sc.exe sdset CoworkVMService "<corrected SDDL>" both return OpenService FAILED 5: Access is denied. The DACL on the service explicitly excludes BA/SY from DELETE and WRITE_DAC.

Why this is a high-impact bug

• Affects every user who has CoworkVMService already installed and tries to upgrade Claude Desktop
• The installer silently exits with code 0 while the user sees a frozen splash screen — there is no error surfaced to the user
• The recovery procedure requires registry editing + system reboot — not something a non-technical user can do
• The defect is regenerated on every install because the service binary itself sets the bad DACL via SetServiceObjectSecurity at startup, so even a clean reinstall after recovery puts the user back into the same vulnerable state for the next update

Environment details

• Windows 11 Pro, OS Build 22621 (24H2)
• Native arch: x64
• Sideloading enabled, S Mode off, AllowDevelopmentWithoutDevLicense = 1
• Installer commit: 5095e7dddcba4ca974d351ee397e17d204814f07
• Affected packages observed:
• Claude_1.5354.0.0_x64__pzs8sxrjxfjjc
• Claude_1.6259.1.0_x64__pzs8sxrjxfjjc

Diagnosis was performed primarily in PowerShell (elevated)

Although the form asks about terminal/shell, the bug is in the MSIX installer / service registration, not in any CLI tool. PowerShell was the diagnosis tool, not the source of the bug.

Willing to provide more

Happy to provide additional logs, registry exports, or run further diagnostic commands if needed for triage.