[Windows][AppX] In-family MSIX update permanently fails with 0x80070002 (Resolved state) once the previously-installed package's files are gone from a non-system-volume junction — no version bump fixes it

Environment

• Windows 11, build 26200.9445 (Polish locale)
• Package: OpenAI.Codex (displayed as "ChatGPT" desktop app)
• PackageFamilyName: OpenAI.Codex_2p2nqsd0c76g0
• Publisher: CN=50BDFD77-8903-4850-9FFE-6E8522F64D5B
• Currently registered (broken) version: 26.825.6671.0, x64
• Tested update targets: 26.903.8094.0 and 26.915.4065.0 — both fail identically
• "New apps will save to" was set to a secondary NTFS volume (D:), a standard Windows setting for Store/MSIX apps

Summary

Once the on-disk contents of the currently-installed package version are deleted from disk (in our case, D:\WindowsApps\OpenAI.Codex_26.825.6671.0_x64__2p2nqsd0c76g0 was removed by an unrelated third-party tool, while the AppX registration/junction under C:\Program Files\WindowsApps\... was left intact and pointing at the now-missing folder), every subsequent install/update attempt for that PackageFamilyName fails, regardless of which newer MSIX version is used. This appears to affect Windows' AppX deployment engine generally, not something specific to this app, but we can only reproduce it with OpenAI.Codex since that's the affected install.

Root cause (confirmed via direct inspection, not speculation)

Add-AppxPackage for a newer version of the same PackageFamilyName fails at the Resolved state handler with 0x80070002 (file not found), before anything is written to the deployment state repository. We confirmed via a read-only copy of C:\ProgramData\Microsoft\Windows\AppRepository\StateRepository-Machine.srd (SQLite) that:

• There is exactly one Package row for this family (the old, broken 26.825.6671.0), with a clean PackageLocation row pointing at the dead junction.
• Zero rows in DeploymentHistory and WorkInProgress for this package — i.e., the failure happens before any transaction is recorded, so it is not a stuck/orphaned transaction or a database inconsistency.

This strongly suggests the deployment engine needs to physically read files from the currently registered package's install location (via the C:\Program Files\WindowsApps\... junction, which now points to a deleted folder on the non-system volume) in order to process an in-place version update within the same PackageFamilyName — and has no fallback path when that location is inaccessible (not even "treat as fresh install").

Steps to reproduce

1. Install the Store/MSIX version of ChatGPT (OpenAI.Codex) with apps configured to install to a non-system volume (Settings → Apps → Storage → "New apps will save to" set to a secondary drive).
2. Delete the contents of that drive's WindowsApps\OpenAI.Codex_<version>_x64__2p2nqsd0c76g0 folder directly (simulating what happened to us via an unrelated third-party "optimizer" tool), leaving the junction in C:\Program Files\WindowsApps and the AppX registration intact.
3. Attempt to update/reinstall via any MSIX from https://persistent.oaistatic.com/codex-app-prod/ChatGPT-x64.msix, with or without -ForceUpdateFromAnyVersion, targeting either volume.
4. Observe failure regardless of MSIX version.

Evidence

Deployment log (Get-AppPackageLog) for an attempt with the current MSIX build (26.915.4065.0), forcing the system volume:

Preferred package version for package family is changing. Current preferred version is: OpenAI.Codex_26.825.6671.0_x64__2p2nqsd0c76g0. New preferred version will be: OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0.
Error 0x80070002: Failure in the Resolved state handler.
Deployment Add operation with target volume C: on Package OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0 ... failed with error 0x80070002.
AppX Deployment operation failed for package OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0 with error 0x80073CF9.
Performance summary ...: Failed to reach state Resolved

Identical failure signature (same HRESULTs, same "Resolved" stage) was already reproduced on 2026-09-14/15 with an older MSIX build (26.903.8094.0). Two MSIX builds ~12 release trains apart, same exact failure — ruling out a version-specific packaging bug on OpenAI's side and pointing at either the underlying Windows AppX engine, or at how the app's PackageFamilyName/update path was set up.

We also verified via Get-AppxProvisionedPackage, registry (AppxAllUserStore\Applications), and 14 separate hypotheses (service state, ACLs, manifest presence, volume registration, DISM/SFC repair, SYSTEM-context deployment, etc.) that this is not caused by permissions, a corrupted Windows image, or a stuck AppX volume registration. Full internal diagnostic log available on request.

Impact

Once this state occurs, there is no supported recovery path for the affected user other than a full Windows reset (losing all other Store apps) — Remove-AppxPackage also fails (0x80073CFA, DeStage failure) on the same dead junction, so the broken registration cannot even be cleanly removed. We're currently using ChatGPT Classic (Store ID 9NT1R1C2HH7J) as a workaround, which is unaffected because it has a different PackageFamilyName.

Ask

• Is there an official/supported way to force AppX to treat an in-family update as a clean install when the previous install location is inaccessible, without hand-editing StateRepository-*.srd?
• Could the app's deployment/update path be made resilient to this (e.g., detect that the previous install location is unreachable and fall back to a full reinstall instead of a delta/in-place update)?
• Any chance of a supported Remove-AppxPackage-equivalent for this exact scenario (dead junction + non-removable registration)?

Related existing threads for context:

• https://github.com/openai/codex/issues/13993
• https://github.com/openai/codex/issues/21538
• https://community.openai.com/t/official-codex-app-installation-command-resolves-to-an-unrelated-third-party-app/1386469

No Codex source file or test is identified in the report. Start by reviewing the Add-AppxPackage and Remove-AppxPackage behavior, the Get-AppPackageLog output, and the read-only StateRepository-Machine.srd inspection; done would require an agreed, supported recovery or update behavior for the dead junction state.