›_ Codex Issues
Codex Issues / #24047

Windows Desktop update installs but Codex does not relaunch afterward

Open 💬 7 comments Opened May 22, 2026 by claell
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Codex Desktop on Windows, Microsoft Store/AppX package after the update:

  • OpenAI.Codex_26.519.3891.0_x64__2p2nqsd0c76g0

The update appears to have replaced:

  • OpenAI.Codex_26.519.2736.0_x64__2p2nqsd0c76g0

What subscription do you have?

Unknown / not relevant to the updater behavior.

What platform is your computer?

Windows 11 Education, version 10.0.26200, build 26200, 64-bit.

What issue are you seeing?

When I manually trigger a Codex Desktop update from the in-app update affordance in the top-left corner, the UI changes to an "installing" state. Normally, after installation completes, Codex should restart/relaunch automatically.

For the current update, Codex did not relaunch after reaching the installing state. I waited and checked Task Manager thoroughly for Codex-related processes, but did not find an active Codex process during that period. I had to start Codex manually again.

After manually reopening Codex, the installed package version is 26.519.3891.0, so the package installation itself appears to have succeeded. The failure seems to be in the post-update relaunch / user-visible recovery path.

This has happened twice now across recent updates. The immediately previous update did relaunch eventually, but took noticeably longer and remained visible in Task Manager while it was installing. In this failed case, I did not see a visible installer/Codex process after the app disappeared.

What steps can reproduce the bug?

  1. Run Codex Desktop on Windows with an update available.
  2. Click the in-app update affordance in the top-left corner.
  3. Observe that Codex enters the "installing" state.
  4. Wait for the expected automatic restart/relaunch.
  5. Check Task Manager for Codex-related processes if the app does not come back.

Observed result:

  • The package update completed according to Windows deployment logs.
  • Codex did not relaunch automatically.
  • No obvious Codex process was visible in Task Manager while waiting after the app disappeared.
  • Manually launching Codex afterward worked and showed the updated package installed.

What is the expected behavior?

After an in-app update reaches the installing state and the package update succeeds, Codex should either:

  • relaunch automatically, or
  • show a clear failure/recovery message explaining that the update installed but Codex could not restart, with instructions to launch it manually.

It should not silently disappear after installation, leaving no clear signal about whether the update succeeded, failed, or is still running in the background.

Additional information

I searched for existing issues before filing this. The closest issues I found were related but not exact duplicates:

  • #24010: launch crash when a Windows Store update is detected but cannot be downloaded.
  • #23814: Windows desktop silent closes/restarts and sidechat state issues; it mentions one update-time hang, but the main issue is repeated post-update/session behavior.
  • #23053: update prompt should show target versions and environment impact.

Local Windows deployment evidence for the failed relaunch case:

2026-05-22 10:25:10 local: Remove started for OpenAI.Codex_26.519.2736.0_x64__2p2nqsd0c76g0
2026-05-22 10:25:11 local: Remove completed successfully for OpenAI.Codex_26.519.2736.0_x64__2p2nqsd0c76g0
2026-05-22 10:25:13 local: Preferred package version changed from OpenAI.Codex_26.519.2081.0_x64__2p2nqsd0c76g0 to OpenAI.Codex_26.519.3891.0_x64__2p2nqsd0c76g0
2026-05-22 10:25:41 local: Stage completed successfully for OpenAI.Codex_26.519.3891.0_x64__2p2nqsd0c76g0
2026-05-22 10:25:42 local: RegisterByPackageFamilyName started for OpenAI.Codex_2p2nqsd0c76g0 with ForceTargetApplicationShutdownOption, RegisterHighestVersion, FailIfNeedsRemediation, SkipDeploymentOperationRpcCallerIsAdminCheck
2026-05-22 10:25:43 local: Register completed successfully for OpenAI.Codex_26.519.3891.0_x64__2p2nqsd0c76g0

Codex desktop log timing around the update:

2026-05-22T08:25:11.746Z info [AppServerConnection] Stopping app-server transport connectionId=1 transport=stdio
2026-05-22T08:25:11.746Z info [AppServerConnection] app_server_connection.state_changed cause=stop_process ... currentState=connected ... next=disconnected ...
2026-05-22T08:25:11.771Z info [browser-session-registry] IAB_LIFECYCLE removed browser session window windowId=1

No Windows Application log entries for Codex.exe / Application Error / Application Hang were found in the 2026-05-22 10:20-10:35 local window.

The next Codex desktop logs on this machine start at 2026-05-22 10:27:07 local, after I manually reopened the app.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #23814

Powered by Codex Action

claell · 1 month ago

This happened again with the latest Windows Desktop update.

Current package after manually reopening Codex:

OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0

The update appears to have replaced:

OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0

Observed behavior:

  • I triggered the update from the in-app top-left update affordance.
  • The app entered the installing state.
  • Codex did not relaunch afterward.
  • I waited at least 10 minutes, likely longer, and nothing came back.
  • After manually reopening Codex, the updated package was installed.

Windows deployment log timing for this recurrence:

2026-06-02 11:58:43 local: RegisterByPackageFamilyName started for OpenAI.Codex_2p2nqsd0c76g0 with ForceTargetApplicationShutdownOption, RegisterHighestVersion, FailIfNeedsRemediation, SkipDeploymentOperationRpcCallerIsAdminCheck
2026-06-02 11:58:43 local: updateList: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0 is updating to OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
2026-06-02 12:00:16 local: Register completed successfully for OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0

Codex desktop log timing around the same update:

2026-06-02T09:58:43.536Z info [AppServerConnection] Stopping app-server transport connectionId=1 transport=stdio

The old Codex desktop logs stop at 2026-06-02 11:58:43 local time. The next Codex desktop log files on this machine start at 2026-06-02 12:10:31 local time, after the long wait and manual reopen. I did not find a Codex-named Windows Application Error/Hang entry in the 11:50-12:20 local window.

This makes the behavior look consistent with the earlier report: the package update succeeds, but the post-update relaunch/recovery path silently fails.

claell · 1 month ago

This happened again with the next Windows Desktop update.

Current package after reopening Codex:

OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0

The update replaced:

OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0

Observed behavior:

  • I triggered the update from the app again.
  • The package update completed.
  • Codex did not come back normally afterward, so this is another recurrence of the same post-update relaunch failure.

Additional Windows deployment detail from this recurrence:

2026-06-04 10:58:35 local: updateList: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0 is updating to OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
2026-06-04 10:58:36 local: Register failed with 0x80073D02 because OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0 needed to be closed
2026-06-04 10:58:36 local: packages were not updated because affected apps were still running: {OpenAI.Codex_2p2nqsd0c76g0!App}

Later, when I triggered the in-app update path:

2026-06-04 12:22:06 local: RegisterByPackageFamilyName started for OpenAI.Codex_2p2nqsd0c76g0 with ForceTargetApplicationShutdownOption, RegisterHighestVersion, FailIfNeedsRemediation, SkipDeploymentOperationRpcCallerIsAdminCheck
2026-06-04 12:22:06 local: updateList: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0 is updating to OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
2026-06-04 12:23:41 local: Register completed successfully for OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0

Codex desktop log timing around the forced update:

2026-06-04T10:22:06.272Z info [AppServerConnection] Stopping app-server transport connectionId=1 transport=stdio

The old Codex desktop logs stop at 2026-06-04 12:22:06 local time. The next Codex desktop log files on this machine start at 2026-06-04 12:24:41 local time, after reopening on the updated package.

I did not find a Codex-named Windows Application Error/Hang entry in the 12:15-12:40 local window. The update itself succeeds, but the app still fails to return cleanly after the update shutdown.

SplitMilky · 1 month ago

I get this issue every time, have for a least a month now.

GuXinghai · 1 month ago

Same question, and I tried reinstall the App but same situation.

DeadlyEnvy · 1 month ago

I can corroborate this behavior on Windows as well. When the blue update icon appears at the top-left of the Codex window, I click it and briefly see the update dialog with wording that Codex will restart. The app closes and the update appears to apply, but Codex never relaunches automatically. Manually starting Codex afterward works.

claell · 5 days ago

Additional scope and frequency information:

  • I have now personally observed this behavior on three independent Windows setups: my own machine/account and two other people's machines/accounts.
  • On my machine, it has recurred across many separate Codex Desktop updates.
  • Automatic relaunch has occasionally worked, but only rarely. The typical outcome is that the update installs, Codex closes, and the app does not relaunch.
  • The other two Windows setups showed the same post-update failure, which makes a machine-specific configuration issue less likely.

This is also consistent with the independent reports already added to this issue, including reports that it occurs on every update and that reinstalling the app does not resolve it.

At this point, the evidence suggests a broader reliability problem in the Windows Store/AppX post-update relaunch path rather than an isolated intermittent failure on one installation. Could this issue please be routed to the owner of the Windows Desktop updater/relaunch flow for investigation?