Repository navigation
Windows Desktop crash/hang with codex.exe MoBEX and node_repl/extension-host BEX64 after recent update #31353
Description
Summary
Codex Desktop on Windows started crashing/hanging repeatedly during normal use. The workflow had been stable for several days while using the bundled chrome, browser, computer-use, and node_repl capabilities. The instability began suddenly on July 6-7, 2026.
This does not look like a single conversation corrupting state. Windows Error Reporting shows repeated codex.exe MoBEX crashes first, followed by a cascade involving node_repl.exe, extension-host.exe, and the main Codex app.
Environment
- OS: Windows 11, x64, build family 10.0.26100
- Current installed package:
OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0 - Previously crashing package in WER:
OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0 - Local CLI reported earlier:
codex-cli 0.130.0-alpha.5
Crash / Hang Timeline
Recent Windows Error Reporting entries:
- 2026-07-06 19:50-23:47: repeated
MoBEXforOpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0,P5: codex.exe,P9: c0000409,P10: 0000000000000007 - 2026-07-07 00:09-00:44: repeated same
codex.exeMoBEX / c0000409 - 2026-07-07 08:35 and 09:42: same
codex.exeMoBEX / c0000409 - 2026-07-07 09:58:
node_repl.execrashed withBEX64,P10: 0000000000000007extension-host.execrashed withBEX64,P10: 0000000000000007- Codex main app reported
MoAppCrash, moduleKERNELBASE.dll - Codex app then reported
MoAppHang
- 2026-07-07 11:19: Microsoft Store/AppX updated Codex from
26.623.13972.0to26.623.19656.0 - 2026-07-07 11:23: bundled plugin cache folders for
browser,chrome, andcomputer-usewere updated locally
What I Tried / Ruled Out
- Rotated a bloated/empty
~/.codex/logs_2.sqlitestate file. This reduced disk pressure but did not explain the crash sequence. - Observed high-frequency inserts into
~/.codex/logs_2.sqlite, then temporarily installed a SQLite trigger blocking inserts intologsand checkpointed/truncated WAL. After sampling,MAX(id), row count, and WAL size stopped growing, but Codex Desktop still crashed/hung. - A very large conversation file was compacted from about 3.2 GB to a recent-turn subset and validated as well-formed JSONL. This reduced load pressure but did not eliminate the app instability.
- The same user workflow was stable before July 6-7 with
chrome,browser,computer-use, andnode_repl, so the likely boundary is the Windows desktop app/runtime/plugin-host layer rather than the mere use of those capabilities.
Available Local Artifacts
Crash dumps exist locally under:
%LOCALAPPDATA%\CrashDumps\Codex.exe.3268324.dmp%LOCALAPPDATA%\CrashDumps\codex.exe.3094072.dmp%LOCALAPPDATA%\CrashDumps\codex.exe.3074908.dmp- several more
codex.exe.*.dmpfiles from 2026-07-07
I can provide redacted WER details or crash dumps if maintainers want a specific artifact.
Expected Behavior
Codex Desktop should not crash or hang when opening/continuing a thread or when the bundled node_repl / browser-related plugin hosts are active.
Actual Behavior
Codex Desktop repeatedly crashes or becomes unresponsive. Windows records MoBEX / c0000409 for codex.exe, followed by BEX64 crashes in node_repl.exe and extension-host.exe, then MoAppCrash / MoAppHang for the main app.
Related Issues
This seems related to the Windows crash/performance reports in:
- Windows Codex app crash plus runaway conhost/cmd processes during dictation/session freeze #28092
- Windows Codex app repeatedly spawns git.exe/conhost.exe in Git workspaces, possibly contributing to Nonpaged Pool growth #26812
- Codex desktop app intermittently freezes Windows shell/UI; opening Codex Settings stops the freeze #16374
- Codex Desktop on Windows generates excessive local SQLite I/O and causes system stalls #29177
- Desktop launch can fail when logs_2.sqlite grows large: app-server SQLite pool times out during startup #27741
- Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance #28224
Activity
github-actions commentedon Jul 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Bricklink commentedon Jul 17, 2026
Adding a data point with the same signature, plus a set of local causes I was able to eliminate through testing.
Environment
Timeline
Started the evening of 2026-07-15, immediately after Windows updates KB5101001, KB5101650, and KB5120102 were installed. Windows Error Reporting shows repeated Event 1000 crashes for ChatGPT.exe that evening with exception code 0xc06d007f and faulting module "unknown" (sample Report Id 4bc48318-5853-4d34-8cd3-ed5ec0577953), then Event 1002 AppHang entries on 2026-07-16 where Windows force-closed the app twice within one minute.
Current behavior on 26.715
The main window process is alive but oscillates between Responding and Not Responding indefinitely. Sampling
(Get-Process).Respondingevery 10 seconds for 3 minutes gives patterns likeHHHRHHHHHHRHHHHHRH(H = not responding, R = responding). It never settles, and CPU stays elevated on the main process while hung. No child processes (node_repl, extension-host, gpu) crash during the loop.Eliminated locally, each verified with the same 10s sampling method
--disable-gpulaunch: identical hang patternthread-browser-tabs-v1:*keys and trimming a 946KBprompt-historyblob inside.codex-global-state.jsonimproved time-to-first-responsive from roughly 60s to 8s, but the oscillating hang loop continued afterwardThe prompt-history observation may be worth a look independently: it appears the full typed-prompt history for every thread is serialized into
electron-persisted-atom-state, and ours had grown to nearly 1MB, which seems likely to be synchronously rewritten on the main thread.Happy to pull WER report contents or run an instrumented build if that would help.