Repository navigation
Desktop app (Codex mode) silently exits ~25s after launch in an endless crash loop on Windows 11 — reproduces even with a blank profile; the CLI works fine #37752
Description
Environment:
- App: ChatGPT desktop app, Codex mode — version 26.803.41515
- OS: Windows 11 Pro, build 26200
- Device: LG Gram 16 (16ZD90Q-GX56K), 16 GB RAM
- Codex CLI on the same machine: 0.130.0-alpha.5 (works normally)
Summary:
The desktop app launches, runs ~22–30 seconds, then silently exits with no error dialog, immediately relaunches, and repeats — an endless crash loop, so the app is completely unusable. It was stable for ~8 days and started crashing right after a background runtime auto-update. The CLI on the same machine works fine, so this is specific to the desktop front-end, not Codex core.
Onset: The background "cua_node" runtime (computer-use / node_repl) auto-updated; the first launch after that began the crash loop. No manual app update; Microsoft Store reports "latest version installed," so reinstalling pulls the same crashing build.
Does NOT fix it (so it is not profile/data corruption): - Cleared the ~730 MB log DB (logs_2.sqlite)
- Cleared / re-materialized system skills
- Disabled computer-use plugin + node_repl MCP + turn-ended notify hook
- Deleted the cua_node runtime and let it re-download a fresh copy (fresh runtime still crashes)
- Microsoft Store app Reset
- A completely fresh/blank profile (renamed %USERPROFILE%.codex) still crashes at the login/setup screen
Logs (%USERPROFILE%.codex\logs_2.sqlite, table "logs"): - Each process lives ~22–30s and ends with no panic/error line.
- Last activity before exit: MCP init (node_repl, codex_apps -> start_server_task ... "worker quit with reason: Cancelled"), connecting to remote-control websocket (wss://chatgpt.com), a burst of fs/readFile, and WARN "could not find callback for Integer(0)".
- Windows Event Viewer shows no Application Error (1000)/WER (1001) in the crash window -> clean/abrupt termination, not a native fault.
Impact: desktop app 100% unusable (crash loop). Only the terminal CLI works.
Expected: the desktop app should launch and stay running.
Possibly related: Codex Desktop crashes on startup after interrupted/unstable automatic update; manual latest install fixes it #30543, Codex desktop repeatedly crashes when using Computer Use. #26458, Codex Desktop App — Frequent Crash Report #31098.
Activity
github-actions commentedon Aug 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
paraninternational commentedon Aug 10, 2026
Same crash on Windows 11 (build 26200), desktop app 26.803.41515. It launches, runs ~25s, then silently exits with no crash dialog, and relaunches in an endless loop — completely unusable.
Confirmed not local/profile: still crashes with a brand-new blank %USERPROFILE%.codex, after a Microsoft Store "Reset," and after deleting + letting the app re-download the cua_node runtime. Reinstall is a no-op (Store says "latest installed"). No Application Error/WER 1000 in the crash window (consistent with the 0xc0000409 fast-fail you captured).
App-server logs (logs_2.sqlite) show each process dying ~25s into startup during MCP init:
worker quit with reason: CancelledandWARN could not find callback for Integer(0), right after connecting to the remote-control websocket. Codex CLI (0.130.0-alpha.5) works fine on the same machine.+1 — same deterministic startup crash.
ShiMiaohui0426 commentedon Aug 10, 2026
I am seeing the same problem on another Windows installation.
Environment
26.803.41515elevatednode_replcomponents were enabled in the original configurationSymptom
The app opens normally, but after running for only a short time it switches to a crash page. The localized Chinese message is:
This is not just a silent window close in this case; the app displays the “ChatGPT unexpectedly stopped” recovery screen.
Troubleshooting already attempted
The problem still returns shortly after launch, so rebooting does not resolve it.
Expected behavior
The desktop app should remain running rather than repeatedly entering the crash/restart screen. It would also help if this screen exposed a crash ID or diagnostic bundle that users could submit.
Local usernames, project paths, and notification-command paths have been omitted for privacy. A screenshot of the crash page is available if maintainers need it.