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:
0x80073CF90x8007001F0x80073D02
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:
- Install Codex Desktop from Microsoft Store.
- Use Codex normally for a while.
- Let Microsoft Store stage a newer Codex package update.
- The update fails during AppX registration.
- 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:
- Close Codex.
- Close stale Codex-related package handles.
- Unload stale
OpenAI.Codex AppX/Helium registry hives.
- Remove the current user's old AppX package registration.
- 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.
What version of the Codex App are you using (From “About Codex” dialog)?
Microsoft Store / MSIX package.
Observed update path:
OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g09PLM9XGG6VKSOpenAI.Codex_2p2nqsd0c76g0After 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?
10.0.19044wingetmsstoreWhat 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.Codexpackage/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:
0x80073CF90x8007001F0x80073D02Representative AppX message:
The staged target manifest existed at the time of failure:
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:
During local diagnostics, stale old-package state remained after closing visible Codex windows. Observed blockers included:
A direct attempt to register the already-staged new package after closing visible app processes still failed with:
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:
OpenAI.CodexAppX/Helium registry hives.After this, the package registered successfully:
AppXDeployment-Server then logged successful registration:
Post-repair checks showed:
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.