[BUG] Windows MSIX: Repair and Reset can never succeed — the installer registers the package from `%TEMP%\Claude-*.msix`, which is later deleted (0x80073CF0 / 0x80070002)

Summary

Windows' built-in Repair and Reset for the Claude desktop app are permanently broken by a
packaging choice, not by a transient fault.

The installer registers the MSIX package from a temporary file in %LOCALAPPDATA%\Temp\. Windows
records that path as the package source. Both Repair and Reset re-run an Add deployment
against that recorded source path. Once %TEMP% is cleaned — which Windows does routinely — the
file is gone and both operations fail forever with:

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-3192053764.msix failed.

0x80070002 = ERROR_FILE_NOT_FOUND.

The UI reports this as "We couldn't repair this app. Try again in a bit." That message is
misleading: the failure is deterministic and permanent. Waiting cannot help.

This matters because Windows itself directs users here. When the package needs remediation, Windows
displays:

You'll need to go to advanced options for Claude and select Repair. If you're still having issues with it, reinstall this app or contact your administrator.

Following that instruction leads to two guaranteed failures, after which the only remaining option
is uninstall + reinstall — which has its own destructive consequence (see the linked issue below).

Environment

| Item | Value |
|---|---|
| App version | 1.34493.1.0 |
| Package full name | Claude_1.34493.1.0_x64__pzs8sxrjxfjjc |
| Install type | MSIX, SignatureKind: Developer |
| Install source | https://claude.ai/download |
| OS | Windows 11 Pro 10.0.26200, x64 |

Steps to reproduce

1. Install Claude Desktop from https://claude.ai/download.
2. Wait for %TEMP% to be cleaned (Storage Sense, Disk Cleanup, a reboot cycle, or manual

deletion). Confirm no Claude*.msix remains in %LOCALAPPDATA%\Temp.

1. Go to Settings → Apps → Claude → Advanced options.
2. Click Repair → fails.
3. Click Reset → fails.

Both fail regardless of the app's actual state.

Evidence

From Microsoft-Windows-AppXDeploymentServer/Operational:

Original install — note the source path:

02:04:12  603  Started deployment Add operation on a package with main parameter
               Claude-3192053764.msix
02:04:12  854  Successfully added the following uri(s) to be processed:
               file:///C:/Users/<user>/AppData/Local/Temp/Claude-3192053764.msix
02:04:17  400  Deployment Add operation ... finished successfully.

Repair attempts, ~15 hours later:

16:52:40  603  Started deployment RepairPackageOperation
16:52:40  603  Started deployment Add operation
16:52:41  404  ERROR  AppX Deployment operation failed with error 0x80073CF0.
                      error 0x80070002: Opening the package from location
                      Claude-3192053764.msix failed.
16:52:44  603  Started deployment RepairPackageOperation   (retry)
16:52:44  404  ERROR  ... same 0x80073CF0

Reset attempt:

16:53:01  603  Started deployment ResetPackageOperation
16:53:01  603  Started deployment Add operation
16:53:01  404  ERROR  ... same 0x80073CF0
16:53:02  400  OK: Remove          <-- destructive sub-operation succeeded
16:53:02  400  OK: StageUserData
16:53:03  400  OK: Register

Confirmed on disk: %LOCALAPPDATA%\Temp\Claude-3192053764.msix does not exist, and no Claude*.msix
remains anywhere in %TEMP%.

Secondary defect: Reset reports failure after already destroying data

As the trace above shows, ResetPackageOperation reported failure to the user, but its Remove
sub-operation had already succeeded. The user sees "We couldn't reset this app" while the app
data has in fact been wiped. This is the worst possible combination: an error message that implies
nothing happened, after something irreversible happened.

Context: the underlying problem had already fixed itself

In my case the package's ACLs were damaged across a sleep/wake cycle. Windows detected this and
showed the "select Repair" prompt. But 18 seconds after wake, an automatic
RegisterByPackageFullName had already resolved it:

16:50:28  649  Deployment Register operation ... Trying to repair ACLs for
               \\?\C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
16:50:28  649  Deployment Register operation ... ACLs repaired successfully
16:51:02  400  OK: Register

The package was already healthy. Following Windows' on-screen instruction to run Repair — and then
Reset, and then reinstall — is what caused the actual damage.

Expected behaviour

1. Retain a durable copy of the .msix, or register the package from a stable location outside

%TEMP%, so Repair and Reset keep working for the life of the installation.

1. Do not report "Try again in a bit" for a deterministic, permanent failure.
2. Reset must not perform its destructive Remove before it has confirmed it can complete.

Related

• #88692 — the destructive consequence of having no working Repair/Reset: the forced reinstall regenerates the device identity and permanently orphans existing Claude Code sessions
• #88068 — reports Repair/Reset failing on Windows, but with different error codes

(0x80073CF6 / 0x80073CFA) and no root cause identified

• #88138 — package transitioning to Modified, NeedsRemediation
• #87314 — ACL corruption in the package directory

I believe the %TEMP% source-path root cause above has not been reported before, and it is a
straightforward fix.