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

[starmiaoa]

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:

• Codex App freezes / becomes Not Responding when opening image-heavy projects with many generated images #21232
• # Codex desktop main-process crash: RangeError: Invalid string length when loading sessions whose rollout JSONL exceeds V8's max string length #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.

[github-actions]

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

• Desktop compaction repeatedly embeds full image base64 in compacted checkpoints #23257
• Codex App crashes when reopening an existing conversation with extensive ImageGen usage #24318
• Codex Desktop: proactive handoff and rescue workflow for unrecoverable remote compaction failures #24100
• Codex remote compaction deadlocks when input_image payloads remain in compacted replacement history #24388
• Responses WebSocket falls back when compacted replacement_history contains large inline images #24550

Powered by Codex Action

[VVittgenstein]

Adding a fresh Windows repro on a newer Store build. This looks like the same image-heavy rollout/session class, with one extra amplification detail: compaction can retain inline image data inside replacement_history.

Environment:

• Codex Desktop Store package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• App executable path class: C:\Program Files\WindowsApps\OpenAI.Codex_<version>_x64__2p2nqsd0c76g0\app\Codex.exe
• Platform: Windows x64
• Date observed: 2026-06-01 local time

Observed:

• Codex Desktop repeatedly became slow / stuck / Windows "Not Responding" around image-heavy threads.
• Quarantining large rollout JSONL files out of %USERPROFILE%\.codex\sessions restored responsiveness.
• The latest repro rollout was only 102.44 MB, smaller than my previous ~183 MB case, but still problematic enough to require external cleanup.

Sanitized stats from the latest rollout:

File size:                    102.44 MB
JSONL lines:                  982
Lines > 1 MB:                 17
Lines > 5 MB:                 7
Lines containing data:image:  31
Bytes in image-containing lines: 100.37 MB
data:image URI occurrences:   51
Unique image data URIs:       34
Total data:image URI bytes:   100.26 MB
response_item user image lines: 14
event_msg user_message image lines: 14
compacted records:            2
bytes in compacted records:   24.74 MB
largest single record:        24.207 MB compacted record with 16 image refs

Largest records:

Line 757: compacted, 24.207 MB, 16 image refs
Line 403: event_msg/user_message, 6.486 MB, 1 image ref
Line 402: response_item/message, 6.486 MB, 1 image ref
Line 393: response_item/message, 6.403 MB, 1 image ref
Line 394: event_msg/user_message, 6.403 MB, 1 image ref
Line 675: event_msg/user_message, 6.121 MB, 1 image ref
Line 674: response_item/message, 6.121 MB, 1 image ref

Important isolation detail:

• The file was not large because of ordinary text.
• Almost the entire file size was inline base64 image data.
• The same user-provided screenshots appear to be persisted in both response_item and event_msg forms.
• The compacted event can then carry prior image-heavy history again inside payload.replacement_history; in this repro, one compacted line alone was 24.207 MB.
• After quarantining the rollout file, %USERPROFILE%\.codex\session_index.jsonl still contained stale entries for the quarantined thread id. Removing those stale index lines after backing up the index prevents the sidebar/thread list from retaining entries for missing dangerous rollouts.

Suggested fixes / guards:

• Do not store raw image bytes as inline data:image strings in durable rollout JSONL when a file/blob reference or content hash would work.
• Do not include raw image data in compacted.payload.replacement_history; retain lightweight references or placeholders.
• Avoid duplicating the same image payload across response_item and event_msg records, or apply a per-record/per-field byte cap before persistence.
• Keep sidebar/thread-list state metadata-only and avoid loading image-heavy turns unless the user explicitly opens/expands them.
• Add a built-in repair/archive flow for oversized or image-heavy sessions so users do not need to manually move JSONL files and edit session_index.jsonl.

Privacy note: I am intentionally not uploading the raw rollout, screenshots, sqlite databases, or unsanitized logs because they contain private conversation/image data.