A few weeks ago an app on my machine updated itself, quit, and then never came back. The desktop icon did nothing. Nothing showed up under Apps in Task Manager. The only clue was a dialog about apps needing to be closed and an error code: 0x80073D02.
If you've run into this with Claude Desktop, Codex, or any other app that ships as an MSIX package, here's the short version: it's usually not a corrupted install, and reinstalling is often the slowest way out. It's a package swap that didn't finish, and you can usually clear it in a couple of minutes.
An MSIX update is a package swap, not a patch
When one of these apps updates, Windows stages the new files, adds the package, then registers it for your user account.
Staging and adding are file operations. Register is the step that touches your user's state, and it comes with a hard requirement: nothing from the old version can still be running. If something is, the deployment service returns 0x80073D02, which is ERROR_PACKAGES_IN_USE. Microsoft's wording is that the package's resources are "currently in use".
That's why the failure shows up at the very end of an update that looked fine right up to the last step.
The updater quits the app, not everything the app started
The shutdown API Windows gives packaged apps covers the processes belonging to the package. For Claude Desktop, that's the Claude.exe set. It does not cover the helpers the app launched that carry no package identity: a bundled CLI running out of %APPDATA%, node.exe processes from MCP servers, a native messaging host for browser integration, a Python process holding an stdio MCP connection.
One surviving process is enough to pin the package and abort Register.
The annoying part: those helpers don't show under the app's name in Task Manager's Processes tab, because that tab groups by app identity. Switch to the Details tab and sort by name.
Packaged services cause the same thing. Some apps install one, and Claude Desktop's is called CoworkVMService. It's marked AUTO_START, so a repair flow that stops it to free the package gets it back a few seconds later, mid-servicing, and Register fails again. Disabling it isn't an option either: Set-Service -StartupType Disabled returns Access denied, because the service's DACL only grants that right to the OS deployment service. That one is by design.
Finding what's holding the package
Start with the package and where it lives:
Get-AppxPackage -Name "*Claude*" |
Select-Object Name, PackageFullName, InstallLocation, Status
Now the part that matters. Get-Process -Name claude only matches on name, which is why it misses the leftovers. Match on executable path instead:
Get-CimInstance Win32_Process |
Where-Object { $_.ExecutablePath -like "$env:LOCALAPPDATA\Packages\Claude_*" } |
Select-Object ProcessId, Name, ExecutablePath
And check whether a packaged service is in the picture:
Get-Service CoworkVMService | Select-Object Name, Status, StartType
The fix, cheapest attempt first
- Kill the leftovers, then relaunch.
Get-Process claude, cowork-svc -ErrorAction SilentlyContinue | Stop-Process -Force
If name matching misses (it often does), take the PIDs from the path query above and stop those. Several reporters said this alone sorted it, on the same machine, repeatedly.
- Stop the service, kill, re-register the package yourself.
Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
Get-Process claude, cowork-svc -ErrorAction SilentlyContinue | Stop-Process -Force
$pkg = Get-AppxPackage -Name "*Claude*"
Add-AppxPackage -DisableDevelopmentMode -Register "$($pkg.InstallLocation)\AppxManifest.xml"
That's roughly what Settings > Apps > Advanced options > Repair does under the hood, minus the part where AUTO_START brings the service back halfway through. One reporter who hit 0x80073D02 on every repair had this run clean on the first try.
- If the deployment path itself is wedged, reboot and reinstall.
There's a variant where nothing of yours is holding anything: an orphaned per-package container still has a registry hive open, which surfaces as 0x80070020 (ERROR_SHARING_VIOLATION, 32) and the staged build never deploys. A reboot releases it. If the app is available from the vendor's download page, install it fresh after that reboot instead of fighting the in-app updater.
- Last resort: remove and reinstall.
Get-AppxPackage -Name "*Claude*" | Remove-AppxPackage
Remove-AppxPackage only removes the package for the account(s) you target. A package provisioned for all users needs Remove-AppxProvisionedPackage with elevation, which is a different cmdlet.
The other codes in this family
| Code | Message you'll see | What it usually means |
|---|---|---|
| 0x80073D02 | apps need to be closed / resources in use | Something from the old version is still running, often a packaged service |
| 0x80073CF6 | the package could not be registered | Stale or duplicate package state; also shows up when the package sits on a non-C: drive |
| 0x80073CF9 | package installation failed | Registration failed, and the inner error is the useful one |
| 0x80073D05 | error deleting previously existing application data | A half-written install left state behind |
| 0x80073D28 | administrator privileges required | A packaged service tried to register without elevation |
| 0x80070020 (32) | the file is in use by another process | A file or registry hive is held open; a reboot releases it |
You can't run binaries out of WindowsApps
This trips up anyone trying to work around a broken app by calling its bundled CLI directly. Files under C:\Program Files\WindowsApps are owned by the OS (TrustedInstaller) and locked down on purpose, so Access denied from your shell is the expected answer, not a permissions problem you can take ownership of.
If the app needs an external CLI, install it yourself and point the app at it:
npm.cmd install -g @openai/codex@latest
[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", "$env:APPDATA\npm\codex.cmd", "User")
One more drive-related trap, since it caught two reporters in a row: keep the package on C:. If Windows' "Where new content is saved" points at D:, some apps' internal path checks fail and the reinstall dies with 0x80073CF6.
Honest limits
I can be wrong about your specific install, and this doesn't cover every case. Two things I couldn't verify well enough to promise:
- Sometimes Register succeeds and the app still won't launch. That's the OS servicing path stuck rather than a process pinning the package, and a reboot is the next honest step.
- All of this is per-user. Clearing a packaged service for real may need elevation, and vendor dialogs will cheerfully say "administrator access is required" even when you already ran elevated. Trust the error code over the dialog.
So: when an MSIX app dies after updating itself, don't reinstall right away. Find what's still running under the package path and kill by path, not by name.
Sources: the reports I leaned on are in anthropics/claude-code issues 89599, 88962, 89108 and 88500, and openai/codex issues 38843 and 40867. Microsoft's AppX troubleshooting page covers the deployment error codes and the read-only package volume.
Top comments (0)