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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   performance

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on May 16, 2026
2. github-actions commented on May 16, 2026

   

   github-actionsBot

   on May 16, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Long conversations cannot be opened at all after updating the OpenAI Windows desktop app, urgent fix needed! #22956
   • Codex Desktop session can become unusable after large Git output #22961
   • # Codex desktop main-process crash: RangeError: Invalid string length when loading sessions whose rollout JSONL exceeds V8's max string length #22004
   • macOS Desktop: image-heavy thread takes minutes to open because rollout JSONL embeds generated image payloads inline #22603
   • Large active session causes global freezes with no UI attribution #21948

   Powered by Codex Action
3. Deniskoyyy commented on May 16, 2026

   

   Deniskoyyy

   on May 16, 2026

   Author

   More actions

   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.

   
4. Herrtian commented on May 22, 2026

   

   Herrtian

   on May 22, 2026

   More actions

   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.
5. Deniskoyyy commented on May 29, 2026

   

   Deniskoyyy

   on May 29, 2026

   Author

   More actions

   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.
6. blain3white commented on Jun 9, 2026

   

   blain3white

   on Jun 9, 2026

   More actions

   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.
7. 0xdevalias commented on Jun 17, 2026

   

   0xdevalias

   on Jun 17, 2026

   More actions

   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.

   • Avoid rereading rollout history during cold resume #27031
   • core: cache turn diff rendering #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.
8. hanhan761 commented on Jul 12, 2026

   

   hanhan761

   on Jul 12, 2026

   More actions

   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.
9. hanhan761 commented on Jul 12, 2026

   

   hanhan761

   on Jul 12, 2026

   More actions

   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.
10. hanhan761 commented on Jul 12, 2026

    

    hanhan761

    on Jul 12, 2026

    More actions

    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.
11. hanhan761 commented on Jul 12, 2026

    

    hanhan761

    on Jul 12, 2026

    More actions

    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.
12. NicolayBang commented on Aug 4, 2026

    

    NicolayBang

    on Aug 4, 2026 – with ChatGPT Codex Connector

    Last edited by NicolayBang

    More actions

    I can reproduce this on Windows with a single long-running session whose rollout JSONL reached 3,567,436,125 bytes (approximately 3.32 GiB).

    There appear to be two related but distinct behaviors.

    Desktop app behavior

    • The freeze can affect the whole Windows system, including mouse input, rather than only making the Codex window unresponsive.
    • Task Manager does not always show an obvious CPU or memory spike when the freeze occurs.
    • Several Codex processes and child processes are visible during the problem. Some may be expected for the desktop app architecture, but the process count appears duplicated or excessive when this happens.
    • The GUI application's memory usage appears to grow over time, suggesting a possible memory leak or retained session data.
    • I have not observed this ongoing memory-growth and system-wide-freeze pattern during normal CLI use.

    Affected session

    • Opening the oversized thread in the desktop app triggers the problem.
    • Directly resuming this specific oversized session from the CLI does not recover it, but normal CLI sessions do not exhibit the GUI's broader system-freeze behavior.
    • Fresh and smaller threads continue to open and run normally.
    • Automatic context compaction occurred during the thread's lifetime but did not prevent the durable rollout file from reaching this size.
    • The final JSONL record parses successfully, so the file does not appear obviously truncated.

    I am not attaching the raw rollout because it contains private conversation and tool output. This also appears related to #22004, although the visible desktop symptom here is an indefinite system-wide stall rather than an explicit RangeError.
13. boombx403-byte commented on Aug 18, 2026

    

    boombx403-byte

    on Aug 18, 2026

    More actions

    Hi @Deniskoyyy, regarding the missing tool output / unfinished call state in the transcript, Codex Rescue Alpha5 has bounded tool-correlation diagnostics to detect persisted correlation anomalies and incomplete turn boundaries without assuming non-execution.

    To inspect the rollout locally and safely in read-only mode:

    pip install codex-rescue==0.1.0a5
    codex-rescue doctor <path-to-rollout.jsonl>

    No private files need to be uploaded; please sanitize any repository details before sharing diagnostic output.
14. scraptechindustries commented on Sep 2, 2026

    

    scraptechindustries

    on Sep 2, 2026

    More actions

    Independent Windows reproduction of the same large-history renderer failure, with
    a smaller rollout and detailed record/pagination measurements.

    Environment

    • Windows 11 25H2, build 26200.9168, x64
    • Codex Desktop 26.814.5167.0

    What happened

    A long-running text task became progressively laggy and then unusable in the
    desktop UI. Its final turn completed normally, the backend became idle, and a
    bounded read-only task query still worked. Only the desktop task view was unusable.

    Sanitized measurements

    • Valid rollout JSONL: 277,136,936 bytes (264.3 MiB)
    • Records: 61,319
    • Compactions: 90
    • Largest record: 8,222,229 characters
    • Exec outputs larger than 1 MiB: 17
    • Exec outputs larger than 100 KiB: 51
    • One cold load issued exactly 129 five-turn page requests for 641 started turns
    • Average history-request duration: 1,895 ms; maximum: 2,541 ms
    • The load window contained 53 ResizeObserver errors and 17
      unknown-conversation notices, but zero Conversation state not found and zero
      Item not found errors
    • Available RAM was about 18.9 GiB, disk activity about 4.7%, and CPU was low

    The final turn added only about 0.16 MiB. This case shows that the practical failure
    can occur well below 500 MiB and may depend on record shape, oversized tool outputs,
    turn count, compactions and renderer layout work—not byte size alone.

    Expected behavior

    • Hydrate and render old history lazily or virtually.
    • Cap or externalize raw tool output before it enters the hot renderer path.
    • Keep history loading cancellable and isolate one oversized task from the rest of
      the desktop app.
    • Provide a supported compact/recovery view instead of requiring users to abandon a
      valid task.

    Privacy

    No task ID, transcript, project name, local path, raw log or screenshot is included.
    Aggregate statistics and reviewed excerpts can be provided privately.