›_ Codex Issues
Codex Issues / #25770

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

Open 💬 2 comments Opened Jun 2, 2026 by zyzhen

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.

View original on GitHub ↗

2 Comments

zyzhen · 2 months ago

Additional repeated repro data from the same machine.

This is still happening on later Microsoft Store/MSIX updates. The pattern remains the same: Store successfully stages the new package, then AppX Register fails because Windows still reports OpenAI.Codex_2p2nqsd0c76g0!App as running.

Observed update failures after the original report:

2026-06-03 17:25 local time
OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0 -> OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
Register failed: 0x80073CF9 / 0x8007001F
Reason text: needs to close OpenAI.Codex_2p2nqsd0c76g0!App
Blockers observed: svchost.exe package container job handle, SearchApp.exe AppIconCache handles, mounted AppX/Helium hives

2026-06-05 11:02 local time
OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0 -> OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0
Register failed: 0x80073CF9 / 0x8007001F
Reason text: needs to close OpenAI.Codex_2p2nqsd0c76g0!App
Blockers observed: svchost.exe package container job handle, SearchApp.exe AppIconCache handles, mounted AppX/Helium hives

2026-06-16 09:55 local time
OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0 -> OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0
Register failed: 0x80073CF9 / 0x8007001F
Reason text: needs to close OpenAI.Codex_2p2nqsd0c76g0!App
Blockers observed: svchost.exe package container job handle, mounted AppX/Helium hives

2026-06-17 09:17 local time
OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0 -> OpenAI.Codex_26.611.7849.0_x64__2p2nqsd0c76g0
Register failed: 0x80070005
Reason text: needs to close OpenAI.Codex_2p2nqsd0c76g0!App
Blockers observed: SearchApp.exe AppIconCache handles

2026-06-17 14:55 local time
OpenAI.Codex_26.611.7849.0_x64__2p2nqsd0c76g0 -> OpenAI.Codex_26.611.8273.0_x64__2p2nqsd0c76g0
Register failed: 0x80073CF9 / 0x8007001F
Reason text: needs to close OpenAI.Codex_2p2nqsd0c76g0!App
Blockers observed: svchost.exe package container job handle, SearchApp.exe AppIconCache handles, mounted AppX/Helium hives

Representative AppX event shape on each failure:

Deployment Register operation with target volume C: on Package OpenAI.Codex_<new version>_x64__2p2nqsd0c76g0 from: (AppxManifest.xml) failed with error 0x8007001F / 0x80070005.
Packages were not updated because affected apps are still running.
Running apps: {OpenAI.Codex_2p2nqsd0c76g0!App}

The reliable manual repair has been one of these, depending on how stuck the package state is:

  1. Close stale Codex-related handles (SearchApp.exe AppIconCache handles and/or the svchost.exe package container job handle).
  2. Unload stale OpenAI.Codex AppX/Helium hives when present.
  3. Retry Add-AppxPackage -Register against the already staged AppxManifest.xml.
  4. If AppX still claims the old app is running even with no handles/hives left, remove the current user's old AppX package registration and reinstall from Store:
winget install --id 9PLM9XGG6VKS --source msstore --accept-source-agreements --accept-package-agreements

The latest successful repair ended at:

OpenAI.Codex_26.611.8273.0_x64__2p2nqsd0c76g0
Status: Ok
Deployment Register operation ... finished successfully at 2026-06-17 15:03 local time
No mounted OpenAI.Codex hives found
No stale Codex-related handles found

This now appears to reproduce on nearly every Store update on this machine, so it looks like a deterministic Windows Store/MSIX update lifecycle issue around releasing the old package identity, not a one-off corrupted install.

tolga-guldutuna · 13 days ago

Additional independent reproduction and a controlled success comparison from a different Windows machine.

Environment

  • Windows 11 Enterprise 24H2, build 26100, x64
  • Microsoft Store package family: OpenAI.Codex_2p2nqsd0c76g0
  • Affected update: 26.810.4967.0 -> 26.810.6296.0
  • Co-installed legacy app: OpenAI.ChatGPT-Desktop_1.2026.190.0_x64__2p2nqsd0c76g0

Historical failure evidence

On 2026-08-14, AppX began a Register operation for OpenAI.Codex while package-owned processes were still running. About four seconds later it failed with:

0x80073D02
Unable to install because the following apps need to be closed:
OpenAI.Codex_2p2nqsd0c76g0

Two Application Hang event 1002 records for ChatGPT.exe followed in the same incident window. Later repair/remove attempts produced 0x80070490 (package repository / element not found) and 0x80073CFA de-stage/remove failures. The user-facing recovery cycle had repeatedly become repair/reset/reinstall before the app would launch again.

The machine also had ChatGPT Classic installed, but package identity inspection rules out a visible-name or Task Manager collision:

New ChatGPT/Codex:
  OpenAI.Codex_2p2nqsd0c76g0!App

ChatGPT Classic:
  OpenAI.ChatGPT-Desktop_2p2nqsd0c76g0!ChatGPT

They have different package families, AUMIDs, install roots, executables, and protocols. Classic remained Status: Ok. A Beta package had also been installed and shared the codex: protocol with Stable; it was removed before the controlled reproduction below.

Controlled successful update comparison

On 2026-08-15, the in-app Update action was run while an independent observer recorded package/process state. The observer did not force-close any residual process.

Timeline:

09:58:11  AppX Stage for OpenAI.Codex_26.810.6296.0 starts
09:58:12  Event 400: Deployment Stage finished successfully
09:58:13  Original Electron main process exits naturally
09:58:13  RegisterByPackageFamilyName starts with:
          ForceTargetApplicationShutdownOption,
          RegisterHighestVersion,
          FailIfNeedsRemediation
09:58:14  Event 400: Deployment Register finished successfully
09:58:14  Old 26.810.4967.0 package folder moved to WindowsApps\Deleted, Result 0x0
09:59:50  Next desktop-app log session starts on 26.810.6296.0

Post-update evidence:

  • Registered version advanced to 26.810.6296.0
  • Package status Ok
  • Store signature, package family, and AUMID valid
  • Old package process count was zero
  • Old versioned install root was removed
  • No Codex-related AppX error event
  • No ChatGPT Application Hang event
  • ChatGPT Classic remained running and usable throughout
  • Both distinct AUMIDs now expose their own live windows

This comparison supports the theory that the critical boundary is fully quiescing the old OpenAI.Codex process tree before/during Register, not the coexistence of ChatGPT Classic.

Store catalog / manifest mismatch observed after success

The new app log then recorded:

buildVersion=26.810.6296.0
manifestBuildVersion=26.810.7004.0
canSilentlyDownload=true
completed=false
hasUpdate=false
overallState=NoUpdates

So the OpenAI manifest was already ahead of the version the Microsoft Store would offer. This did not crash the new build, but it makes updater state and user messaging ambiguous.

Requested updater behavior

  1. Before Register, deterministically stop and await all app-owned Electron/backend descendants, including tray-resident processes.
  2. Make post-update relaunch deterministic or show a clear notification if a manual relaunch is required.
  3. Treat “manifest is newer but Store says NoUpdates” as a normal staged-rollout state, without presenting an unusable update action.
  4. Preserve the prior usable registration or provide a supported recovery path instead of forcing users into repair/reset/reinstall loops.
  5. Add telemetry/logging around the transition from Store download/Stage to process shutdown and user Register.

Privacy: usernames, hostnames, SIDs, project names, conversation contents, session IDs, and full user-profile paths were intentionally omitted.