macOS Desktop: image-heavy thread takes minutes to open because rollout JSONL embeds generated image payloads inline

What version of the Codex App are you using?

Codex Desktop 26.506.31421 on macOS. App bundle:

• CFBundleShortVersionString: 26.506.31421
• CFBundleVersion: 2620
• Bundle ID: com.openai.codex
• Session meta in rollout: cli_version: 0.130.0-alpha.5, originator: Codex Desktop

What platform is your computer?

macOS 26.5 (25F71), Apple Silicon / arm64.

What issue are you seeing?

Opening one Codex Desktop thread for a local repo with many generated images made the Desktop app appear to crash or become unresponsive. It eventually opened after several minutes, but the thread was heavy enough that normal Desktop use became painful.

Local diagnosis shows the session trace stores full image bytes inline, even though the generated image files are also written separately under ~/.codex/generated_images/.

Measured local data for the affected thread:

• ~/.codex/sessions/2026/05/11/rollout-<thread-id>.jsonl: 747 MB
• JSONL record count: 2,164
• Matching ~/.codex/generated_images/<thread-id>/: 82 PNG files, 240 MB
• 82 generated images appear to be stored twice in the JSONL: once as event_msg / payload.type == image_generation_end, and once as response_item / payload.type == image_generation_call
• 164 JSONL records contain multi-megabyte payload.result base64 PNG strings
• 35 additional function_call_output records contained embedded input_image.image_url: data:image/...;base64 payloads
• 191 JSONL lines were larger than 1 MB; the oversized lines accounted for most of the rollout file

Manual recovery confirmed the root cause. Redacting only embedded image payloads while preserving all JSONL records and metadata reduced the rollout file from 747 MB to 2.3 MB:

• replace payload.result for image_generation_end / image_generation_call with a short placeholder
• replace nested image_url values beginning with data:image/ with a short placeholder
• keep saved_path, call ids, prompts, timestamps, and all other metadata intact
• validate JSONL with jq -e .

After this trim, the file still had the same 2,164 records and no JSONL line above 1 MB.

This looks related to, but not exactly the same observed platform, as:

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

I am filing this as a macOS Desktop datapoint with exact local measurements. Feel free to close as duplicate if the intended fix is tracked elsewhere.

Steps to reproduce

1. Use Codex Desktop on macOS.
2. In one thread, generate dozens of images, enough to create many records with payload.type == image_generation_end and payload.type == image_generation_call.
3. Confirm the rollout JSONL grows into hundreds of MB because generated images are embedded as base64 in payload.result while also being saved under ~/.codex/generated_images/<thread-id>/.
4. Close/reopen Codex Desktop or select that thread.
5. Observe that opening the thread can freeze/hang the Desktop UI for minutes or make it appear to crash.

Expected behavior

Codex Desktop should stay responsive when opening image-heavy threads. Generated image bytes should not be duplicated inline in the session rollout if they are already stored as files, or the loader should lazy-load/stream/skip oversized binary payloads safely.

At minimum, Desktop should detect oversized image-heavy sessions, show a clear warning, and provide a built-in way to compact/trim embedded images without forcing users to manually edit ~/.codex/sessions.

Actual behavior

The Desktop app attempts to load/hydrate a hundreds-of-MB rollout file with many inline base64 image payloads, causing the UI to become unresponsive for minutes when opening the thread.

Privacy note

I intentionally omitted the raw rollout file, prompts, local username, full thread id, generated images, and repo contents from this public report. The important reproducible signal is the data shape and sizes above.