Unbounded image history payload can make threads unrecoverable with 413

Open 💬 1 comment Opened Jun 28, 2026 by DJNgoma

What version of Codex are you using?

Current main as of commit bdd282f in openai/codex.

What issue are you seeing?

After asking Codex to analyze an image for OCR, the thread can become permanently stuck with repeated request-size failures:

unexpected status 413 Payload Too Large: request too large, url: http://127.0.0.1:48111/v1/responses

Once the thread is in this state, sending a follow-up message still fails even when the image attachment is no longer attached to the chat. The oversized payload appears to be persisted in conversation history/rollout state and replayed on resume.

This looks related to #11440, but the concrete path here is image/tool-output history rather than only long text compaction.

Root cause hypothesis

In the current code path, image tool/function output can be prepared into a base64 data URL before being persisted into conversation history. Resume reconstruction later records persisted rollouts into history, and function output image items are preserved without counting the image URL against truncation budgets.

That means one large prepared image data URL can poison a rollout/history record and keep being included in later /v1/responses payloads.

Expected behavior

Codex should bound image payloads that enter model-visible history and should recover by replacing or omitting oversized image items, rather than replaying an unbounded base64 image until every follow-up request fails with 413.

Proposed fix

I have a patch branch here, but this repo currently blocks PR creation from non-collaborators:

https://github.com/openai/codex/compare/main...DJNgoma:codex:codex/bound-image-history-payloads?quick_pull=1

Commit:

383ac91 Bound image history payloads

The patch does two things:

  • Caps prepared prompt image data URLs at 10 MiB before they are persisted into conversation history, replacing oversized prepared images with the existing image-too-large placeholder.
  • Counts function-call output image URLs against the existing byte/token truncation budget instead of preserving them unbounded, so resumed legacy rollouts can omit oversized image items.

Validation run on the patch branch

just fmt
just test -p codex-utils-output-truncation
just test -p codex-core image_preparation
just fix -p codex-utils-output-truncation
just fix -p codex-core

The full just test suite was not run locally.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗