[Windows][26.818.5229.0] Codex Desktop silently exits during normal work; no WER/crash event; reboot temporarily fixes it

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.5229.0

What subscription do you have?

ChatGPT subscription

What platform is your computer?

Windows 10 Pro, 10.0.19045, x64

Hardware:

• Intel Core i5-13400F
• 32 GB RAM
• NVIDIA GeForce RTX 5060 Ti
• NVIDIA driver 32.0.16.1088

What issue are you seeing?

Codex Desktop for Windows periodically exits completely during normal coding work without showing any error.

The window simply disappears. I have observed two variants:

1. Sometimes ChatGPT/Codex background processes remain alive after the window disappears.
2. Other times all ChatGPT.exe and codex.exe processes terminate completely.

In the second case, Windows does not record an Application Error, Application Hang, Windows Error Reporting event, relevant GPU/display-driver error, or crash dump.

A particularly problematic state sometimes follows the first silent exit: launching Codex again causes it to open and silently terminate again within a few seconds. This can repeat on every launch. Rebooting Windows consistently restores normal operation temporarily.

One recent clean reproduction:

• Windows reboot: ~13:02 local time
• Codex worked normally for ~37 minutes
• Silent exit: ~13:39
• ChatGPT.exe processes after exit: 0
• codex.exe processes after exit: 0
• Windows Application Error / WER events: none
• Relevant Display / NVIDIA GPU errors: none
• RAM at failure: ~15 GB free out of 32 GB

This occurs during normal agentic coding work involving local file edits, tests, PowerShell commands, and project operations.

What steps can reproduce the bug?

The exact trigger is not deterministic, but the recurring pattern is:

1. Reboot Windows.
2. Start Codex Desktop.
3. Open an existing local project/thread.
4. Work normally for some time with file edits/tests/tools.
5. Codex window suddenly disappears with no error dialog.
6. Sometimes background processes remain; other times all ChatGPT/Codex processes terminate.
7. Relaunch Codex.
8. In some cases it now exits again within a few seconds on every launch.
9. Reboot Windows.
10. Codex works normally again temporarily.

What is the expected behavior?

Codex Desktop should remain running during normal coding work.

If a fatal internal error occurs, it should generate a crash report/dump, log the reason for shutdown, or display a recoverable error. It should not silently terminate with no Windows crash event and then repeatedly terminate on subsequent launches until Windows is rebooted.

Troubleshooting already performed

I tested the following without eliminating the silent exits:

• clean Windows reboot
• reinstall/update of Codex previously
• sandbox = "elevated"
• sandbox = "unelevated"
• recreating bundled plugin marketplace caches
• recreating plugins/cache
• disabling the bundled Browser plugin
• restoring the original configuration afterward
• reducing an abnormally large .codex session store

Rebooting Windows remains the only reliable temporary recovery once Codex enters the state where it exits a few seconds after every launch.

Separate session/compaction issue discovered during debugging

During diagnosis I also found a separate serious local-session growth issue.

Previously %USERPROFILE%\.codex had grown to about 136 GB. Individual rollout JSONL files included approximately:

• 25.92 GB
• 25.25 GB
• 13.04 GB
• 11.39 GB
• several around 5.4 GB

Analysis of the largest 25.92 GB rollout showed approximately 25.77 GB consisted of compacted records.

The largest individual compacted record was about 80.39 MB with replacement_history count 591. Approximate classified contents of that single record were:

• image/base64: 80.18 MB (120 elements)
• user-like data: 140.63 KB (462 elements)
• subagent/agent: 33.75 KB
• other: 39.88 KB

So nearly the entire compaction snapshot was repeated image/base64 data inside replacement_history.

For local testing, after backing up the original rollout files, I removed obsolete historical compacted records while preserving the latest compacted record and all non-compacted JSONL records.

Example result:

25.92 GB -> 225.51 MB

After applying the same repair to the other abnormally large rollout files:

• .codex decreased from ~136 GB to ~7 GB
• old project threads still opened
• project files were intact
• disk activity dropped dramatically
• RAM when opening an old large thread dropped from ~18.7 GB to roughly 1.5–2 GB

However, the silent Codex Desktop exits still occur even after the session store was reduced to ~7 GB, so this appears to be a separate issue rather than the sole cause of the process exits.

Additional diagnostics

Observed package/runtime paths during debugging:

• Desktop package: OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0
• command runner: codex-command-runner-0.149.0-alpha.4.1.exe

Sandbox logs frequently show repeated launches of:

codex.exe --codex-run-as-fs-helper

followed by codex-windows-sandbox-setup.exe and ACL setup. There is a recurring warning about failing to hide C:\Users\Default with SetFileAttributesW ... error 5 (Access is denied), while setup itself reports errors=[] and successful read-ACL completion. Some startup silent exits occur before the sandbox log is updated, so I do not know whether the sandbox warning is related.

No relevant crash dump is created in %LOCALAPPDATA%\CrashDumps, and Windows Event Viewer repeatedly shows no matching Application Error/WER event at the time of the silent exits.

The only surviving process after some complete exits is a small crashpad_handler.exe process.

I can provide sanitized diagnostic reports or targeted log excerpts if maintainers indicate what would be most useful.

Related reports

This looks related to, but not necessarily identical with:

• #35560 — Windows desktop silently exits shortly after launch with no crash event
• #37752 — Windows desktop endless silent-exit loop; reboot/runtime state involved
• #31583 — Windows desktop AppX container silently destroyed/relaunched with no crash artifact
• #25779 — session/context bloat meta-issue

Start by comparing this report with related issues #35560, #37752, and #31583, then review the sandbox logs, %LOCALAPPDATA%\CrashDumps, and the listed package/runtime paths. Useful diagnostics should establish why the Windows desktop process exits without a WER event or dump and whether the recurring sandbox warning is related. Done means a reproducible cause and a verified non-silent failure or recovery path.