[Windows Desktop 26.818.5345.0] Image Base64 bypasses read_thread output limits and repeatedly stalls recovery tasks

Summary

Codex Desktop on Windows repeatedly makes image-generating threads unrecoverable because full PNG Base64 remains inline in the rollout and is also returned by task-inspection APIs.

This workflow has now stalled three times. Two clean recovery threads were created without forking or reading the earlier image-heavy threads, but each recovery became unusable again after it generated images.

The newest recovery produced only 5 PNG files (6,098,757 bytes total on disk), yet its rollout grew to 33,133,290 bytes and its latest turns ended as interrupted. The thread is now idle with no assistant reply.

A particularly important additional repro is that read_thread(includeOutputs=false) still returns the full imageGeneration.result Base64 field.

Environment

• Codex Desktop MSIX: OpenAI.Codex_26.818.5345.0_x64__2p2nqsd0c76g0
• Bundled CLI: codex-cli 0.149.0
• Platform: Windows 11 x64, Microsoft Windows NT 10.0.26200.0
• Local project thread
• Image tool: built-in ImageGen

Repeated recovery timeline

1. An original UI-design thread generated images and became unresponsive.
2. A first diagnostic/recovery workflow was created. Its affected rollout reached 72,799,230 bytes.
3. A clean first recovery thread was created without reading/forking the old history. Its rollout reached 17,682,727 bytes.
4. A clean second recovery thread was created with explicit instructions never to read the old threads. It generated 5 PNGs and its rollout reached 33,133,290 bytes.
5. That second recovery then stalled while attempting the next image. The latest two turns are interrupted; the newest ran for 141 seconds and ended with no assistant message or tool marker.
6. A third clean migration is now required.

The clean recoveries did not inherit the previous task history. They reproduced the problem after new ImageGen calls, so the failure is not limited to reopening one already-corrupted thread.

Task-inspection evidence

Reading only the latest turns of the affected thread produced unexpectedly huge responses:

includeOutputs=true

Request shape:

read_thread(
  turnLimit=10,
  includeOutputs=true,
  maxOutputCharsPerItem=16000
)

Observed result:

Warning: truncated output
original token count: 2,129,388

The response contained complete PNG Base64 in imageGeneration.result, despite the generated image already having a separate savedPath.

includeOutputs=false

Request shape:

read_thread(
  turnLimit=4,
  includeOutputs=false,
  maxOutputCharsPerItem=4000
)

Observed result:

Warning: truncated output
original token count: 391,951

The response still contained the complete imageGeneration.result Base64. Therefore includeOutputs=false and maxOutputCharsPerItem do not protect callers from image payloads.

Steps to reproduce

1. Start a new local Codex Desktop task on Windows.
2. Generate and save several PNG UI mockups with built-in ImageGen.
3. Continue the task for a few turns. In this case, only 5 generated images were enough for the task to become unreliable.
4. Inspect the rollout JSONL and confirm full PNG Base64 is stored inline in image-generation records while the PNG also exists under the generated-images directory.
5. Call read_thread for recent turns with includeOutputs=false and a small maxOutputCharsPerItem.
6. Observe that the response still includes the complete imageGeneration.result Base64 and becomes hundreds of thousands of tokens.
7. Continue or resume the affected task.
8. Observe long-running turns ending as interrupted, eventually leaving the task idle without a reply.
9. Create a clean migration task that does not fork or read the affected history, generate several new images, and observe the problem recur.

Expected behavior

• Generated image bytes should be externalized and referenced by asset ID, hash, or savedPath, rather than duplicated inline in rollout history.
• read_thread(includeOutputs=false) must omit binary/image payloads.
• maxOutputCharsPerItem should cap or replace oversized imageGeneration.result fields.
• Resuming a thread should not hydrate all historical image Base64 into model or UI context.
• Codex should warn when a task becomes image-heavy and provide a built-in compact/repair path.
• A task should remain usable after several generated images.

Actual behavior

• Full PNG Base64 is retained inline even after the image is saved separately.
• Task inspection returns the Base64 even when outputs are explicitly disabled.
• A thread with only 5 generated PNGs can grow to tens of MB and later end turns as interrupted.
• Clean recovery tasks reproduce the issue, forcing repeated migrations and losing continuity.

Suggested fixes

1. Store generated image data in a blob/asset store and keep only metadata plus savedPath/asset ID in rollout JSONL.
2. Make includeOutputs=false remove imageGeneration.result and any nested data URLs.
3. Apply maxOutputCharsPerItem recursively to tool and image-generation result fields.
4. Deduplicate image bytes across response items, event messages, and compaction records.
5. Add a built-in “compact image payloads” repair action for existing tasks.
6. Add regression coverage for repeated ImageGen calls followed by read_thread(includeOutputs=false).

Related issues

• #22603 — image-heavy rollout embeds generated image payloads inline
• #24676 — Windows Desktop hangs on an image-heavy rollout
• #34863 — repeated inline PNG data in compacted records causes extreme rollout and memory growth
• #21948 — large active session causes global freezes

This report adds a current Windows version, a small-image-count reproduction, repeated failure across clean recovery tasks, and the read_thread(includeOutputs=false) payload leak.

Privacy note

The raw rollouts, prompts, local paths, thread IDs, and generated images contain private project data and are intentionally omitted. Sanitized sizes, statuses, and API behavior are included above.