[Windows][26.818.5229.0] Codex Desktop silently exits during normal work; no WER/crash event; reboot temporarily fixes it #40576

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   performance

   on Aug 25, 2026
2. github-actions commented on Aug 25, 2026

   

   github-actionsbot

   on Aug 25, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop 26.818.5229.0 repeatedly crashes on Windows while Codex CLI remains stable #40062
   • [Windows] Codex Desktop exits when opening @/+ composer picker and can enter startup exit loop #39890
   • [Windows] Automatic compaction repeatedly embeds inline images, growing a long-running rollout beyond 16 GiB #40323

   Powered by Codex Action
3. mikkinels322 commented on Aug 25, 2026

   

   mikkinels322

   on Aug 25, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Additional A/B test: silent exit reproduces with hardware GPU disabled

   I performed a controlled GPU-off test to check whether the Windows/Chromium hardware GPU path is responsible for the silent exits.

   Codex Desktop was launched through IApplicationActivationManager::ActivateApplication with:

   --disable-gpu
   

   I verified from the live process command lines that the flag was actually applied to the main process:

   ChatGPT.exe --disable-gpu
   

   The Chromium GPU process was using software WARP rather than the NVIDIA hardware path:

   --use-gl=angle --use-angle=d3d11-warp-webgl
   

   Renderer processes also had:

   --disable-gpu-compositing
   

   So this was a real software-rendering test, not merely a launcher flag that was ignored.

   Despite that, Codex silently exited again at approximately 14:52 local time.

   Immediately after the exit:

   ChatGPT process count: 0
   Codex process count: 0
   ChatGPT processes with MainWindowHandle != 0: 0
   

   Additional state at the failure:

   • RAM: 31.84 GB total, 19.13 GB free
   • .codex total size: 7.54 GB
   • largest rollout: 705.10 MB
   • sessions >= 1 GB: 0
   • no matching Application Error / WER event
   • no relevant Display/NVIDIA GPU event
   • no relevant crash dump

   The largest rollout was ~704.45 MB before this experiment and ~705.10 MB at the failure, so there was no rapid multi-GB session growth associated with this exit.

   This suggests that the NVIDIA hardware GPU / Chromium hardware acceleration path is not required to reproduce the silent full-process exit. The separate rollout/compaction growth issue still exists, but this reproduction also occurred while the active session size was relatively stable.
4. mikkinels322 commented on Aug 25, 2026

   

   mikkinels322

   on Aug 25, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Stronger crash evidence: Crashpad captured a main browser-process crash

   A subsequent read-only inspection of Codex's own local logs/Crashpad metadata identified the failure class more precisely.

   At 14:52:28 local time (UTC+5), Crashpad created a report with:

   {"capture_kind":"crash","ptype":"browser"}

   This occurred exactly one second after the last normal log entry from the previous Codex process.

   Timeline:

   • 14:43:19 — active turn started
   • 14:51:20 — last tool call completed successfully (read-only local Laravel query)
   • 14:52:25 — last app-server request: configRequirements/read
   • 14:52:27 — last log line from the process: GET /backend-api/codex/models returned 200 OK
   • 14:52:28 — Crashpad recorded capture_kind=crash, ptype=browser
   • 14:53:36 — new web session started
   • 14:53:55 — new Codex process performed thread/resume
   • 14:54:03 — continuation turn created to resume the interrupted work

   In the final ~60 seconds before the crash, there were no WARN, ERROR, panic, shutdown, or orderly-exit records.

   Also not observed immediately before the crash:

   • thread/turns/list
   • thread/read
   • thread/resume
   • app-server disconnect/exit
   • renderer/webview termination
   • process gone
   • GPU-process crash marker
   • plugin reconciliation failure
   • fs-helper failure
   • AppX lifecycle error

   The last completed tool operation had already succeeded. The application then began the next model request and the main browser process crashed before that step completed.

   This confirms that at least this reproduction was a real crash of the main Chromium/Electron browser process, not a normal chat close, Laravel/PHP failure, network disconnect, or session-only failure.

   Unfortunately, the local Crashpad data contains no exception code or faulting module, and no minidump was persisted. Windows Event Log still shows no matching Application Error entry for the crash window.

   This browser-process crash also occurred during the previously reported GPU-off A/B test, where the main process had --disable-gpu and Chromium was using software WARP (--use-angle=d3d11-warp-webgl). So hardware NVIDIA acceleration is not required to reproduce this crash.
5. mikkinels322 commented on Aug 27, 2026

   

   mikkinels322

   on Aug 27, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Workaround appears confirmed: disabling the Windows updater stopped the crashes

   Follow-up after extended real-world testing.

   Before the workaround, Codex Desktop was crashing repeatedly during normal work, often roughly every 30–40 minutes. Multiple Crashpad reports consistently showed:

   capture_kind=crash
   ptype=browser
   

   Two independently captured full minidumps had the same native crash signature:

   Exception:       0xC0000005 (Access Violation)
   Operation:       Read
   Invalid address: 0x0
   Faulting module: resources\native\windows-updater.node
   Module offset:   +0x2D693
   

   Disabling GPU acceleration did not prevent the crash; the same browser-process crash reproduced while Chromium was using software WARP.

   I then set the following as a persistent User environment variable in Windows:

   CODEX_SPARKLE_ENABLED=false
   

   and rebooted Windows before launching Codex normally from the Start menu.

   Since doing that, Codex has completed multiple normal development/work sessions with zero crashes, whereas before the change crashes were occurring repeatedly throughout the day. The machine has also remained running across the extended test period rather than relying on repeated reboots as a temporary recovery.

   This strongly suggests that, for this crash signature, the native Windows updater path is the trigger and CODEX_SPARKLE_ENABLED=false is an effective temporary workaround.

   Important detail: initially I tried setting $env:CODEX_SPARKLE_ENABLED='false' only inside a PowerShell session and launching the MSIX app through ApplicationActivationManager. Codex later crashed again at the identical windows-updater.node +0x2D693 address. The workaround only became reliable after setting CODEX_SPARKLE_ENABLED=false persistently at the Windows User environment level and rebooting.

   For affected users with the same dump signature, the PowerShell command used was:

   [Environment]::SetEnvironmentVariable(
       "CODEX_SPARKLE_ENABLED",
       "false",
       "User"
   )

   Then verify:

   [Environment]::GetEnvironmentVariable(
       "CODEX_SPARKLE_ENABLED",
       "User"
   )

   Expected output:

   false
   

   After that, reboot Windows and launch Codex normally.

   This should be treated as a temporary workaround rather than a permanent fix, since it disables the affected in-app updater path. The underlying windows-updater.node null-read crash still needs to be fixed.
6. Zikang7 commented on Aug 28, 2026

   

   Zikang7

   on Aug 28, 2026

   More actions

   +1
7. altim8Solutions commented on Sep 9, 2026

   

   altim8Solutions

   on Sep 9, 2026

   More actions

   Current-version reproduction: UI/window disappears while backend stays alive; successful AppX reactivation does not recreate a window

   I reproduced a closely related but diagnostically distinct variant three times on the current Windows package. In the latest occurrence, the desktop UI/window disappeared while the AppX container and Codex backend remained alive.

   Environment

   • Codex Windows package: OpenAI.Codex 26.903.8094.0 x64
   • ChatGPT.exe file version: 152.0.7977.83
   • Bundled codex-cli: 0.153.4
   • Windows build: 10.0.26200.9445
   • Time zone: Europe/Berlin

   Latest incident

   • Time: 2026-09-09, approximately 11:52–11:54 CEST
   • All Codex windows disappeared.
   • Task Manager showed Apps (0) but Codex (16) under Background processes.
   • The Codex process group used approximately 1,122.9 MB; overall memory was 78% and CPU approximately 33%.
   • Launching Codex again did not restore a visible window.
   • A Windows restart was eventually used for recovery.

   Strong diagnostic evidence

   1. At 11:52:38, AppModel-Runtime events 211/201 (record IDs 1724377/1724378) show a new launch process, PID 2580, being added to the already-live Codex AppX container.
   2. TWinUI event 1621 (record ID 3127) reports the attempted Codex activation as successful, but no window appeared.
   3. The Codex backend, PID 11456, continued normal codex_app_server::outgoing_message activity through 11:53:21 with targeted_connections=1.
   4. There were no Codex WARN/ERROR records immediately before the restart.
   5. No warning/error event appeared in Application, System, or Resource-Exhaustion logs between 11:40 and 11:54:34. There was also no DWM, GPU, display-driver, OOM, or new WER crash event for this occurrence.
   6. WER events after the restart reused report ID 33331c8b-f2ca-4b07-9726-38cca33bbc18 from an earlier 10:29 HamLkd incident; they were queue reprocessing, not a new report.
   7. The restart was user-initiated: User32 event 1074 at 11:54:35, EventLog 6006 at 11:54:52, and EventLog 6005 at 11:55:32.
   8. Related prior evidence on the same installation includes RADAR_PRE_LEAK_64 for codex.exe on 2026-09-08 and the separate 10:29 HamLkd event.

   Session/resource observations

   • The active thread rollout was only about 22.7 MB, so an oversized active transcript is not sufficient to explain this incident.
   • A historical, not-loaded thread has a 2,220,909,855-byte rollout, but it remained unchanged during the incident.
   • The process count and memory pressure may be amplifiers, but Windows recorded no resource-exhaustion event.

   Expected

   If the main window or renderer disappears, a new activation should restore or recreate a visible main window.

   Actual

   Windows reports successful activation and adds a new process to the existing AppX container, but the application remains background-only with no visible window while the Codex backend continues working.

   This points strongly to a desktop shell / renderer / single-instance activation recovery problem rather than a backend or task failure. Raw rollout JSONL and SQLite databases are not attached because they contain sensitive conversation data. Sanitized event details can be provided if maintainers request them.

   Potentially related: #42714, although that report describes headless startup after an update rather than loss of the window during an active task.