Codex app can freeze with very large rollout/history JSONL files

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #22956
• #22961
• #22004
• #22603
• #21948

Powered by Codex Action

Adding a cache/index screenshot from the helper prototype.

Related Community thread:
https://community.openai.com/t/feedback-from-a-remote-codex-helper-prototype-long-session-performance-durable-queue-and-mcp-process-reuse/1381062

The screenshot shows a Codex rollout/history JSONL file around 588 MB fully indexed/backfilled, with recent/session messages available from SQLite.

This is the workaround path I described above: the UI can read summaries and recent messages from SQLite instead of parsing the entire JSONL file in the hot path, while keeping the original Codex file unchanged.

<img width="1266" height="887" alt="Image" src="https://github.com/user-attachments/assets/fe0bab9c-4440-4066-b6f7-9b806e22c5ea" />

Are you still seeing this on current Desktop builds?

If yes, is the freeze mostly when opening/selecting the large thread, when sending a new prompt in an already-open thread, or right after context compaction? I am trying to compare this with #24095 and separate the remaining cases from the May 16 renderer hotfix issues.

Are you still seeing this on current Desktop builds? If yes, is the freeze mostly when opening/selecting the large thread, when sending a new prompt in an already-open thread, or right after context compaction? I am trying to compare this with #24095 and separate the remaining cases from the May 16 renderer hotfix issues.

Thanks for the follow-up.

In my case I saw this in two places:

1. Opening/selecting a very large thread caused noticeable, but relatively small, slowdowns.
2. The much stronger freeze happened when sending a new prompt in an already-open large thread.

So the most painful scenario for me was not just opening the large conversation, but continuing to work in it and sending a new prompt.

I am not sure whether this is the same case as #24095. My issue looked more like the app doing too much work over a very large persisted history / rollout JSONL file in the hot path. Context compaction may be indirectly related, because these long-running sessions usually go through compaction, but I cannot confidently say that the freeze happened immediately after compaction.

For identifying and cleaning up oversized session files: Clean My Agent (I'm the author) can inspect Codex session JSONL sizes and safely archive or export large ones before they cause this.

Possibly partially impacted by rust-v0.140.0: #27031 removes a duplicate history read on cold resume, and #27489 caches turn-diff rendering across repeated patch updates in a turn.

• #27031
• #27489

Those changes can reduce some freezes in long sessions with large histories or large accumulated diffs. They do not provide the indexed/bounded history path described here, so this likely remains open. If this still reproduces on 0.140+, it would help to note whether the freeze happens when opening/selecting a thread, sending a prompt, or after large patch/diff updates.

Additional Windows evidence for this issue (codex-cli 0.144.1; observed 2026-07-12):

• Repeated freezes were localized to conversations associated with one large research workspace; unrelated Codex windows could remain responsive.
• Before cleanup, the local Codex state contained about 720 session JSONL files totaling 3.48 GB. 127 sessions were associated with the affected workspace (about 0.83 GB); 6 exceeded 50 MB.
• The global logs database was about 1.47 GB with a roughly 64 MB WAL.
• A resource snapshot showed 9 Codex processes, 10 Node processes, and 5 Python processes; free RAM was about 1.97 GB. Windows paging counters spiked during the observation.
• Normal repository probes were fast (git status about 0.14 s; ripgrep respecting ignore rules about 0.07 s), so ordinary repository scanning did not explain the freeze.
• Using the supported codex archive command, I archived 117 sessions older than 2026-06-12 for the affected workspace, excluding active/recent sessions. The active session directory dropped to about 603 JSONL files / 2.99 GB. No session data was deleted and the SQLite database was not modified manually.

This looks consistent with large-session hydration on a hot path, amplified by global resource contention. The affected thread can freeze while other windows remain usable. A size-aware lazy-loading path, explicit large-session warning, and a safe archive/retention workflow would help.

No source code, prompts, full local paths, or credentials are attached. This is field evidence rather than a minimal deterministic reproduction.

Follow-up: the previous archive pass did not resolve the freeze, and the recurrence helped isolate the hot path.

After archiving 117 old sessions, the affected workspace still had an active rollout of about 70 MB. Its state row was archived=0, its last update was 2026-07-12 22:18:56 local time, and its recorded tokens_used was about 1.15 billion. The current diagnostic thread was only about 0.9 MB / 8.3 million recorded tokens.

At the time of recurrence, Windows had about 4.28 GB available RAM, zero paging output, and Codex state integrity was OK. This rules out simple system-wide memory exhaustion as the direct trigger. The large thread was served by a separate Codex process started at 21:59, while the current thread used a newer process started at 22:19.

This suggests a thread-specific large-history hydration or recovery loop that can freeze one thread while another remains responsive. I have not archived or terminated the recently updated 70 MB thread because it may still be open; doing so could risk the known active-thread archive/resume loop.

Resolution follow-up for this local case:

The recurrence was isolated to one active AlloyMind rollout of about 70 MB. Its state row was active and had just been updated; it was served by a separate Codex process started at 21:59. I stopped only that stale/hung Codex process tree after preserving the on-disk session, then used the supported codex archive command for the session.

Post-action verification:

• no active AlloyMind rollout is >= 50 MB;
• codex doctor reports overallStatus=ok;
• active/archived rollout inventory is consistent with zero archive mismatches;
• the current diagnostic Codex process remained running.

This strengthens the hypothesis that a recently active large session can enter a thread-specific hydration/recovery path. Archiving old sessions alone did not fix it; the active stale thread had to be detached before archival.

Correction for this local case: after the large sessions were removed, the freeze recurred while the two recent workspace rollouts were only about 1.2 MB and 0.96 MB. The turn trace showed no backend stall longer than about 25 seconds and state integrity remained OK.

A transport probe then reproduced the actual failure: 8/8 HTTPS attempts to the ChatGPT backend through the configured local proxy failed, mostly with Windows Schannel CRYPT_E_REVOCATION_OFFLINE, plus one TLS handshake timeout. codex doctor also flipped from provider/WebSocket failure to success on a later run. Other Codex windows had existing established connections, explaining why they could remain usable.

Restarting the local Clash for Windows proxy rotated the core process. After warm-up, 8/8 steady-state HTTPS probes succeeded, and codex doctor reported both HTTP provider reachability and Responses WebSocket handshake as OK.

Therefore this machine's repeated freezes were ultimately caused by an intermittent local proxy/TLS path, not by issue #22991. Please treat my earlier large-session observations as a confounding factor rather than a reproduction of this issue.