[Windows][26.825.5331.0] Codex Desktop closes during long/tool-heavy sessions while CLI remains stable

What version of the Codex App are you using?

Codex Desktop package: 26.825.5331.0 (Windows MSIX)
Codex CLI/runtime observed: 0.151.0-alpha.7.1
Model: gpt-5.6-sol

Subscription

ChatGPT Plus

Platform

Windows x64. Machine has 32 GB RAM.

Summary

Codex Desktop repeatedly closes during long/tool-heavy work on a larger local project. Small/simple sessions work, but after continuing a long conversation or doing heavier project work, the Desktop window/process closes abruptly.

The CLI remains usable on the same machine/workspace, which points toward a Desktop/Electron/renderer-side failure rather than the Codex CLI/runtime itself.

There was also a separate Windows elevated-sandbox provisioning problem. Switching the config to:

[windows]
sandbox = "unelevated"

made normal read/write operations work successfully in both CLI and Desktop, but did not fix the long-session Desktop closing problem. Therefore the sandbox provisioning issue and this Desktop crash appear to be separate failures.

Reproduction

1. Launch Codex Desktop on Windows.
2. Open a larger local coding project.
3. Start/continue a long conversation with multiple analysis/tool/file operations.
4. Continue working for a while.
5. Codex Desktop eventually closes abruptly.
6. Reopening it allows work to continue, but the problem can recur during longer/heavier sessions.

A small test workspace successfully created and read files without closing, so the failure is much easier to reproduce with longer/heavier project sessions.

Observations / diagnostics

• Windows sandbox config was verified to remain sandbox = "unelevated" when the later crashes occurred.
• Get-WinEvent filtering recent Application events for Codex/ChatGPT/OpenAI did not return a corresponding obvious crash event in the tested occurrence.
• Resource monitoring sampled the ChatGPT.exe and Codex processes once per second during reproduction.
• The heavier memory use was in ChatGPT.exe, not codex.exe.
• In one monitored run, the combined Desktop processes reached roughly 2+ GB private memory, with one ChatGPT.exe process around 1.3 GB private memory. codex.exe remained comparatively small (~85–140 MB range across tests).
• During monitoring, Desktop/ChatGPT processes disappeared/reappeared around the failure while Codex-related backend processes could remain present, consistent with a Desktop/renderer restart or termination rather than the backend being the primary failure.
• Machine has 32 GB RAM, so total system RAM exhaustion does not appear to explain the failure.

Session/history evidence

The local Codex session store contained 23 sessions totaling about 23.2 MB. One long session was a major outlier:

• largest rollout JSONL: ~14.8 MB
• second largest: ~1.56 MB
• third largest: ~1.09 MB

The large session alone represented roughly 64% of all session JSONL data. The Desktop config used:

[desktop]
conversationDetailMode = "STEPS_COMMANDS"

This initially suggested long transcript/rendered command history might be contributing. However, the Desktop continued closing after additional isolation attempts, so this report is not claiming the large thread is the sole cause.

Local DB sizes observed near reproduction included:

• logs_2.sqlite: ~20.05 MB
• logs_2.sqlite-wal: ~4.4 MB
• state_5.sqlite-wal: ~3.93 MB
• thread_history_1.sqlite-wal: ~1.39 MB

Separate elevated sandbox issue

Before isolating this Desktop crash, codex doctor/sandbox setup had Windows sandbox provisioning/ACL failures. Filesystem checks found no reparse points on the relevant user/Codex paths, helper executables existed and had valid OpenAI signatures, and the sandbox setup helper was observed launching with a valid Base64 payload.

Running Codex with windows.sandbox="unelevated" and workspace-write successfully created and read files in a normal user workspace. The Desktop also successfully performed the same small read/write test after changing the persistent config to unelevated.

The long/heavy-session Desktop closing still occurred afterward, so this issue focuses on the Desktop stability problem rather than the elevated sandbox failure.

Expected behavior

Codex Desktop should remain stable during long-running/tool-heavy coding sessions. Large transcript/history state should not cause the Desktop renderer/window to terminate. If renderer state becomes too large, the client should virtualize/compact history or recover without closing the user's working UI.

Actual behavior

The Codex Desktop UI closes abruptly during longer/heavier project sessions. The CLI/backend does not show comparable resource growth and can be used as a workaround.

Workaround

Use Codex CLI for heavy/long-running project work and keep Windows sandbox set to unelevated because of the separate elevated-sandbox provisioning issue.

Related reports

This appears potentially related to existing Windows Desktop renderer/session issues such as #37541, #37829, #38622, #41268, and other reports involving large active thread state / renderer instability.

I can provide additional process-monitor CSV data, Desktop logs, or run targeted diagnostics if maintainers need them.

No source file or test is named. Start by reproducing the long, tool-heavy session on Windows with the larger project while monitoring ChatGPT.exe and codex.exe, then inspect the available Desktop logs and session history around the closure. Done means the Desktop remains open through comparable sessions without renderer or window termination.