Historical images are re-uploaded on every turn in Codex Desktop and VS Code #35732

What issue are you seeing?

Summary

Codex Desktop and the Codex VS Code extension appear to include and re-upload all historical image payloads on every subsequent turn in a conversation.

This affects both:

• Images attached or pasted by the user
• Images generated or produced by Codex itself, including screenshots, browser/computer-use images, and generated images

The old images are re-sent even when the new prompt does not refer to them and does not contain a new image.

Impact

In affected long-running threads, the upload payload can grow to tens or even hundreds of megabytes on every turn. As more images accumulate:

• Each new prompt takes progressively longer to upload and process.
• Turn latency increases continuously.
• The conversation may become extremely slow, reconnect repeatedly, freeze, or become difficult to resume.
• The same image bytes may be transmitted many times instead of being reused by reference.
• Context and usage can grow much faster than the visible conversation suggests.

Affected surfaces

• Codex Desktop
• Codex VS Code extension (openai.chatgpt)

The fact that both surfaces show the behavior may indicate that the problem is in shared session replay, context assembly, or app-server request construction.

Actual behavior

Historical user-provided and Codex-generated images appear to be bundled into each new turn as full image data, such as inline image payloads or equivalent binary/base64 content.

The same images are therefore uploaded repeatedly throughout the conversation.

What steps can reproduce the bug?

1. Start a new Codex conversation in Codex Desktop or the VS Code extension.
2. Over multiple turns, attach or paste several user images.
3. Ask Codex to generate images or use a workflow that produces screenshots.
4. Continue the conversation with short prompts that do not reference the old images and do not attach new images.
5. Inspect a sanitized network trace, request-size measurement, or local session metadata. No private logs, screenshots, or session files need to be shared.
6. Observe that previous image payloads are included again in later turns and that the upload size and latency increase as the thread grows.

What is the expected behavior?

Historical images should not be re-uploaded in full on every turn by default.

Codex should preferably:

• Store image data out-of-line and reuse it through stable references, attachment IDs, or a server-side cache.
• Deduplicate identical images across turns and session checkpoints.
• Include old images only when they are relevant to the current context.
• Remove or summarize stale image content during compaction.
• Avoid hydrating large historical image payloads into every request.
• Provide a way to remove or trim old media from an affected conversation.

If an old image is needed again, Codex could explicitly reattach or retrieve it by reference rather than silently transmitting the full image bytes every time.

Additional information

This appears related to:

• Bug: image-heavy chats repeatedly reconnect and become very slow #20805 - image-heavy chats repeatedly reconnect and become very slow
• Desktop compaction repeatedly embeds full image base64 in compacted checkpoints #23257 - compaction repeatedly embeds full image payloads
• macOS Desktop: image-heavy thread takes minutes to open because rollout JSONL embeds generated image payloads inline #22603 - generated image payloads duplicated in Desktop session history
• Desktop threads can be poisoned by inline base64 tool images, leading to {"detail":"Bad Request"} on resume and likely inflated token usage #18629 - inline base64 tool images persisted in replayable history

Those reports cover related symptoms and persistence problems. This report specifically highlights the repeated per-turn upload behavior across both Codex Desktop and the VS Code extension.

I am intentionally not attaching raw transcripts, images, prompts, logs, or session files because they may contain private data. Sanitized request-size measurements and redacted metadata should be sufficient to investigate this behavior.