›_ Codex Issues
Codex Issues / #26814

image_url serialized as "image urf" in long conversations

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

Description

When a conversation reaches ~156+ messages and includes images, the Codex CLI serializes image_url as image urf (missing the letter "l") in the API request body. This causes the API to reject the request with a deserialization error.

Error Message

Failed to deserialize the JSON body into the target type: messages[156]: unknown variant image urf, expected "text" at line 1 column 199472

Steps to Reproduce

  1. Have a long conversation (156+ messages) that includes image content
  2. Continue the conversation — Codex will attempt to serialize the full history
  3. The API returns the above deserialization error

Expected Behavior

image_url should be serialized correctly as image_url, not image urf.

Environment

  • Codex Desktop (Windows)
  • CLI version: 0.137.0-alpha.4
  • Date: 2026-06-07

Additional Context

The issue appears to be in the Rust serialization layer where message content types are constructed for the API request. The string image_url is being truncated/corrupted to image urf at position 156 in the messages array, suggesting a possible buffer overflow or string truncation bug.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25365

Powered by Codex Action

etraut-openai contributor · 2 months ago

I took a look. I do not think this is likely to be Rust literally truncating the image_url string or an enum tag at message 156. The Codex request/rollout image items are strongly typed, and the current image rollout coverage passes for both copy/paste local images and drag/drop data URLs:

  • suite::image_rollout::copy_paste_local_image_persists_rollout_request_shape
  • suite::image_rollout::drag_drop_image_persists_rollout_request_shape
  • suite::client::resume_replays_legacy_js_repl_image_rollout_shapes

This looks more likely to be in the same family as #25365 / #24582: an image-heavy or corrupted persisted history gets replayed, and the server rejects the reconstructed request. The messages[156] part may just be where the first bad replayed item lands, not a magic threshold.

Could you share one of these, with private data redacted?

  1. A thread/session id or request id from the failing turn.
  2. The relevant ~/.codex/sessions/.../rollout-*.jsonl line around the bad image-bearing message. It is fine to replace the actual image_url value with <redacted>, but please keep the surrounding JSON keys and type fields intact.
  3. If you captured the outbound request body, the single messages[156] item with image bytes redacted.

The key thing to check is whether the persisted/request item really contains "type":"image urf", or whether the local item is valid (input_image / image_url) and the bad variant appears later during backend translation. That distinction decides whether this is a local rollout corruption bug or a server/request-shape bug.

shleder · 11 days ago

This is a useful long-history serialization/replay case for field-testing codex-rescue==0.1.0a4.

If the original affected rollout still exists, could you run:

pipx install codex-rescue==0.1.0a4
codex-rescue doctor --json "/path/to/the-affected-rollout.jsonl"

The diagnostic is read-only. It won’t fix the API serializer, but it can help distinguish whether malformed image-related state is already present in durable history or only appears when Codex reconstructs the outbound request.

A sanitized status/findings summary is enough. Please don’t post raw rollouts, images, databases, prompts, tool output, credentials, repository data, session IDs, or private paths.