Codex desktop (Windows) main process crashes silently — window disappears while in use, 6 times in 2 days (build 26.915.31945)

What version of the Codex app are you using?

Codex desktop for Windows, build codex@26.915.31945, installed from the Microsoft Store (MSIX package 9PLM9XGG6VKS-OpenAI.Codex).

What subscription do you have?

ChatGPT Plus

Which model were you using?

Not model-specific. The app crashed while a session was active, with different models/agents running at the time.

What platform is your computer?

Windows 11 (build 10.0.26200), x64. Time zone Asia/Tokyo (UTC+9).

What terminal are you using?

The Codex desktop app UI (not the CLI). The app is running as an MSIX/Store app.

What did you do?

Normal use of the Codex desktop app on Windows — chatting, running tasks, opening threads. Nothing unusual was done immediately before the crashes.

What did you expect to see?

The app keeps running.

What did you see instead?

The Codex window disappears instantly while I am using it. No error dialog, no freeze first, no Windows blue screen, no "app has stopped working" prompt. The process is simply gone and I have to launch the app again. It has happened six times in two days.

Local time (JST, UTC+9) / UTC:

#	Local (JST)	UTC
1	2026-09-19 17:28:55	08:28:55
2	2026-09-19 17:55:01	08:55:01
3	2026-09-20 16:24:41	07:24:41
4	2026-09-20 17:06:55	08:06:55
5	2026-09-20 18:00:47	09:00:47
6	2026-09-20 18:51:56	09:51:56

Additional information / evidence gathered locally

1. The app's own crash reporter recorded all six events. %APPDATA%\Codex\web\Codex\Crashpad\reports contains one sidecar per event, each with exactly:

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

   ptype: browser means the Electron main process terminated, which matches the whole window vanishing. The matching .dmp files are no longer on disk by the time I look.

2. The app's own log database stops at the crash second. In ~/.codex/logs_2.sqlite, for the most recent crash the last row is 2026-09-20 18:51:55, the Crashpad sidecar is written 18:51:56, and the next row is 21:10:32 after I reopened the app — a 2h19m gap. The rows immediately before the stop are ordinary activity (config/read, configRequirements/read, streaming item/reasoning/textDelta). There is no error, warning, panic, or shutdown entry before the process disappears.

3. Windows never records it. There is no Application Error (event 1000) entry for the Codex/ChatGPT process in the Application log, and no failure record in Reliability Monitor. That is consistent with the app handling the crash internally via Crashpad instead of letting Windows Error Reporting catch it.

4. Crash dumps are not retained or uploaded. The app's Sentry scope file (...\Codex\web\Codex\sentry\scope_v3.json) reports release: codex@26.915.31945 and the tag minidumpAttachmentUploadEnabled: false. Locally a .dmp has never survived long enough for me to copy it; I have since set up a watcher that copies any new .dmp out of the reports directory within a fraction of a second, so a full minidump can be attached for the next occurrence.

5. Possible contributing factors I cannot rule in or out: the machine logs recurring hardware-level WHEA LiveKernelEvent records (bugcheck 0x124), and local Codex state is large (logs_2.sqlite ≈ 2.8 GB, thread_history_1.sqlite ≈ 966 MB). The Store package also auto-updates frequently (successful updates on 09-11, 09-12, 09-15, 09-17, 09-18, 09-19).

What I am asking for

1. Whether these crashes are a known issue for build 26.915.31945 on Windows.
2. What to capture so the next occurrence is actionable. I can provide a full minidump plus the surrounding app log rows as soon as it happens again.
3. Any guidance on whether large local state (logs_2.sqlite / thread_history_1.sqlite) could contribute to a main-process crash on Windows.

(Also reported to OpenAI support as case 15453487.)

Start with the Crashpad reports under %APPDATA%\Codex\web\Codex\Crashpad\reports, the surrounding rows in ~/.codex/logs_2.sqlite, and the release settings in sentry\scope_v3.json. Reproduce or inspect the next crash using the reported minidump watcher, then correlate the dump with the final log entries and build 26.915.31945. Done means identifying an actionable crash cause or documenting the evidence needed for escalation.