[BUG] Claude Desktop; Windows MSIX: install fails with 0x80073CF6 after OS upgrade (orphaned package data); every background update then stalls with "Another program is currently using this file" until reboot

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

Two distinct but related failures of the MSIX install/update path on Windows 11 Enterprise build 10.0.26200 (x64, sideloading enabled, no S Mode). Package family: Claude_pzs8sxrjxfjjc.

Failure A — clean (re)install fails with 0x80073CF6 after a Windows feature upgrade.

App 1.14271.0 was installed successfully in June on build 26100. The machine was later upgraded to build 26200. In September, the installer for 1.46388.1 fails at AddPackage with HRESULT 0x80073CF6, identically on retry, both elevated and non-elevated — even though no Claude package is registered anywhere:

PS> Get-AppxPackage *Claude* -AllUsers

# (empty)

PS> Get-ChildItem "HKCU:\...\AppModel\Repository\Packages" | Where-Object Name -like "*Claude*"

# (empty)

The real cause is only visible in the Microsoft-Windows-AppxDeploymentServer/Operational event log (see Error Messages/Logs): inner error 0x80073D05 — "An error occurred while deleting the package's previously existing application data" — caused by 0x800703FA ("registry key that has been marked for deletion"). Root cause: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc remained from the June install; its SystemAppData\Helium\User.dat* hives were left by the OS upgrade in a "marked for deletion" state the installer cannot clear, and LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe was additionally held by a running Chrome (Claude-for-Chrome native messaging host).

Workaround that fixed it: reboot → before Chrome starts, Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force → run installer → install succeeds. Note this likely explains a share of the existing 0x80073CF6 reports on build 26200 (#49104, #48437, #66635), where Get-AppxPackage cleanup advice doesn't help because nothing is registered.

The installer's error dialog is also misleading: it says "Administrator access is required to install Claude with full features" even though the log confirms Elevation type: Full, Is elevated: true — the actual failure is MSIX registration, not elevation.

Failure B — every background auto-update stalls half-way; app unlaunchable until reboot.

After the successful clean install of 1.46388.1.0, a background update to 1.46388.2.0 arrived while the workstation was locked. On unlock, Claude Desktop no longer launches: error dialog titled C:\Program Files\WindowsApps\Claude_1.46388.2.0_... with body "Another program is currently using this file."

Diagnostics at that moment:

• tasklist | findstr /i claude → no Claude processes running.


• CoworkVMService → Status: Running; stopping it did not help.


• Resource Monitor → Associated Handles for Claude_1.46388:

i.e. the package files were already 1.46388.2.0 while the kernel still held the AppContainer Job of 1.46388.1.0 — the updater swapped the package mid-flight without tearing down the previous version's container. Nothing short of a reboot releases that Job. After reboot the system was consistent (single registration, Version 1.46388.2.0, Status Ok, old folder gone).

Days later the exact same failure repeated with the next background update — same dialog, path now Claude_1.46388.4.0_.... So this is systematic: every background update performed while the previous version's container (and/or CoworkVMService) is alive leaves the app unlaunchable until a manual reboot, with no hint to the user that a reboot is what's needed.

Side effect worth documenting: wiping %LOCALAPPDATA%\Packages\<family> (the only workaround for Failure A) permanently orphans existing Cowork sessions — they show "Can't reach your computer. It may be asleep or offline." forever, since the local VM/pairing state lived in that folder.

### What Should Happen?

Install path (Failure A):

When AddPackage fails with 0x80073CF6/0x80073D05, the installer should detect leftover %LOCALAPPDATA%\Packages\ data with no corresponding registration and offer to remove it — or at least name it in the error dialog.
The dialog should surface the inner AppxDeploymentServer error text instead of the bare 0x80073CF6.
The "Administrator access is required" dialog should not be shown when elevation already succeeded.

Update path (Failure B):

Before swapping the package, the updater should ensure the previous version's AppContainer Job is terminated (and CoworkVMService quiesced), or defer the swap until next launch/logon.
If the swap cannot complete, the app should keep launching the old registered version instead of becoming unlaunchable.
On launch failure due to a stale container, show an actionable message ("a pending update requires a restart") instead of the raw file-in-use error.

### Error Messages/Logs

```shell
Installer log (Failure A; username redacted):

=== Claude Setup 2dfd5f2c40e82ccf388f5dc1d3f1ce93a3671b03 started ===
Windows edition: Enterprise
Windows version: 10.0.26200
Native arch: x64
Elevation type: Full
Is elevated: true
Sideloading enabled: true
S Mode: false
Installing MSIX from ...\Claude-2264245466.msix (all-users: false)
WinVerifyTrust: MSIX signature is valid
Signature verified: MSIX signer matches bootstrapper
Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
No Squirrel Claude processes found
Installing via AddPackage (current-user)...
MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
ERROR dialog (with log path): Administrator access is required to install Claude with full features. You can try again or install without Cowork.

Microsoft-Windows-AppxDeploymentServer/Operational (Failure A, same timestamps):

error 0x80073D05: While processing the request, the system failed to register the
windows.stateExtension extension due to the following error: An error occurred while
deleting the package's previously existing application data.

An internal error occurred with error 0x800703FA.
(= ERROR_KEY_DELETED: Illegal operation attempted on a registry key that has been
marked for deletion)

error 0x80073CF6: Cannot register the Claude_pzs8sxrjxfjjc package due to the following
error: Package could not be registered.

AppX Deployment operation failed for package Claude_1.46388.1.0_x64__pzs8sxrjxfjjc with
error 0x80073CF6. The specific error text for this failure is: An internal error occurred
with error 0x80073D05.

Launch failure after background update (Failure B):

Dialog title: C:\Program Files\WindowsApps\Claude_1.46388.4.0_...
Dialog body: Another program is currently using this file.

(Resource Monitor evidence for Failure B is in the table above; screenshots of the dialog and of the \Container_Claude_1.46388.1.0... Job handle available on request. Full ClaudeSetup.log also available.)
```

### Steps to Reproduce

Failure A (install after OS feature upgrade):

Install Claude Desktop (MSIX path) on Windows 11 build 26100; use it (including the Chrome extension's native host).
Upgrade Windows to build 26200. The Claude package registration is lost, but %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc remains, with Helium hives in a marked-for-deletion state.
Run the current Claude Setup.exe (elevated or not).
Download and signature verification succeed; AddPackage fails with 0x80073CF6; AppxDeploymentServer log shows 0x80073D05 / 0x800703FA.
Workaround: reboot, delete %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc before Chrome starts, rerun installer → success.

Failure B (background update):

Install Claude Desktop (MSIX path, with Cowork) on Windows 11 build 26200.
Leave the app installed and the workstation running; lock the screen.
Wait for a background auto-update to arrive.
Unlock and launch Claude Desktop → "Another program is currently using this file" pointing at the new version's WindowsApps path.
Observe in Resource Monitor: svchost.exe (netsvcs) holds a Job object \Container_Claude_... while package files are already the new version; no Claude processes are running; stopping CoworkVMService does not help.
Reboot → app launches normally on the new version.
Wait for the next background update → the same failure repeats (observed on 1.46388.1→2 and again on the update to 1.46388.4).

### Claude Model

None

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

_No response_

### Claude Code Version

Claude Desktop 1.46388.4.0

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Other

### Additional Information

_No response_

The issue names no repository files or tests. Start by tracing the MSIX AddPackage install path and the background updater on Windows 11 build 26200, using the AppxDeploymentServer/Operational log and the reported Resource Monitor handles. Done means orphaned package data and stale containers are handled without an unlaunchable app, and the user receives an actionable error when recovery is required.

Rédigé par le modèle d'indexation à partir du texte de l'issue.