Repository navigation
image_url serialized as "image urf" in long conversations #26814
Description
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
- Have a long conversation (156+ messages) that includes image content
- Continue the conversation — Codex will attempt to serialize the full history
- 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.
Activity
github-actions commentedon Jun 6, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
etraut-openai commentedon Jun 8, 2026
I took a look. I do not think this is likely to be Rust literally truncating the
image_urlstring 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_shapesuite::image_rollout::drag_drop_image_persists_rollout_request_shapesuite::client::resume_replays_legacy_js_repl_image_rollout_shapesThis 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?
~/.codex/sessions/.../rollout-*.jsonlline around the bad image-bearing message. It is fine to replace the actualimage_urlvalue with<redacted>, but please keep the surrounding JSON keys andtypefields intact.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.