[BUG] Claude Desktop reinstall fails with 0x80073CFF — orphaned CoworkVMService cannot be removed, blocks AddPackage

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?

An interrupted Cowork-enabled update left an orphaned CoworkVMService Windows service registered. On every subsequent reinstall/repair, the installer detects the service, tries to remove it as a prerequisite, and fails with "Access is denied" — even when running fully elevated. Because the conflicting service can't be cleared, the follow-on AddPackage fails with HRESULT 0x80073CFF, and the app never installs.

The end-user–visible symptom is that Claude Desktop appears uninstalled (no Start-menu entry, empty install folder, Repair unavailable), while Get-AppxPackage -AllUsers *claude* still shows the old versions in a Staged (SYSTEM-only) state that the user cannot register or remove.

This looks like a self-inflicted deadlock: the installer's own service-cleanup step lacks the rights to open CoworkVMService for DELETE, so it can never recover the machine from this state on its own.

What Should Happen?

The installer should either successfully remove/replace the pre-existing CoworkVMService (it is elevated at that point), or degrade gracefully and complete the app install when the service cannot be removed, rather than aborting AddPackage entirely.

Error Messages/Logs

From `ClaudeSetup.log`, elevated attempt:
 

WARNING: CoworkVMService already exists (potential conflict)
...
Is elevated: true
Conflicting service: true
Running in elevated context
...
Removing conflicting CoworkVMService...
WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
Checking for existing Claude MSIX packages...
Removing: Claude_1.15962.1.0_x64__pzs8sxrjxfjjc
Windows rejected data-preserving removal for Claude_1.15962.1.0_x64__pzs8sxrjxfjjc (0x80073CFA, requires developer mode); relying on in-place update
Removing: Claude_1.46388.4.0_x64__pzs8sxrjxfjjc
Windows rejected data-preserving removal for Claude_1.46388.4.0_x64__pzs8sxrjxfjjc (0x80073CFA, requires developer mode); relying on in-place update
Installing MSIX: ...Claude-3233090873.msix
Standard install (not split-account), using AddPackage
Installing via AddPackage (current-user)...
MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CFF

 
(Full log available on request.)

Steps to Reproduce

1. Have Claude Desktop installed and working (a Cowork-enabled build that registers CoworkVMService).
2. Have an auto-update interrupted partway through (leaves a package in Servicing state and CoworkVMService registered but orphaned).
3. Attempt to relaunch → app fails to open / appears gone.
4. Attempt Repair (Settings → Apps → Advanced options) → unavailable/fails.
5. Re-download and run the installer .exe (elevated).
6. Install fails: AddPackage failed with HRESULT 0x80073CFF; dialog reads "Administrator access is required to install Claude with full features. You can try again or install without Cowork."

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.15200

Claude Code Version

Cannot run that command but attempted to install 2.110.0 (build dfb2ba67b0820f5151bf7275ed57996f9d54d34c)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

• Windows edition: Enterprise N (EnterpriseSN)

Environment

• Windows version: 10.0.26100 (Windows 11 24H2)
• Arch: x64
• Host: Windows 11 running as a Parallels VM on macOS
• Claude Desktop version attempted: 2.110.0 (build dfb2ba67b0820f5151bf7275ed57996f9d54d34c)
• Last known-good install: version 1.15200.x, installed cleanly 2026-06-26 (Conflicting service: false at that time)
• Sideloading: enabled. S Mode: off.

Package State Observed

Get-AppxPackage -Name "*Claude*" -AllUsers returns two packages, both Staged to S-1-5-18 (SYSTEM), never registered to the current user, both SignatureKind : Developer:

• Claude_1.15962.1.0_x64__pzs8sxrjxfjjc — Status: Ok
• Claude_1.46388.4.0_x64__pzs8sxrjxfjjc — Status: Servicing ← the interrupted update

Get-AppxPackage *claude* (current user, no -AllUsers) returns nothing, which is why the app looks uninstalled.

What I've Already Tried (all unsuccessful or blocked)

• Settings → Apps → Claude → Repair / Reset — Repair reports it cannot run.
• Add-AppxPackage -DisableDevelopmentMode -Register <AppxManifest.xml> — fails 0x80073D28 ("Administrator privileges required to install packaged service"). Per-user register cannot provision the machine-wide service.
• Re-running the official .exe installer elevated — fails 0x80073CFF (log above).
• sc.exe stop/delete CoworkVMService — Access is denied even elevated.
• Deleted the service registry key HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService and rebooted — sc query/sdshow now return 1060 (service gone).
• Get-AppxPackage -AllUsers *claude* | Remove-AppxPackage -AllUsers — the two staged packages still remain (silent per-item failure; suspected 0x80073CFA developer-mode requirement, matching the installer log).

Suspected Root Cause / Suggested Fixes

1. The installer's service-removal step is under-privileged for the DELETE it needs. It opens CoworkVMService and gets Access Denied despite elevation — suggesting the service's DACL (or protection level) doesn't grant Administrators DELETE/WRITE_DAC. The installer should set an appropriate SD or run the delete in a SYSTEM context before falling through to AddPackage.
2. AddPackage aborts instead of degrading. When the conflicting service can't be removed, the install fails hard rather than completing the app portion. Offering to proceed (as the "install without Cowork" dialog implies) but then still failing is confusing.
3. Developer-signed packages + no Developer Mode = unrecoverable staged state. The data-preserving removal path requires developer mode (0x80073CFA), which is often disabled/locked by Group Policy on managed Enterprise images. A recovery path that doesn't depend on developer mode would help.