codex - 💡(How to fix) Fix Codex Desktop becomes unrecoverable on launch when the most recent session rollout exceeds ~500 MB [1 comments, 2 participants]

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

26.422.8496.0_x64

What subscription do you have?

GPT PRO

What platform is your computer?

Windows 11 Pro 26200

What issue are you seeing?

A long-running agent task (~20 hours, ~3,300 turns) on a moderately heavy repository produced a single rollout JSONL file of 718.6 MB / 3,305 lines (avg ~222 KB per line). After the agent loop deadlocked mid-tool-call and the unresponsive process was force-quit, every subsequent launch of Codex Desktop entered a non-recoverable freeze: the renderer process holds Responding=False while CPU pegs at ~140% of one core and working-set memory grows by ~1 GB every 10 seconds — apparently while attempting to auto-resume the oversized session.

Root cause appears to be an unbounded function_call_output size in the rollout JSONL: tool stdout (rg matches, Read of multi-MB JSON files, build/test stdout) is written verbatim, so a single line can be tens of MB. The auto-resume code path then attempts to deserialize the full file into the renderer's state on launch, which is unrecoverable past a few hundred MB.

What steps can reproduce the bug?

1. Open Codex Desktop in a workspace where:
   • Read of common data files produces multi-MB tool outputs
   • Aggressive rg queries match across many files
2. Start a long agent task and let it run unattended for many hours / hundreds of turns. (In our case the task spawned subagents that themselves performed expensive searches, compounding output volume.)
3. The agent loop eventually deadlocks mid-tool-call — no new events are written to the rollout JSONL, but the renderer process remains alive with Responding=False.
4. Force-quit Codex Desktop.
5. Relaunch Codex Desktop.

What is the expected behavior?

The app should launch and remain responsive even if the most recent session is unusually large. Acceptable approaches:

• Lazy / incremental loading of session history (render the latest N turns, stream older ones in).
• A startup size-threshold check that prompts the user ("Most recent session is 718 MB and may freeze the app. Resume anyway, or start a fresh session?") instead of silently auto-resuming.
• Silent fallback to a new session when the rollout exceeds a safe threshold.

Additional information

• The app window appears, then becomes unresponsive within a few seconds.

• The session is auto-resumed and the freeze persists across every subsequent launch — the user is locked out of the app entirely.

• A 10-second snapshot of the renderer process during the freeze:

  metric	T₀	T+10s	delta
  CPU (cumulative)	503.7 s	518.1 s	+14.4 s / 10 s ≈ 140% of one core
  Working set	1,089 MB	2,266 MB	+1,177 MB / 10 s
  Responding	False	False	—
  rollout jsonl LastWriteTime	26 min ago	26 min ago	(no new events)

  The agent loop is silent (no new turns being written), but the renderer is clearly burning resources in a tight loop — most likely while parsing or rendering the oversized session history.

1. The rollout JSONL was held with an exclusive write lock by the frozen process for the full duration of the freeze, even though the agent loop had stopped emitting new events 26 minutes earlier. (Verified via System.IO.File.Open failing with sharing violation, then succeeding immediately after the process was killed.) This suggests the agent-loop hang and the renderer hang are independent stuck paths inside the same process — which is consistent with the symptom that the process keeps consuming resources even though no new turns are being produced.
2. logs_2.sqlite-wal continued to receive small writes during the freeze, suggesting a background diagnostic logger remained active while the agent loop was deadlocked. The 2.4 GB size of logs_2.sqlite itself suggests there is no rollover policy on this DB.