Windows Store Codex repeatedly fails to update because old MSIX package remains locked/in use

What version of the Codex App are you using (From “About Codex” dialog)?

Microsoft Store / MSIX package.

Observed update path:

• Previous installed package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Target package staged by Store/AppX: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
• Store ProductId: 9PLM9XGG6VKS
• Package family: OpenAI.Codex_2p2nqsd0c76g0

After manual repair, the machine is now successfully on OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0.

What subscription do you have?

Not relevant to the Store/AppX update failure.

What platform is your computer?

• OS: Microsoft Windows 10 Enterprise
• Version: 10.0.19044
• Architecture: x64
• Install source: Microsoft Store / winget msstore

What issue are you seeing?

Codex Desktop from Microsoft Store repeatedly fails to update on Windows. The update reaches the AppX/MSIX registration phase, then fails because Windows still considers the old OpenAI.Codex package/application to be in use.

This has happened repeatedly on the same machine, and also on another machine in the same LAN.

Recent AppXDeployment-Server failures included:

• 0x80073CF9
• 0x8007001F
• 0x80073D02

Representative AppX message:

Deployment Register operation failed because OpenAI.Codex_2p2nqsd0c76g0!App needs to be closed.

The staged target manifest existed at the time of failure:

C:\Program Files\WindowsApps\OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0\AppxManifest.xml

But registration was blocked by the old package state.

What steps can reproduce the bug?

This happens during Store/MSIX updates, not during a normal in-app action. The rough pattern is:

1. Install Codex Desktop from Microsoft Store.
2. Use Codex normally for a while.
3. Let Microsoft Store stage a newer Codex package update.
4. The update fails during AppX registration.
5. Closing visible Codex windows is not enough; Windows still reports the old package/app as in use.

During local diagnostics, stale old-package state remained after closing visible Codex windows. Observed blockers included:

SearchApp.exe file handles:
...\Microsoft.Windows.Search_cw5n1h2txyewy\LocalState\AppIconCache\100\OpenAI_Codex_2p2nqsd0c76g0!App

svchost.exe package/container job handle:
\Container_OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0-...

Mounted AppX/Helium registry hives for OpenAI.Codex

A direct attempt to register the already-staged new package after closing visible app processes still failed with:

Add-AppxPackage: 0x80073D02
The package could not be installed because resources it modifies are currently in use.
OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0 needs to be closed.

What is the expected behavior?

Codex should update cleanly through Microsoft Store without requiring a reboot or manual AppX cleanup.

If Codex needs to restart itself for update, it should fully release package/container/AppX state, or provide a robust update flow that handles stale app package locks.

Actual behavior

The app/update flow repeatedly leaves the old package considered "in use", causing Store/AppX registration to fail. The user is forced into repeated manual repair, package unregister/reinstall, or reboot-like cleanup.

Workaround used locally

The update succeeded only after manually quiescing the old package state:

1. Close Codex.
2. Close stale Codex-related package handles.
3. Unload stale OpenAI.Codex AppX/Helium registry hives.
4. Remove the current user's old AppX package registration.
5. Reinstall from Microsoft Store:

winget install --id 9PLM9XGG6VKS --source msstore --accept-source-agreements --accept-package-agreements

After this, the package registered successfully:

OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
Status: Ok

AppXDeployment-Server then logged successful registration:

Deployment Register operation with target volume C: on Package OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0 from: (AppxManifest.xml) finished successfully.

Post-repair checks showed:

No mounted OpenAI.Codex hives found.
No stale Codex-related handles found.

Additional information

This makes every Store update fragile for users who keep Codex running for long coding sessions. A reboot may implicitly clear the same package/container state, but requiring a reboot for frequent app updates is a poor update experience.

The failure appears to be in the Windows Store/MSIX update lifecycle around releasing the old package identity, rather than in normal application runtime behavior after the package is successfully installed.