Codex Desktop re-sends generated-image history in subsequent /responses turns, growing requests to 27 MB and TTFT to 20s+ #33760

Codex version

Observed client User-Agent:

Codex Desktop/0.145.0-alpha.18 (Mac OS 26.5.1; arm64) unknown (codex_chatgpt_android_remote; dev)

Platform: macOS 26.5.1, Apple Silicon (arm64).

Issue

After generating images in a Codex Desktop thread, subsequent /responses turns appear to retain and re-send large inline image/history payloads. The inbound request body grows from roughly 100 KB to tens of megabytes, and time to first semantic output rises from roughly 2-4 seconds to 13-28 seconds.

This was measured at a relay immediately after receiving the Codex Desktop request and before model mapping or upstream forwarding. Raw request bodies were not retained or inspected; only sanitized sizes, upstream-reported usage, and timing metadata were analyzed.

Sanitized production evidence

Same Codex Desktop client, same thread workflow, same OAuth account, same model (gpt-5.6-sol), and reasoning_effort=medium:

Across the observed requests:

• cached context below 50k tokens: TTFT median 2.22 s
• cached context above 150k tokens: TTFT median 14.87 s, p90 20.46 s
• correlation between TTFT and total reported context size: approximately 0.83

The large requests were not explained by relay contention:

• no overlapping request on the OAuth account for the initial affected samples
• no account proxy
• no rate limit or overload state
• 5-hour quota usage was 0%; 7-day usage was low
• the relay starts TTFT timing only after the inbound body has already been received

The request-size jump occurred immediately after successful image-generation turns. Later turns that did not generate another image still carried 18-27 MB inbound bodies.

Steps to reproduce

1. Open Codex Desktop on macOS.
2. Start a thread using the Responses API path.
3. Generate one or more images in that thread.
4. Continue with ordinary text turns in the same thread.
5. Observe the serialized /responses request size for each subsequent turn and time to first semantic output.
6. Compare with a new thread or compact context.

Expected behavior

Generated image bytes should not be repeatedly embedded in every later model request when the same image is already stored locally or represented in prior response state.

Possible approaches include:

• keep generated image bytes out of hot conversation history and store a durable reference/content hash instead;
• use server-side continuation (previous_response_id) where supported;
• deduplicate or compact old generated-image content before serializing subsequent turns;
• upload image content once and reuse a stable reference;
• expose diagnostics for serialized request size and context composition.

Subsequent text turns should remain bounded in payload size and should not inherit multi-megabyte image bytes unless the image is explicitly needed again.

Related issues

This appears related to the broader inline-image amplification described in:

• App Server explodes websocket frames with mandatory generated image data #21988 (large app-server websocket frames containing generated image data)
• macOS Desktop: image-heavy thread takes minutes to open because rollout JSONL embeds generated image payloads inline #22603 (generated image payloads embedded inline in macOS rollout JSONL)
• # Codex desktop main-process crash: RangeError: Invalid string length when loading sessions whose rollout JSONL exceeds V8's max string length #22004 (oversized image-heavy rollout files)
• Codex App freezes / becomes Not Responding when opening image-heavy projects with many generated images #21232 (image-heavy threads becoming slow/unresponsive)

However, this report covers a distinct runtime impact: the serialized outbound /responses request itself grows to 18-27 MB after image generation, causing sustained model TTFT degradation on later turns, even when the Desktop UI remains responsive.

I can provide additional sanitized per-turn timing and size data if useful, but cannot share raw request bodies because they contain private conversation and image content.