[BUG] Claude Desktop (Windows/MSIX): update retries against the deleted %TEMP% .msix instead of registering the already-staged package — app becomes unlaunchable AND unrepairable

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?

This is a Claude DESKTOP bug on Windows, not a Claude Code CLI bug. I'm filing it here because there is no separate Desktop issue tracker and Desktop bugs are routinely filed in this repo (#75337, #76357, #63397, #76061, #57221). Please re-route it if this is the wrong venue rather than closing as invalid — several identical reports have been closed that way already.

Summary

Claude Desktop's MSIX auto-update defers registration while the app is running — a known, widely-reported condition. The novel part of this report is what happens next:

The update retry re-invokes the full deployment against the original .msix in %LOCALAPPDATA%\Temp, instead of registering the payload it already staged into C:\Program Files\WindowsApps\.

Windows Disk Cleanup deletes that temp file after 7 days (VolumeCaches\Temporary Files → LastAccess = 7, with the user Temp folder first in its Folder list, driven by the \Microsoft\Windows\DiskCleanup\SilentCleanup task). Once it's gone, every retry fails with 0x80070002 (file not found). The package is then unlaunchable and unrepairable — Windows Settings → Repair fails for the same reason — and the only recovery is a full uninstall and reinstall.

This is an application-side defect. Once staging completes, the source .msix is no longer required; registration proceeds from the staged copy. Nothing in Windows required that file to still exist.

Environment

• Windows 11 Pro 26200 (24H2)
• Claude Desktop Claude_1.24012.9.0_x64__pzs8sxrjxfjjc (MSIX), installed via the official Claude-*.exe bootstrapper
• Occurred twice: 2026-07-27 and 2026-08-03

Timeline

• 2026-07-24 10:36 — update 1.24012.1.0 → 1.24012.9.0 stages successfully, then defers (event 658)
• 2026-07-25 10:10 and 2026-07-26 05:05 — retries fail, 0x80073D02 "apps need to be closed"
• 2026-08-03 08:31, 08:31, 08:37 — temp file now gone (staged 7/24 = 10 days elapsed against a 7-day cleanup window). Three attempts fail with 0x80070002. App will not launch. Repair fails. Uninstall + reinstall was the only fix.

Exact log lines are in the Error Messages/Logs field below.

Why the deferral never resolves

A process from the package family is essentially always running, so the package is never lock-free:

CoworkVMService   Running   StartMode: Auto
PathName: C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

Plus 11 concurrent Claude.exe processes running from inside WindowsApps\Claude_*. CoworkVMService is an Automatic-start Windows service whose binary lives inside the package being updated, so it holds the package open from boot regardless of whether the app window is open. Fully quitting the app does not help — I verified this.

Microsoft's contract for AddPackageOptions.DeferRegistrationWhenPackagesAreInUse states registration is delayed "until the next time the application is activated." Indefinite deferral does not honor that.

Impact

Two forced uninstall/reinstall cycles in eight days. Each reinstall wipes %APPDATA%\Claude, which silently destroys the scheduled-task registry — in my case 37 automation routines whose definitions live elsewhere and survive, so everything looks intact while nothing actually fires. That failure is invisible until deliverables stop arriving.

Related issues

Same deferred-registration signature, different final error:

• #75337 (open)
• #76357 (open — reports it on every update, 20+ times)
• #63397 (closed invalid)
• #76061 (closed invalid)
• #57221 (root-causes the lock to CoworkVMService)

I could not find any existing report of the %TEMP% eviction → 0x80070002 variant described here.

Related platform bug: https://github.com/microsoft/WindowsAppSDK/issues/4827 — deferral combined with DependencyPackageUris re-registers the old version and deletes the staged package. Closed as not planned, so the workaround has to live in the app.

What Should Happen?

The update should apply without bricking the installation. Four concrete fixes, in order of impact:

1. Retry by registering the staged package, not the source file. Add-AppxPackage -MainPackage <PackageFullName> -Register -ForceTargetApplicationShutdown requires no source file and resolves the deferral. This alone eliminates the unrecoverable state.

1. Don't stage from %TEMP%. Download to a vendor-owned path such as %LOCALAPPDATA%\Claude\updates\, which no OS cleanup handler enumerates.

1. Don't defer indefinitely. Use ForceTargetApplicationShutdown, or prompt the user to restart, rather than retrying silently forever against a path that will eventually be cleaned up.

1. Ship CoworkVMService as Manual start, not Automatic. This appears to have been changed upstream after #57221, but this install still has it on Auto, and it holds the package open from boot.

At absolute minimum: a failed update should leave the previous working version registered. The current behavior leaves the package in a state where neither the old nor the new version is launchable and Windows Repair cannot fix it, which turns a routine background update into a mandatory reinstall.

Error Messages/Logs

Source: Microsoft-Windows-AppXDeploymentServer/Operational  (username redacted as <user>)

=== Update stages, then defers because the old version is running ===

2026-07-24 10:36:47  id=658  [Warning]
Marking package {Claude_1.24012.9.0_x64__pzs8sxrjxfjjc} for deferred registration
because {Claude_1.24012.1.0_x64__pzs8sxrjxfjjc} is still running.

=== Retries fail while the app keeps running ===

2026-07-25 10:10:31  id=419  [Error]
error 0x80073D02: Unable to install because the following apps need to be closed
Claude_1.24012.1.0_x64__pzs8sxrjxfjjc.

2026-07-26 05:05:27  id=419  [Error]
error 0x80073D02: Unable to install because the following apps need to be closed
Claude_1.24012.1.0_x64__pzs8sxrjxfjjc.

2026-07-28 09:29:06  id=618  [Error]
error 0x80070005: Unable to update the status for package
Claude_1.24012.9.0_x64__pzs8sxrjxfjjc and user NULL (Clear=0x439F, Set=0x0).

=== 10 days after staging, the temp .msix is gone. THIS is the defect. ===

2026-08-03 08:31:11  id=465  [Error]
error 0x80070002: Opening the package from location Claude-3117766592.msix failed.

2026-08-03 08:31:11  id=497  [Error]
Error 0x80070002: Opening the Msixvc package from location Claude-3117766592.msix failed.

2026-08-03 08:31:11  id=403  [Error]
error 0x80070002: Failure to get staging session for:
file:///C:/Users/<user>/AppData/Local/Temp/Claude-3117766592.msix

2026-08-03 08:31:11  id=404  [Error]
AppX Deployment operation failed for package with error 0x80073CF0.
The specific error text for this failure is: error 0x80070002: Opening the package
from location Claude-3117766592.msix failed.

(that four-event block repeats identically at 08:31:17 and again at 08:37:53)

=== Orphaned package remnants accumulating across versions ===

2026-08-03 08:40:35  id=1230  [Warning]
These hardlinks did not have packages in repository:
\Program Files\WindowsApps\Claude_1.13576.0.0_x64__pzs8sxrjxfjjc\...
\Program Files\WindowsApps\Claude_1.9659.4.0_x64__pzs8sxrjxfjjc\...
(16 orphaned Claude versions listed)

2026-07-27 06:03:56  id=493  [Warning]
There were 9 additional files that failed to be deleted under the folder
\\?\C:\Program Files\WindowsApps\Deleted.   (preceded by repeated "error 0x5" delete failures)

=== The 7-day temp retention that evicts the staged payload ===

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Temporary Files
    LastAccess = 7
    Folder     = C:\Users\<user>\AppData\Local\Temp|C:\WINDOWS\Temp|C:\WINDOWS\Logs|...

Executed by scheduled task \Microsoft\Windows\DiskCleanup\SilentCleanup
(cleanmgr.exe /autocleanstoragesense /d %systemdrive%), which ran 2026-08-03 08:47.

=== Lock-holder that prevents registration from ever completing ===

CoworkVMService   Running   StartMode: Auto
PathName: C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

plus 11 concurrent Claude.exe processes with paths under
C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\Claude.exe

Steps to Reproduce

This reproduces on its own over ~7+ days; it does not need deliberate steps. The sequence:

1. Install Claude Desktop on Windows via the official Claude-*.exe bootstrapper (installs as MSIX into C:\Program Files\WindowsApps\Claude_*_x64__pzs8sxrjxfjjc).
2. Leave the app in normal daily use. Note that CoworkVMService runs as an Automatic-start service whose binary lives inside the package, so a package-family process is alive from boot onward regardless of whether the app window is open.
3. Wait for a background auto-update to download. It stages the new .msix into %LOCALAPPDATA%\Temp and logs AppX event 658 — "Marking package for deferred registration because {old package} is still running."
4. Observe retries failing with 0x80073D02 "Unable to install because the following apps need to be closed" (mine failed on 7/25 and 7/26).
5. Wait more than 7 days from step 3. Windows Disk Cleanup (\Microsoft\Windows\DiskCleanup\SilentCleanup) deletes the staged .msix from %TEMP% per VolumeCaches\Temporary Files → LastAccess = 7.
6. Trigger another registration attempt (reboot, sign-out/in, or let the updater retry). It now fails 0x80070002 — "Opening the package from location Claude-XXXXXXXX.msix failed" — because it is reaching for the deleted source file rather than the payload already staged in WindowsApps.

Result: Claude will not launch. Windows Settings → Advanced options → Repair fails for the same missing-file reason. Uninstall + fresh download is the only recovery.

Faster check without waiting: after step 3, manually delete the staged Claude-*.msix from %LOCALAPPDATA%\Temp, then force a registration retry. If the updater is registering the staged package correctly it should still succeed; if it re-invokes the Add against the source path it will fail 0x80070002.

Confirming the correct code path works: on a wedged install, Add-AppxPackage -MainPackage "Claude_<newver>_x64__pzs8sxrjxfjjc" -Register -ForceTargetApplicationShutdown registers the already-staged payload successfully with no source file present — which is exactly what the updater's retry should be doing.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.24012.1.0 (Desktop) — and pre-Feb-2026 Squirrel builds generally

Claude Code Version

N/A — this is Claude DESKTOP 1.24012.9.0 (MSIX), not Claude Code. Claude Code CLI 2.1.219 also installed.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Note on this form: several required fields above (Claude Code Version, Terminal/Shell, Platform) don't map to a Desktop app bug — I filled them as closely as I could. There is no Desktop-specific template, which is likely part of why identical reports (#63397, #76061) were closed as invalid.

Workaround for anyone hitting this before it's fixed. A logon-triggered scheduled task that registers any staged-but-pending package, running outside the app's process tree so the lock isn't a problem. No admin required:

$pkg = Get-AppxPackage -Name 'Claude'
$regVer = [version]$pkg.Version
$pending = Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList' |
    Where-Object { $_.PSChildName -like "Claude_*_$($pkg.PublisherId)" -and
                   [version](($_.PSChildName -split '_')[1]) -gt $regVer } |
    Select-Object -ExpandProperty PSChildName
foreach ($f in $pending) {
    Add-AppxPackage -MainPackage $f -Register -ForceTargetApplicationShutdown
}

Registering at logon usually means the app isn't running yet, so nothing has to be shut down at all.

Note the HKLM\...\AppModel\StateChange\PackageList detection is an undocumented heuristic — I could not find any supported API that reports "a newer version is staged and pending." Get-AppxPackage -AllUsers with PackageUserInformation[].InstallState is the supported equivalent but requires elevation. A first-class way to query pending registration state would be independently useful.

Second-order damage worth knowing about: the uninstall/reinstall this forces wipes %APPDATA%\Claude, which includes claude-code-sessions\<session>\<workspace>\scheduled-tasks.json — the scheduled-task registry. Task definitions live in ~/.claude/scheduled-tasks/ and survive, so the UI looks completely intact while nothing fires. Anyone relying on scheduled tasks should check list_scheduled_tasks after any reinstall, not assume.