›_ Codex Issues
Codex Issues / #26352

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

Open 💬 5 comments Opened Jun 4, 2026 by hlky
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25163
  • #26161
  • #25779
  • #26299

Powered by Codex Action

100yenadmin · 2 months ago

Related implementation branches published from current main:

I could not open upstream PRs directly because GitHub returned GraphQL: 100yenadmin does not have the correct permissions to execute CreatePullRequest, but both branches are pushed to 100yenadmin/codex.

The lightweight branch makes the TUI request thread/resume with excludeTurns=true plus an initialTurnsPage, then replays that bounded page chronologically instead of consuming full thread.turns. It also exposes excludeTurns/initialTurnsPage in generated TS/JSON schemas so clients can use the documented cheap resume path.

The diagnostics branch is deliberately non-mutating. It logs resume payload shape for cold and running resumes: turn/item counts, estimated item payload bytes, item class distribution, image/user-image counts, tool-output counts, and token-usage replay duration. It does not log message text or raw session contents. That should make it easier to distinguish genuinely oversized image-heavy resumes from the smaller active-thread lockups now tracked separately in #28867.

100yenadmin · 2 months ago

@tibo-openai

thisislvca · 1 month ago

Adding a small related macOS datapoint: my full details are in #22004 here: https://github.com/openai/codex/issues/22004#issuecomment-4887099344

This case was thread/read rather than thread/resume, but it looks like the same bounded-payload contract problem. A built-in image-generation-heavy rollout was 1,165,931,575 bytes, mostly duplicated inline image_generation_end / image_generation_call result payloads. Opening/reading the thread produced a single logged JSON response line of 536,871,005 bytes and hit RangeError: Invalid string length in the Electron main process.

A local schema-safe repair that removed inline image bulk reduced the rollout to 6,096,679 bytes, with the same 3,240 JSONL records and max line 84,047 bytes. So the same excludeTurns / bounded tail-only loading direction discussed here likely needs to cover thread/read and stream-state snapshots too, not only thread/resume.

shleder · 14 days ago

Your measured 28–55 MB image-heavy rollouts and 7–20 MB thread/resume responses are a useful persisted-payload case. Codex Rescue currently has bounded oversized-record detection, so I’d like to validate whether it identifies this structure cleanly without trying to load or copy the inline images.

It is local-first and leaves the original rollout untouched. It won’t fix the Desktop transport/rendering stall, strip images automatically, or replay any calls; the useful result is a safe diagnostic boundary.

If one of those sessions still exists, could you run:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

Please share only sanitized output—no raw JSONL, image data, SQLite files, prompts, local paths, or secrets.

https://github.com/shleder/codex-rescue