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

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

• #40062
• #39890
• #40323

Powered by Codex Action

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.

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.

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.

+1