Summary
The ChatGPT/Codex Windows desktop app repeatedly crashes during local Codex work. Inspection found seven Crashpad crash sidecars from September 26–27, 2026: five marked ptype=browser (main/browser process), and two marked ptype=renderer.
For all five browser-process crashes, the final line of the corresponding desktop log is Sending server response ... success=true tool=read_thread. The crash sidecar modification times follow that line by approximately 0.7–5.6 seconds. This is a repeated temporal correlation, not proof that read_thread itself is the root cause.
Environment
- Surface: Windows desktop app, local Codex tasks.
- Windows 11 Pro, x64, version 10.0.26200.
- Running executable: ChatGPT.exe in the OpenAI.Codex MSIX package.
- App update checker: installedVersion 26.924.22138, build 11645, release channel prod, status up_to_date.
- Windows package version: 26.924.2738.0, package status Ok. Both version identifiers are included intentionally.
- Model/plan at each crash: not established by this investigation.
Bug and observed failure sequence
During local Codex work, the agent reads another chat through the desktop read_thread tool. Logs show thread/read, thread/turns/list and, in some cases, thread/items/list requests completing. The last desktop log line reports a successful read_thread response, followed shortly by a browser-process crash sidecar.
Expected: return the other chat’s information and keep the desktop application running.
Actual: repeated desktop crashes interrupt the workflow.
Reproduction status
This has recurred during normal use, but a deterministic minimal reproduction has not been established. The exact required conversation contents, response size, and tool arguments are unknown. Please treat the sequence above as an observed failure pattern rather than an independently verified reproduction recipe.
Correlated diagnostics (UTC)
The second timestamp below is the Crashpad sidecar’s filesystem modification time, not a timestamp extracted from a native crash stack.
| Last successful read_thread response | Browser crash sidecar modified | Approximate interval |
|---|---|---|
| 2026-09-27 04:31:53.415Z | 2026-09-27 04:31:54.350Z | 0.94 s |
| 2026-09-27 09:20:09.906Z | 2026-09-27 09:20:15.555Z | 5.65 s |
| 2026-09-27 12:09:40.717Z | 2026-09-27 12:09:41.549Z | 0.83 s |
| 2026-09-27 12:33:04.995Z | 2026-09-27 12:33:06.095Z | 1.10 s |
| 2026-09-27 13:17:17.724Z | 2026-09-27 13:17:18.411Z | 0.69 s |
Representative sanitized desktop log:
2026-09-27T13:17:17.724Z info [electron-message-handler] Sending server response callId=<redacted> isRemoteHost=false rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true success=true tool=read_thread turnId=<redacted>
Associated sidecar metadata:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}
Checks and limitations
- No matching ChatGPT/OpenAI Application Error or Application Hang entries were found in the Windows Application event log during the seven-day check, despite the application-owned Crashpad records.
- At inspection time, approximately 13 GiB of physical memory and 67 GiB of C: disk space were available. This does not establish memory usage at the instant of each crash.
- No native dump or stack trace was available in the inspected Crashpad reports directory; only the sidecars remained.
- The two renderer crashes have not been attributed to the same trigger.
- No cache reset, reinstall, GPU-setting change, or controlled crash reproduction has been performed.
Could the team investigate the desktop read_thread response handling / IPC path and advise how to collect a useful native crash dump if it recurs? Private chat contents, user paths, and chat/call IDs have been omitted from this public report.
reaction to the GitHub issue itself, rather than only reacting to this forum topic. GitHub reactions can help the maintainers gauge how many users are affected.