Codex App reopening some threads stalls because `thread/resume` returns oversized image-heavy payloads

What version of the Codex App are you using (From "About Codex" dialog)?

26.601.21317

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.19044.0 x64

What issue are you seeing?

Reopening some existing threads in the Codex App stalls noticeably. The backend appears to return very large thread/resume payloads when the rollout contains inline base64 image data.

What steps can reproduce the bug?

1. Reopen a thread whose rollout contains inline image data.
2. Observe a noticeable stall before the thread is usable.

Measured against the installed app-server:

• thread/resume on large image-heavy rollouts returned about 7-20MB responses and took about 1.2-1.7s in backend time
• the same calls with excludeTurns: true returned tiny responses and avoided the payload blow-up

Example local rollout sizes observed:

• about 55.3MB
• about 36.3MB
• about 28.8MB

The large files contained data:image/png;base64,... inline content.

What is the expected behavior?

Reopening a thread should not require transporting and parsing multi-megabyte history payloads up front just to restore the thread shell.

Additional information

Relevant path:

• codex-rs/core/src/session/mod.rs and the surrounding resume flow still hydrate full history for normal resume.
• The app-server protocol already has cheaper resume options such as excludeTurns, but the current reopen behavior appears to pay for full history transfer in image-heavy threads.

Why this is expensive:

• Rollouts can contain inline data:image/png;base64,... content.
• When that history is sent in the initial thread/resume response, the frontend has to transport, parse, and render very large JSON payloads before the thread is usable.

Likely fix directions:

1. Use metadata-only resume first for initial open.

• Prefer excludeTurns: true or an equivalent metadata-first path.

1. Lazy-load turns/items after the shell is already open.
2. Add paging or truncation for image-heavy history so the initial resume response does not include unnecessary inline base64 content.

Notes from investigation:

• thread/list itself was comparatively fast and small, so this does not look like a generic thread-listing problem.
• The payload-size difference between normal resume and excludeTurns: true was much larger than the backend time difference, which suggests frontend JSON transport/parsing/rendering cost is likely a major part of the perceived freeze.