Claude Desktop (Windows MSIX) auto-update silently fails with 0x80073D02 while app is running

Bug report: Claude Desktop (Windows MSIX) auto-update fails with 0x80073D02 while app is running; no clean recovery without manual MSIX re-registration

Summary

On Windows, Claude Desktop is distributed as a sideloaded, Developer-signed MSIX package. The auto-updater downloads and stages the new version correctly, but registration is deferred because the running app holds file locks, and the update never completes — repeatedly — without manual intervention. The in-app "Update" button and even a reboot do not reliably finalize it.

Environment

• Claude Desktop (MSIX), package family Claude_pzs8sxrjxfjjc, AUMID Claude_pzs8sxrjxfjjc!Claude
• Installed/registered version at time of report: 1.9255.2.0
• Staged-but-unregistered update: 1.9659.1.0 (present at C:\Program Files\WindowsApps\Claude_1.9659.1.0_x64__pzs8sxrjxfjjc\AppxManifest.xml)
• Windows 10/11 x64, non-admin user account
• SignatureKind: Developer (sideloaded, not Microsoft Store)

Root cause (from Windows AppX deployment event log)

The new version stages fine, but Windows defers registration because the old version is still running:

• AppXDeploymentServer/Operational Event 658: "Marking package {Claude_1.9659.1.0...} for deferred registration because {Claude_1.9255.2.0...} is still running."
• On an attempted register: Event 419/404/401, HRESULT 0x80073D02 — "Unable to install because the following apps need to be closed: Claude_1.9255.2.0_x64__pzs8sxrjxfjjc."
• Event 638: "Packages were not updated because affected apps are still running. Running apps: {Claude_pzs8sxrjxfjjc!Claude}."
• File-lock evidence (NOT permissions): Event 5224 Error Code : 0x20 (ERROR_SHARING_VIOLATION) deleting ...\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat / UserClasses.dat; main.log EBUSY: resource busy or locked copying the native-host binary out of the WindowsApps folder.
• Reboot path is also unreliable: Event 503 "The file system entries for package Claude_pzs8sxrjxfjjc could not be cleaned up after reboot."

It is a file-lock / "app still running" problem (0x20 sharing violation), not an ACL/permission denial (which would be 0x5).

Why it recurs / why users may not all report it

A claude.exe from the package family is almost always alive at registration time — including because Claude Code runs as a child process of Claude Desktop, and the Electron app can re-register for automatic restart, so a hard-kill is followed by a respawn within ~2s. The updater therefore never gets a lock-free moment, and "restart to apply" can silently no-op while appearing to succeed (the app reopens on the OLD version).

Reproduction

1. Run Claude Desktop with an update pending (new version staged).
2. Click in-app Update / restart to apply.
3. Observe: app reopens, "update available" prompt clears, but (Get-AppxPackage -Name '*Claude*').Version still reports the OLD version. Event log shows 0x80073D02.

Workaround that DOES work (no reboot)

Run from a context detached from the Claude process tree (e.g., a Scheduled Task), so closing Claude doesn't kill the script:

Add-AppxPackage -DisableDevelopmentMode -Register `
  "C:\Program Files\WindowsApps\Claude_<newver>_x64__pzs8sxrjxfjjc\AppxManifest.xml" `
  -ForceTargetApplicationShutdown -ForceUpdateFromAnyVersion

-ForceTargetApplicationShutdown makes the deployment engine close the running package as part of the operation, eliminating the kill-then-respawn race. Then relaunch shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude and verify the version flipped.

Suggested product fix

Have the updater apply the staged package using the equivalent of -ForceTargetApplicationShutdown (or a true apply-on-quit that guarantees zero package-family processes before registration), rather than relying on deferred registration that the always-running app perpetually blocks. Also surface a real failure to the user instead of silently reopening on the old version.