Issue draft for openai/codex

Title

Codex Desktop hangs when opening an image-heavy session rollout (~183 MB, huge inline image_url records), and the thread becomes hard to recover from the sidebar

Body

What version of the Codex App are you using?

OpenAI Codex Desktop, Microsoft Store install:

• Package: OpenAI.Codex
• Version: 26.519.5221.0
• Package full name: OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0
• Install location pattern: C:\Program Files\WindowsApps\OpenAI.Codex_<version>_x64__2p2nqsd0c76g0\

What platform is your computer?

Windows 11 x64

• Microsoft Windows NT 10.0.26200.0 x64

What subscription do you have?

plus

What issue are you seeing?

Codex Desktop can become extremely slow or fully "Not Responding" when opening a long, image-heavy local thread whose rollout JSONL contains large inline image payloads.

This is related to image-heavy-session issues such as:

• https://github.com/openai/codex/issues/21232
• https://github.com/openai/codex/issues/22004

However, my case reproduced well below the ~512 MB V8 string-limit crash described in #22004. The problematic rollout was about 183 MB on disk, but still made the app/UI effectively unusable when the thread was selected. The thread also became difficult to recover from the sidebar after manually moving/slimming the rollout and restoring the index.

Local evidence

Problematic session rollout:

C:\Users\<user>\.codex\sessions\2026\05\18\rollout-2026-05-18T18-03-42-<thread-id>.jsonl

Original file stats before mitigation:

File size:             182.8 MB
Lines:                 41,361
Total chars:           188,255,915
Max single JSONL line: 6,850,815 chars
Lines > 20k chars:     1,205
Lines > 100k chars:    88
Lines > 500k chars:    19
Lines > 1m chars:      14
JSON parse errors:     0

Largest records were response_item / event_msg records containing inline image data:

Line 24062: response_item, 6,850,815 chars
  $.payload.content[5].image_url length: 2,561,406
  $.payload.content[2].image_url length: 2,128,902

Line 24063: event_msg, 6,849,389 chars
  $.payload.images[1] length: 2,561,406
  $.payload.images[0] length: 2,128,902

Line 9126: response_item, 5,086,077 chars
  $.payload.content[2].image_url length: 5,085,746

Line 9127: event_msg, 5,085,951 chars
  $.payload.images[0] length: 5,085,746

The issue is not that ordinary text was too long. The heavy records were mainly base64/data-URL image strings stored inline in the JSONL.

Observed behavior

1. The machine became extremely sluggish and many windows showed "Not Responding" while Codex was open or when selecting this thread.
2. Opening/clicking the image-heavy thread could freeze the Codex Desktop UI for minutes.
3. After moving the rollout out of ~\.codex\sessions and editing session_index.jsonl, Codex became responsive again.
4. After creating a slimmed copy of the rollout, restoring the index, and even creating a cloned recovery thread with a new id/title, the thread still did not reliably show up in the desktop sidebar. The local files and session_index.jsonl entries existed, but the UI did not surface the thread as expected.

Mitigation I used locally

To recover the app, I had to manually:

1. Move/quarantine the original 183 MB rollout.
2. Edit C:\Users\<user>\.codex\session_index.jsonl to remove or restore matching entries.
3. Create a slimmed rollout where large inline image fields were replaced with a small placeholder.
4. Prune older detailed records while keeping a recent compacted summary and recent records.

After replacing large inline images and pruning old records:

Slimmed file size:     41.43 MB
Lines:                 16,670
Max single JSONL line: 78,692 chars
Lines > 100k chars:    0

This made the underlying local data much less dangerous, but the thread still could not reliably be recovered from the sidebar.

Expected behavior

Codex Desktop should remain responsive when a local session contains many images or large image payloads.

At minimum:

1. Opening a thread should not parse/render all inline image payloads synchronously on the UI path.
2. Very large image_url / payload.images strings should be lazy-loaded, omitted from sidebar/preview computation, or replaced with lightweight references.
3. The app should not embed full image bytes into the rollout JSONL if the images are already available elsewhere; the rollout should store file paths/content hashes instead.
4. If a rollout is too large or malformed for the UI to load safely, Codex should show a recoverable error for that one thread, not make the whole app unresponsive.
5. The sidebar/session index should have a robust recovery path after a user manually quarantines or slims a problematic rollout.

Why this matters

This can make a user's long-running thread unrecoverable from the UI even though the local session data still exists on disk. In my case, the practical workaround was to manually extract a textual summary from the JSONL and move to a new thread.

Suggested fixes

• Do not inline base64/data-URL image bytes in rollout JSONL; store references to generated image files instead.
• Stream-parse JSONL records and avoid building/rendering huge strings on the Electron UI path.
• Apply hard caps to image_url / payload.images fields before sending records to the renderer.
• Use virtualized rendering for history items and lazy-load old image-heavy turns only when expanded.
• Add a built-in "repair/export summary" flow for sessions that are too large to open.
• Add a warning when a rollout exceeds a threshold such as 50 MB / 100 MB / 250 MB.

Additional notes

I can provide exact sanitized stats and the PowerShell scripts used to identify the large records, but I cannot upload the raw rollout because it contains private conversation history and image data.

Optional comment for an existing issue

This may be a useful data point for #21232 / #22004:

I reproduced a similar Codex Desktop freeze on Windows with a rollout that was only ~183 MB, well below the ~512 MB V8 string-limit crash case. The file contained 41k JSONL records and 14 individual lines over 1 million characters. The largest records were response_item / event_msg entries containing inline image_url / payload.images strings, with single image strings up to ~5.1 million characters.

After replacing large inline image fields and pruning old records, the rollout dropped to 41.43 MB and max line length dropped to 78,692 chars. This made the local data safer, but the thread still did not reliably reappear in the desktop sidebar even after restoring session_index.jsonl entries and adding a cloned recovery thread. So there may be two related issues:

1. image-heavy rollouts can freeze/hang the app before the 512 MB hard crash threshold, and
2. sidebar/session recovery is fragile after a user manually quarantines or slims a problematic rollout.