Skip to content

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

Closed as not planned
Closed as not planned
[BUG] CoworkVMService DACL omits BA/SY permissions, blocking installer upgrades and recovery (root cause for #25136, #48367, #49655)#57035
Labels
area:coworkarea:desktoparea:installationbugSomething isn't workingplatform:windowsIssue specifically occurs on WindowsstaleIssue is inactive

Description

@neanicu
neanicu
opened on May 7, 2026

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • 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.

Activity

  1. neanicu
    added
    bugSomething isn't working
    on May 7, 2026
  2. github-actions
    added
    platform:windowsIssue specifically occurs on Windows
    area:cowork
    area:desktop
    area:installation
    on May 7, 2026

  3. github-actions commented on May 7, 2026

    @github-actions
    github-actionsbot
    on May 7, 2026 – with GitHub Actions

    Found 3 possible duplicate issues:

    1. [BUG] Cowork tab not showing on Windows 11 Pro x64 — "yukonSilver" marked as unsupported + CoworkVMService cannot be removed #25136
    2. [BUG] Claude Desktop crashes immediately on startup after recent update — Windows 10, no logs generated #48367
    3. [BUG] Claude Desktop update fails with 0x80073CF6 when CoworkVMService is running (Windows) #49655

    This issue will be automatically closed as a duplicate in 3 days.

    • If your issue is a duplicate, please close it and 👍 the existing issue instead
    • To prevent auto-closure, add a comment or 👎 this comment

    🤖 Generated with Claude Code

  4. neanicu commented on May 7, 2026

    @neanicu
    neanicu
    on May 7, 2026
    Author

    Not a duplicate — those issues are referenced as related symptoms, not as the same report.

    The referenced issues describe the user-facing symptoms of this bug:

    This issue identifies the root cause that connects all of them: the DACL on CoworkVMService is constructed without BA (Built-in Administrators) or SY (LocalSystem) entries, so neither the installer nor any elevated user can DELETE or WRITE_DAC the service. I included the actual SDDL string, decoded ACE-by-ACE, and a concrete SDDL fix.

    Closing this as a duplicate of any of those would lose the only report that actually pinpoints what to change in the code (the call to SetServiceObjectSecurity in cowork-svc.exe, or wherever the service descriptor is constructed at install time).

    Happy to merge into one of the existing issues if a maintainer prefers — but the technical content here is not in any of them.

    🤖 Report drafting assisted by Claude

  5. robjarawan commented on May 20, 2026

    @robjarawan
    robjarawan
    on May 20, 2026

    Cross-linking with #49655: the local repro there matches this DACL/root-cause analysis. In an elevated admin shell, Stop-Service CoworkVMService -Force succeeded, but sc.exe config CoworkVMService start= disabled failed with OpenService FAILED 5: Access is denied.

    That lines up with the service ACL issue described here. The practical update workaround was to stop CoworkVMService, then terminate all running Claude package processes from C:\Program Files\WindowsApps\Claude_* before retrying the update. Details/workaround: #49655 (comment)

  6. neanicu commented on May 21, 2026

    @neanicu
    neanicu
    on May 21, 2026
    Author

    Update from the original reporter: after several subsequent Claude Desktop updates, the launch/upgrade failure no longer reproduces on my system, so the user-facing symptom appears resolved in day-to-day use.

    However, the root cause is still present. sc.exe sdshow CoworkVMService on the current version returns the same defective DACL I originally reported:

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

    There is still no ACE for Built-in Administrators (BA) or Local System (SY). The only principals are Authenticated Users (AU) with a limited right set, and the service's own virtual SID with full control.

    sc.exe query CoworkVMService confirms the service is still present and running, with TYPE: WIN32_PACKAGED_PROCESS. Since it ships as part of the MSIX package, the DACL is applied by the packaging runtime on every install (via SetServiceObjectSecurity), which is why it gets recreated identically each time and can't be durably corrected from the outside. This needs to be fixed at the source.

    This lines up exactly with @robjarawan's repro: AU is granted SERVICE_STOP (WP), so Stop-Service succeeds, but neither AU nor BA is granted SERVICE_CHANGE_CONFIG (DC) or WRITE_DAC (WD), so sc.exe config ... start= disabled fails with OpenService FAILED 5 (Access is denied).

    So the symptom appears to have been masked by changes in the update flow rather than fixed at the source. Since the service is still created with a DACL that locks out Administrators and SYSTEM, the failure can resurface on any future update path that needs to reconfigure or remove the service. I'd suggest keeping this open until the DACL includes BA and SY with at least DELETE and WRITE_DAC.

    Thanks @robjarawan for the independent confirmation.

    Analysis and write-up co-authored with Claude (Anthropic).

  7. ngu009 commented on May 29, 2026

    @ngu009
    ngu009
    on May 29, 2026

    Affected here too. Paying Max plan user on Windows 11 Pro.

    Installer symptoms match this issue exactly:

    • HRESULT 0x80073CFF (AddPackage) chained with 0x80073CFA (RemovePackage)
    • Cannot remove stale Claude_1.1.3189.0 package
    • CoworkVMService "Access is denied" even when elevated

    BUT I also have a SECONDARY runtime issue that may be separate:

    Could these be related, or are they separate bugs that both happen to affect the same users?

    My closed issue with full logs (ClaudeSetup.log + cowork-service.log): #63439

  8. github-actions
    added
    staleIssue is inactive
    on Jun 16, 2026

  9. github-actions commented on Jul 1, 2026

    @github-actions
    github-actionsbot
    on Jul 1, 2026 – with GitHub Actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  10. github-actions
    closed this as not plannedon Jul 1, 2026

  11. github-actions commented on Sep 2, 2026

    @github-actions
    github-actionsbot
    on Sep 2, 2026 – with GitHub Actions

    This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

  12. github-actions
    locked as resolved and limited conversation to collaborators on Sep 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:coworkarea:desktoparea:installationbugSomething isn't workingplatform:windowsIssue specifically occurs on WindowsstaleIssue is inactive

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions