[BUG] Windows installer cannot recover when the MSIX install volume is physically removed — orphaned package + stale packaged service block AddPackage permanently

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?

Environment

• Windows 11 Pro, 10.0.26200
• x64
• Claude Setup build f65e386db0db64c8f8b39950e25adb11f5f5e3f3
• Orphaned package: Claude_1.40609.0.0_x64__pzs8sxrjxfjjc
• Stale packaged service binary path references: Claude_1.37937.1.0_x64__pzs8sxrjxfjjc

What happened

Claude Desktop was installed on a secondary drive (E:). That drive suffered a hardware controller failure and is permanently gone. After the drive died, Claude Desktop cannot be reinstalled. The installer fails every time and there is no user-accessible way to clear the state it left behind.

Initial error: AddPackage failed with HRESULT 0x80073D0D

Root cause found (partially fixable)

Windows retained an AppxVolume record pointing at the dead drive:

Name             : \\?\Volume{5c624bf0-dfce-4b25-99b7-bba411729c12}
PackageStorePath : E:\WindowsApps
IsOffline        : True

Remove-AppxVolume cannot remove this. It fails with "Could not resolve mount point. Win32 error: 2" because the cmdlet must resolve the mount point before removing the record — impossible when the volume physically no longer exists. Dismount-AppxVolume also fails silently.

I removed it manually by deleting the registry key:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes\3

After reboot the offline volume was gone and the install error changed from 0x80073D0D to 0x80073CF9 — so the offline volume was a genuine blocker.

Remaining blocker (not fixable by the user)

The package registration will not clear:

PackageFullName        : Claude_1.40609.0.0_x64__pzs8sxrjxfjjc
PackageUserInformation : {S-1-5-18 [S-1-5-18]: Staged}
Status                 : Modified, PackageOffline, NotAvailable, Servicing, NeedsRemediation
InstallLocation        : C:\Program Files\WindowsApps\Claude_1.40609.0.0_x64__pzs8sxrjxfjjc  (Test-Path returns False)

The install folder does not exist. The registration is a pure orphan.

Meanwhile CoworkVMService is pinned to an even older version:

SERVICE_NAME: CoworkVMService
  TYPE             : 210  WIN32_PACKAGED_PROCESS
  START_TYPE       : 2   AUTO_START
  BINARY_PATH_NAME : "C:\Program Files\WindowsApps\Claude_1.37937.1.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
  DEPENDENCIES     : staterepository
  SERVICE_START_NAME : LocalSystem

Because it is a WIN32_PACKAGED_PROCESS, sc.exe delete and Set-Service -StartupType Disabled both return Access Denied even from an elevated admin shell. Windows reserves control of packaged services to the deployment engine. So:

• The service cannot be removed until its package is removed
• The package cannot be removed while the service exists

This is a deadlock with no user-accessible exit.

Installer log (relevant lines, current build)

WARNING: CoworkVMService already exists (potential conflict)
Conflicting service: true
Is elevated: true
Sideloading enabled: true
AllowDevelopmentWithoutDevLicense found with value: 1
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.40609.0.0_x64__pzs8sxrjxfjjc
Windows rejected data-preserving removal for Claude_1.40609.0.0_x64__pzs8sxrjxfjjc (0x80073CFA, requires developer mode); relying on in-place update
Installing MSIX: C:\Users\<user>\AppData\Local\Temp\Claude-2137156091.msix
Standard install (not split-account), using AddPackage
Installing via AddPackage (current-user)...
MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF9
Elevated process exited with code 1
ERROR dialog (with log path): Administrator access is required to install Claude with full features. You can try again or install without Cowork.

Note: the log says the removal requires developer mode, but Developer Mode is enabled (confirmed both in Settings and via AllowDevelopmentWithoutDevLicense=1 in the log itself). The rejection still occurs.

Things I tried that did not help

• Remove-AppxPackage (per-user, -AllUsers, -User S-1-5-18) — all return success, package remains
• Remove-AppxProvisionedPackage -Online
• Enabling Developer Mode (via Settings toggle and registry)
• sfc /scannow — found and repaired corrupt files
• DISM /Online /Cleanup-Image /RestoreHealth — completed successfully
• Store re-register + wsreset -i
• Multiple reboots after each step
• Running installer elevated

Note: after Remove-AppxPackage -User S-1-5-18, the status gained Modified and NeedsRemediation — the removal attempts degrade the record further rather than clearing it.

The "install without Cowork" option is unreachable

The error dialog suggests installing without Cowork, but no such prompt or option is ever presented. The installer fails at AddPackage before reaching any choice, then shows that dialog after the elevated process has already exited. There appears to be no way to actually take that path.

Suggested fixes

1. The installer should detect an orphaned package whose InstallLocation does not exist and force-remove the registration rather than "relying on in-place update"
2. The installer should stop and unregister CoworkVMService through the deployment API (which has the rights) rather than sc.exe, which cannot touch a packaged service
3. Handle offline AppxVolumes — a volume record pointing at a removed drive should be detected and reported to the user, since Remove-AppxVolume structurally cannot clear it
4. Actually expose the "install without Cowork" path when the Cowork service is the blocker

Impact

Any user whose install drive fails is permanently unable to reinstall Claude Desktop on that machine, with no documented recovery path.

What Should Happen?

The installer should complete successfully and install Claude Desktop.

Specifically, when the installer detects an existing package whose InstallLocation does not exist on disk (an orphan left by a removed or failed drive), it should force-remove that registration rather than falling back to "relying on in-place update" — an in-place update over a package whose files are gone cannot succeed.

It should also unregister the conflicting CoworkVMService through the MSIX deployment API, which has the rights to modify a WIN32_PACKAGED_PROCESS service. The current approach fails with Access Denied even when running elevated, because Windows does not permit sc.exe to modify packaged services at any privilege level.

Failing that, the installer should actually present the "install without Cowork" option it references in its error dialog. That message appears after the elevated process has already exited, so the option is never reachable.

Error Messages/Logs

Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF9
Administrator access is required to install Claude with full features. You can try again or install without Cowork.

=== Claude Setup f65e386db0db64c8f8b39950e25adb11f5f5e3f3 started ===
AllowDevelopmentWithoutDevLicense found with value: 1
Windows edition: Professional
WARNING: CoworkVMService already exists (potential conflict)
Windows version: 10.0.26200
Native arch: x64
Elevation type: Full
Is elevated: true
Sideloading enabled: true
S Mode: false
Conflicting service: true
Running in elevated context
Installing MSIX from C:\Users\<user>\AppData\Local\Temp\Claude-2137156091.msix (all-users: false)
Verifying Authenticode signature on C:\Users\<user>\AppData\Local\Temp\Claude-2137156091.msix
WinVerifyTrust: MSIX signature is valid
Signature verified: MSIX signer matches bootstrapper
Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
Checking for running Squirrel Claude processes...
No Squirrel Claude processes found
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.40609.0.0_x64__pzs8sxrjxfjjc
Windows rejected data-preserving removal for Claude_1.40609.0.0_x64__pzs8sxrjxfjjc (0x80073CFA, requires developer mode); relying on in-place update
Installing MSIX: C:\Users\<user>\AppData\Local\Temp\Claude-2137156091.msix
Standard install (not split-account), using AddPackage
Installing via AddPackage (current-user)...
MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF9
Elevated process exited with code 1
Elevation failed: elevated installer exited with code 1

Note: the error was originally 0x80073D0D. It changed to 0x80073CF9 after I manually deleted the orphaned AppxVolume registry key for the dead drive (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes\3, SisPath: E:\WindowsApps), which Remove-AppxVolume could not remove because it cannot resolve a mount point for a drive that no longer exists.

Steps to Reproduce

1. Install Claude Desktop on Windows 11 with the default install volume set to a

secondary drive (Settings > System > Storage > Advanced storage settings >
Where new content is saved > New apps will save to > E:).
The MSIX package installs to E:\WindowsApps.

1. Let the app update at least once, so more than one package version has existed

(in my case 1.37937.1.0 followed by 1.40609.0.0). This leaves CoworkVMService
registered against the older version's binary path.

1. Physically remove or fail the drive. In my case the SSD suffered a controller

failure and no longer enumerates at all — it is not merely unplugged, it is dead.
Any permanent removal of the volume should reproduce this.

1. Reboot Windows.

1. Confirm the orphaned state:

Get-AppxPackage -AllUsers claude | Select PackageFullName, Status
-> Claude_1.40609.0.0_x64__pzs8sxrjxfjjc
Status: PackageOffline, NotAvailable, Servicing
PackageUserInformation: {S-1-5-18 [S-1-5-18]: Staged}

Get-AppxVolume | Select Name, IsOffline
-> the removed drive's volume is still listed with IsOffline: True

1. Download a fresh Claude Setup.exe from claude.ai/download and run it as

Administrator.

1. Installation fails with:

AddPackage failed with HRESULT 0x80073D0D

1. Attempt every documented removal path. All of these return success or complete

without error, and none of them clear the package:

• Get-AppxPackage -AllUsers claude | Remove-AppxPackage -AllUsers
• Remove-AppxPackage -Package "Claude_1.40609.0.0_x64__pzs8sxrjxfjjc" -AllUsers
• Remove-AppxPackage -Package "Claude_1.40609.0.0_x64__pzs8sxrjxfjjc" -User S-1-5-18
• Get-AppxProvisionedPackage -Online | Where {$_.PackageName -like "Claude"} |

Remove-AppxProvisionedPackage -Online

• Enable Developer Mode (Settings toggle and AllowDevelopmentWithoutDevLicense=1)
• sfc /scannow (found and repaired corrupt files)
• DISM /Online /Cleanup-Image /RestoreHealth (completed successfully)
• Store re-register + wsreset -i
• Reboot after each

Note: after the -User S-1-5-18 attempt, Status gains "Modified" and
"NeedsRemediation" — the removal attempts degrade the record rather than
clearing it.

1. Attempt to remove the offline volume:

$v = Get-AppxVolume | Where-Object { $_.IsOffline -eq $true }
Remove-AppxVolume -Volume $v -> fails silently
Dismount-AppxVolume -Volume $v -> fails silently
Remove-AppxVolume -Volume "E:\WindowsApps"
-> "Could not resolve mount point. Win32 error: 2"

Remove-AppxVolume structurally cannot remove a volume record for a drive that
no longer exists, because it must resolve the mount point first.

1. Work around step 9 by deleting the registry key directly:

reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes\3" /f
(identified via: reg query
"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes" /s
— the key with MountPoint E: and SisPath E:\WindowsApps)

1. Reboot. The offline volume is now gone from Get-AppxVolume.

1. Run Claude Setup.exe as Administrator again.

The error CHANGES to: AddPackage failed with HRESULT 0x80073CF9
(confirming the offline volume was a real blocker)

1. Installation still fails. The package registration remains, and

CoworkVMService cannot be removed:

sc.exe qc CoworkVMService
-> TYPE: 210 WIN32_PACKAGED_PROCESS
BINARY_PATH_NAME: "C:\Program Files\WindowsApps\
Claude_1.37937.1.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
DEPENDENCIES: staterepository

sc.exe delete CoworkVMService -> Access is denied (elevated)
Set-Service CoworkVMService -StartupType Disabled -> Access is denied (elevated)

Windows does not permit modifying a WIN32_PACKAGED_PROCESS service by hand at
any privilege level. The service cannot be removed until its package is
removed, and the package cannot be removed while the service exists.

1. Verify the install folder does not exist:

Test-Path "C:\Program Files\WindowsApps\Claude_1.40609.0.0_x64__pzs8sxrjxfjjc"
-> False

The registration points at files that no longer exist, yet the installer's log
says it is "relying on in-place update" over that package.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

Not a regression. Claude Desktop 1.40609.0.0 worked correctly until the drive it was installed on failed. The bug is in the installer's inability to recover from that state, not in a specific version.

Claude Code Version

N/A — this is a Claude Desktop (Windows MSIX installer) issue, not Claude Code. Claude Desktop installer build: f65e386db0db64c8f8b39950e25adb11f5f5e3f3 Orphaned package version: 1.40609.0.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Impact: any user whose Claude Desktop install drive fails is permanently unable to
reinstall on that machine. There is no documented recovery path, and the standard
Windows tooling (Remove-AppxPackage, Remove-AppxVolume, DISM, sfc, Store re-register)
cannot clear the state. Non-technical users would have no way past this at all.

Two findings that may be independently useful:

1. Remove-AppxVolume cannot remove a volume record whose drive no longer exists —

it must resolve the mount point first and fails with Win32 error 2. The only
route I found was deleting the registry key under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes directly.
Doing so genuinely changed the failure mode (0x80073D0D -> 0x80073CF9), so the
installer may want to detect and report offline AppxVolumes explicitly.

1. CoworkVMService is registered as WIN32_PACKAGED_PROCESS with a binary path

pointing at an older package version than the one currently registered
(1.37937.1.0 vs 1.40609.0.0). This suggests the service registration is not
being updated or cleaned up across app updates, which is what creates the
deadlock when the package becomes unremovable.

The dialog text "You can try again or install without Cowork" implies a fallback
path exists, but it is never presented as an actual choice — the installer fails
at AddPackage and the elevated process exits before any option appears. If that
fallback is reachable via a command-line flag, documenting it would give affected
users an immediate workaround.