ChatGPT.exe (Codex desktop) crashes repeatedly in a loop, same process instance, since the 2026-07-13 update
What version of the Codex App are you using (From “About Codex” dialog)?
26.707.12708.0
What subscription do you have?
Pro
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Environment
- App / package:
OpenAI.Codex_26.707.12708.0_x64__2p2nqsd0c76g0 - Component: Desktop app —
ChatGPT.exehelper process (path:app\ChatGPT.exe, notapp\resources\ChatGPT.exe) - OS: Windows 11 Pro, x64
- Hardware: Intel Core Ultra 7 165U, 32GB RAM — not resource-constrained (11+GB free RAM, CPU largely idle at time of crashes)
Summary
Since this build's ChatGPT.exe component was last updated (file timestamp 2026-07-13 14:10), it has been crashing repeatedly — same process ID, same faulting offset, over and over — without the process actually terminating/relaunching cleanly between crashes. This is a regression: zero crashes from this component exist in Event Log history before 2026-07-15.
Crash signature
- Exception code:
0xc06d007f - Faulting module: unknown (module info not resolved in WER report)
- Fault offset:
0x00007fffd0281b6a - Faulting process ID: consistently the same PID (
0x2DC4) across dozens of crash events, with an identical "Faulting application start time" each time — i.e. this looks like one long-lived process instance repeatedly throwing an unhandled exception rather than crashing and restarting.
Timeline (from Windows Application Event Log, Event ID 1000)
| Date | ChatGPT.exe crash count |
|---|---|
| Before 2026-07-15 | 0 |
| 2026-07-13, 14:10 | ChatGPT.exe component file updated (likely trigger) |
| 2026-07-15 | 110 |
| 2026-07-16 (partial day) | 58 (ongoing) |
Impact
- App is generally usable but the constant crash-and-exception cycle (roughly once every 1-2 minutes) coincides with severe, ongoing sluggishness in the app and on the machine generally.
- This is separate from, but compounds with, a completely unrelated background AV agent issue on my machine — flagging in case others report a similar "everything feels slow" symptom alongside the crash count, since the crash loop itself generates constant process/thread churn.
What steps can reproduce the bug?
Not yet isolated to a specific user action — crashes recur continuously during normal use of the app (idle and active). Will update if a specific trigger is identified.
What is the expected behavior?
No user experience degradation
Additional information
Related issues
These appear to be the same "Codex → unified ChatGPT desktop app" migration era causing broader Windows instability, though none exactly match this signature:
- #33516 — ChatGPT desktop crashes immediately after the Codex→ChatGPT migration (Windows ARM64)
- #31353 — Windows desktop crash/hang after a recent update
- #33197 — random crashes causing severe startup lag, "still happening after repeated reports"
- Community thread: "Latest Windows Codex build crashes unexpectedly during normal use"
What I've checked
- Windows Application Event Log (Event ID 1000) — full crash timeline as above.
- Crashpad database at
%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\Crashpad\reports— currently empty, no local.dmpavailable to attach. - Codex home (
%USERPROFILE%\.codex) — available if a maintainer wants specific log/session data (will review for sensitive content before sharing, per your docs).
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Confirmed duplicate of #33518.
I pulled a local crash dump for this crash (%LOCALAPPDATA%\CrashDumps\ChatGPT.exe(6).11716.dmp — Windows had already captured 10 of these locally) and searched it for the module paths identified in #33518's analysis. It contains the same load chain, repeated across multiple dump instances:
...device-kit\node_modules\serialport\node_modules\@serialport\bindings-cpp\build\Release\serialport.node
Same native addon (@serialport/bindings-cpp → serialport.node), same "Codex Micro" / Work Louder device-kit trigger described in #33518 and #33494 — the app appears to unconditionally attempt to load this native serial-port driver even with no such device connected, and it fails to resolve its N-API symbols from the ChatGPT.exe host (0xC06D007F / delay-load ERROR_PROC_NOT_FOUND).
Closing this in favor of #33518 as the canonical report, but flagging the independent confirmation here in case it's useful corroboration across environments — happy to share more of the dump if a maintainer wants it.