›_ Codex Issues
Codex Issues / #33321

[Windows] Background Store update silently exits tray app and does not relaunch

Open 💬 5 comments Opened Jul 15, 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)?

This was observed across two unattended Windows Store/AppX updates:

  • OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0 to OpenAI.Codex_26.707.6957.0_x64__2p2nqsd0c76g0
  • OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0 to OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0

The currently installed package is OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0.

What subscription do you have?

Unknown / not relevant to the updater behavior.

What platform is your computer?

Windows 11 Education 25H2, build 26200.8655, 64-bit.

What issue are you seeing?

Codex Desktop can silently disappear from the Windows tray when a background Microsoft Store/AppX update is installed, even though I did not click the blue in-app update button or otherwise initiate an update. The package update succeeds, but Codex does not relaunch and remains completely closed until I start it manually.

I first noticed the symptom after returning to the laptop later, including after leaving it in standby overnight. This initially looked like Codex had crashed during standby. The logs instead show that Codex had already been terminated by an unattended package update and had never returned. This distinction matters because someone encountering the symptom may search for an overnight, resume, standby, or tray crash rather than an in-app update failure.

I observed this twice in the last few days. In both cases:

  • Codex was running without an update being manually triggered.
  • The updater detected or installed a package in the background.
  • Windows registered the package with ForceTargetApplicationShutdownOption.
  • Codex logged Stopping app-server transport at the same moment.
  • The package update succeeded, but no Codex process or tray icon returned.
  • Manually launching Codex later opened the newly installed version normally.

There was no matching Windows Application Error, Application Hang, or Windows Error Reporting entry. This appears to be an unattended update shutdown followed by a failed relaunch, not a process crash.

What steps can reproduce the bug?

The timing depends on update availability, but the observed flow is:

  1. Start Codex Desktop on Windows and leave it running or minimized to the tray.
  2. Do not click the in-app update button.
  3. Leave the application running while a Microsoft Store/AppX update becomes available and is downloaded or installed in the background.
  4. Allow Windows to register the new Codex package.
  5. Return to the computer later or wake it from standby.

Observed result:

  • Codex is no longer running and its tray icon is gone.
  • There was no update prompt, installing state, crash dialog, or other explanation.
  • Codex does not relaunch automatically.
  • A manual launch starts the updated package successfully.

What is the expected behavior?

An unattended background update should not silently leave Codex closed. Codex should either:

  • relaunch automatically after the package update completes, preserving its prior tray/window state, or
  • defer an update that requires terminating the running application until the user explicitly approves it.

If neither is possible, Windows or Codex should at least provide a notification explaining that the application was closed for an update and must be reopened manually.

Additional information

First unattended occurrence:

2026-07-12 21:28:15 CEST: Codex checks the Store; buildVersion=26.707.3748.0, manifestBuildVersion=26.707.6957.0
2026-07-12 21:29:05 CEST: update check completes with canSilentlyDownload=true, hasUpdate=true
2026-07-12 22:01:47 CEST: Codex logs "Stopping app-server transport"
2026-07-12 22:01:47 CEST: AppX RegisterByPackageFamilyName starts with ForceTargetApplicationShutdownOption
2026-07-12 22:01:47 CEST: updateList records 26.707.3748.0 updating to 26.707.6957.0
2026-07-13 10:49:35 CEST: next Codex log session begins after manual launch

Second unattended occurrence:

2026-07-14 05:13:24 CEST: Codex checks the Store; buildVersion=26.707.8479.0, manifestBuildVersion=26.707.9564.0
2026-07-14 05:14:16 CEST: update check completes with canSilentlyDownload=true, hasUpdate=true
2026-07-14 14:55:22 CEST: Codex logs "Stopping app-server transport"
2026-07-14 14:55:22 CEST: AppX RegisterByPackageFamilyName starts with ForceTargetApplicationShutdownOption
2026-07-14 14:55:22 CEST: updateList records 26.707.8479.0 updating to the newer 26.707.9981.0 package
2026-07-15 10:34:20 CEST: next Codex log session begins after manual launch

For the second occurrence, Windows recorded the later overnight standby from 2026-07-15 01:37 until 10:29 CEST. Codex had therefore already been closed by the package update more than ten hours before standby began.

The relaunch behavior is intermittent. An intervening update from 26.707.6957.0 to 26.707.8479.0 on July 13 was followed by a new Codex log session about three seconds later, consistent with a successful automatic relaunch.

Related issues:

  • #24047 reports the same post-update relaunch failure after manually clicking the in-app update affordance.
  • #29787 also reports no relaunch after manually clicking the blue update button and appears to duplicate #24047.

This report is specifically about the unattended background-update trigger and its distinct user-visible symptom: a previously running tray application is silently gone when the user next returns to or wakes the computer.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32754

Powered by Codex Action

claell · 1 month ago

I reviewed the suggested #32754 and its related #31989. They are relevant, but the captured update outcomes differ:

  • #32754 correlates the silent exit with a failed Store update scan (StoreAgentScanForUpdatesFailure0, 80072efd). It does not show a new package being successfully registered and activated.
  • #31989 includes a Store update lifecycle interruption, but Windows automatically created a new Codex process/container about four minutes later and the staged package was not cleanly activated for that user.
  • In this issue, Windows successfully registered a newer package with ForceTargetApplicationShutdownOption, Codex stopped at that exact moment, the new version was present at the next manual launch, and no automatic relaunch occurred for many hours.

The common user-visible symptom is a silent exit, but this report specifically tracks a successful unattended package update that permanently removes the running tray instance until the user manually launches it again.

Kinasa0096 · 1 month ago

Additional current-build confirmation from Windows 10, with local AppX/AppModel event evidence:

  • OS: Windows 10 Pro 22H2, build 19045.6466, x64
  • Update: OpenAI.Codex_26.715.7063.0_x64 -> OpenAI.Codex_26.715.9079.0_x64
  • All times below are local time (UTC+3).

Windows recorded the update at 2026-07-22 16:37:

  • AppXDeploymentServer event 855: 26.715.7063.0 was updating to 26.715.9079.0.
  • AppXDeploymentServer event 400: both the Stage and Register operations finished successfully.
  • AppModel-Runtime updated the old/new package state at the same time, but there was no event 201 process creation for the updated package in the post-update window.

The next AppModel-Runtime event 201 was not until 2026-07-23 03:58, when process 15004 was created for OpenAI.Codex_2p2nqsd0c76g0!App after the user manually opened Codex. All current Codex/ChatGPT processes share that 03:58 start time. That leaves roughly 11 hours between successful registration and the next launch.

The user reports that this is recurrent: Codex silently closes for an update and often remains closed until manually launched. Manual launch opens the newly installed build normally, so this is again a successful package update followed by a missing relaunch rather than a startup crash.

One additional packaging observation: the current AppxManifest.xml contains no windows.startupTask extension, and there is no Codex entry under the user's normal HKCU\...\Run startup keys. Those are not required for a proper post-update handoff, but they mean there is no secondary startup path to recover when that one-shot relaunch fails.

Suggested acceptance check for the fix: after a successful background Register operation, verify that the new package AUMID is activated and that a process/container is actually created; if activation fails or times out, notify the user that the update completed but Codex must be reopened manually.

ESKehler · 4 days ago

Additional confirmed occurrence with a definitive Windows servicing event.

Environment

  • Windows 10, build 19045.7663, x64
  • Running package before the stop: OpenAI.Codex_26.814.5167.0_x64
  • Package installed during the stop: OpenAI.Codex_26.818.3698.0_x64
  • Current package after a later background update: OpenAI.Codex_26.818.5229.0_x64
  • Times below are local PDT (UTC-7).

Timeline

2026-08-22 11:01:44  Codex scheduled primary-runtime update begins for bundle 26.819.11345.
2026-08-22 11:04:07  Runtime activation fails after 142.5 s with EPERM while renaming
                     the active runtime directory; retryable=false.
2026-08-22 11:30-11:32  x64/x86 Visual C++ redistributable installers run in the
                        same servicing window; Restart Manager records activity.
2026-08-22 11:33:04  Last Codex desktop log entry. It is a normal periodic
                     configRequirements/read response; there is no quit, crash,
                     renderer failure, or app-server-exit record.
2026-08-22 11:34:13  AppXDeploymentServer event 855 records:
                     26.814.5167.0 is updating to 26.818.3698.0.
2026-08-22 11:34:14  AppXDeploymentServer event 646:
                     "The running app OpenAI.Codex...!App was shut down for servicing."
2026-08-22 11:34:14  AppXDeploymentServer event 637 says running apps were shut
                     down to allow the packages to update; previous attempts=3;
                     user session locked=true.
2026-08-22 11:34:17  Registration of 26.818.3698.0 finishes successfully.
2026-08-22 17:21:27  26.818.3698.0 is de-staged while Codex remains closed.
2026-08-23 05:34-05:36  26.818.5229.0 is staged and registered successfully.
2026-08-23 09:04:26  Next observed Codex launch, about 21.5 hours after the
                     forced servicing shutdown.

The app was therefore not stopped by a normal process crash. Windows explicitly terminated it for a successful background package update, and neither that update nor the later package update restored the running tray instance.

Alternative causes checked

No matching evidence was found for:

  • Windows Application Error, Application Hang, or WER/Crash report involving Codex;
  • system shutdown, restart, sleep transition, Kernel-Power failure, or unexpected power loss;
  • resource-exhaustion / out-of-memory event;
  • Defender detection, quarantine, or remediation involving Codex;
  • Code Integrity block involving a Codex/OpenAI binary;
  • GPU/display-driver reset, renderer crash, or app-server child exit.

A Defender intelligence update completed in the same minute, but it logged no Codex detection or remediation. Unrelated Code Integrity noise concerned Bonjour, not Codex.

Separate update-lifecycle failure

About 30 minutes before AppX shut down the app, Codex's own scheduled primary-runtime updater failed to activate bundle 26.819.11345:

errorCategory=permission_denied
errorCode=EPERM
failureStage=activate_runtime
outcome=failed
retryable=false
trigger=scheduled_update
operation=rename active runtime -> previous runtime

Codex continued running for about 30 minutes after this failure, so it was not the direct cause of the stop. It is nevertheless relevant update-lifecycle evidence and matches #40182: the updater attempts to rename a runtime tree still held open by live Codex/helper processes.

Requested behavior

For unattended Store/AppX updates, please either:

  1. defer servicing until the user approves/restarts;
  2. reliably activate the new package and restore the prior running/tray state;
  3. if relaunch fails, notify the user that Codex was closed for an update; and
  4. preserve/recover active long-running tasks across the servicing shutdown.

At minimum, the UI or next launch should explain that the prior process was intentionally terminated for servicing rather than crashed.

globaljpq · 3 days ago

Additional ARM64 confirmation on newer August builds.

Environment:

  • Windows 11 ARM64
  • Codex was left running unattended
  • Running package before the event: OpenAI.Codex_26.810.7004.0_arm64
  • Package installed by the background update: OpenAI.Codex_26.818.3698.0_arm64

On 2026-08-22 at approximately 05:10 local time, Codex silently disappeared while the computer itself remained running.

Windows event logs show that this was a successful background Store/AppX update rather than an application crash:

  • AppXDeploymentServer event 855: OpenAI.Codex_26.810.7004.0_arm64 was updating to OpenAI.Codex_26.818.3698.0_arm64.
  • AppModel-Runtime event 217: the running OpenAI.Codex_26.810.7004.0_arm64 Desktop AppX container was destroyed at 05:10:45.
  • AppModel-Runtime event 42: OpenAI.Codex_2p2nqsd0c76g0 AppContainer was successfully updated at the same time.
  • AppXDeploymentServer event 472: the old 26.810.7004.0 package folder was moved into WindowsApps\Deleted.
  • AppXDeploymentServer event 400: registration of 26.818.3698.0 completed successfully.

The Codex desktop log ends at essentially the same moment. Its final entry is an ipc-connection-reset; there is no normal quit, fatal exception, crash, OOM, renderer termination, or app-server process-exit event.

Reliability Monitor also showed no Codex application crash, and Windows did not reboot.

Codex did not automatically relaunch after the successful update. When I later launched it manually, the updated version opened normally and worked normally.

This appears to reproduce the same successful-background-update / failed-relaunch behavior on ARM64 and on substantially newer August builds.