Codex Desktop threads become unreadable after multi-image generation embeds large payloads

Codex Desktop threads become unreadable after multi-image generation embeds large payloads

What version of the Codex App are you using?

Affected session metadata reports 0.155.0-alpha.2.6. The separately installed CLI currently reports codex-cli 0.153.4.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Two Codex Desktop tasks successfully generated multiple images, but afterward the task conversations became unreadable on both PC and phone. The tasks remain listed, but opening them fails. Other Codex tasks still load normally.

Attempting to read either affected task through the Codex task service returns:

tool call error: tool call failed for codex_app/read_thread

Caused by:
    Mcp error: -32000: MCP error -32000: Codex app tool request failed

The generations themselves completed successfully: all 35 PNGs were recovered locally and validate correctly. The local JSONL transcripts are unusually large because generated-image data appears to be embedded in the conversation records:

• Task A: 42,000,027 bytes after generating five images.
• Task B: 205,754,294 bytes after generating thirty images.

The affected tasks have not been deleted or modified.

What steps can reproduce the bug?

1. In Codex Desktop, start a task that requests several standalone images using the built-in image-generation workflow.
2. Generate multiple images in the same turn. One affected task generated five images concurrently; the other generated thirty images across the task.
3. Allow the task to finish normally.
4. Attempt to reopen the task in Codex Desktop or on mobile, or call codex_app/read_thread for its task ID.
5. The task fails to load even though it remains in the task list. codex_app/read_thread returns MCP -32000.

The transcript sizes are included above. Full task IDs are withheld from this public report and can be supplied privately to an OpenAI maintainer. The first failure correlated with the transcript containing embedded generated-image payloads.

What is the expected behavior?

Codex should store generated images as referenced artifacts rather than embedding payloads that make the conversation unreadable. Completed image-generation tasks should reopen normally on desktop and mobile, and codex_app/read_thread should return their history.

If a task exceeds a supported history or payload limit, Codex should preserve a readable paginated history and surface a specific recoverable error instead of making the whole task inaccessible.

Additional information

OpenAI Support reviewed these details and described the behavior as consistent with a stuck or oversized thread. The problem reproduces across devices, while other tasks on the same account load normally.

The raw transcripts are 42 MB and 206 MB and contain complete task content plus embedded image payloads, so they are not attached publicly. Sanitized excerpts can be supplied if maintainers identify the exact fields needed.

Start with the codex_app/read_thread entry point and the JSONL transcript handling mentioned in the report, then trace how embedded generated-image payloads are read. Done means multi-image tasks remain readable on desktop and mobile, read_thread returns their history, and oversized payloads produce a recoverable error instead of blocking the thread.