Codex Desktop thread later becomes unusable after historical image attachment from Windows Temp path

What version of the Codex App are you using?

Unknown / included in Codex App feedback logs.

What platform is your computer?

Windows x64

What issue are you seeing?

A Codex Desktop thread later became unusable after an earlier assistant response included a generated PNG image attachment shown as stored under the Windows user temp directory, similar to:

C:\Users\<user>\AppData\Local\Temp\<generated-image>.png

Important detail: the failure did not happen immediately after the image was generated. The original thread continued successfully for multiple additional messages after that assistant image response. Only later did new messages start failing, including plain text messages with no image attachment, with this error:

Invalid image in your last message. Please remove it and try again.

The error appears misleading because the latest user message is text-only.

Based on fork testing, the suspect point is an earlier assistant image attachment in the conversation history:

• Forks created before the assistant message containing the generated temp PNG continue to work normally.
• The original thread continued to work for multiple messages after the image was generated.
• Later, the original thread began failing on text-only messages.
• Forks around the suspected point suggest the earlier temp image attachment is involved in the failure.
• The local PNG file still exists and validates as a proper PNG.

I verified the local image file with PIL:

python -c "from PIL import Image; p=r'C:\Users\<user>\AppData\Local\Temp\<generated-image>.png'; im=Image.open(p); im.verify(); print(im.format, im.size, im.mode)"

Output:

PNG (1800, 1540) RGBA

This suggests the issue is not simply that the local image file is missing or corrupt. It may be related to how Codex persists, rehydrates, summarizes, replays, or re-uploads historical image attachments from local temp paths during later turns.

Steps to reproduce

I do not have a minimal deterministic repro yet, but the observed sequence was:

1. Use Codex Desktop on Windows.
2. Have the assistant generate or attach a PNG image stored under C:\Users\<user>\AppData\Local\Temp\....
3. Continue the same thread for multiple additional turns.
4. Later, send a plain text-only message.
5. Observe that the message fails with:

Invalid image in your last message. Please remove it and try again.

1. Fork the conversation at different points:

• forks before the temp image attachment continue normally;
• the original thread and/or forks after the suspected image point fail when continuing.

Expected behavior

A prior assistant image attachment should not make a thread unusable later.

If an old image attachment cannot be reloaded, replayed, or re-uploaded, Codex should degrade gracefully by omitting that historical image, showing a recoverable warning, or allowing the user to continue with text-only messages.

The error message should identify the historical image attachment if that is the actual failing object, rather than saying the latest user message contains an invalid image.

Actual behavior

After some later point in the conversation, new text-only messages fail with:

Invalid image in your last message. Please remove it and try again.

The latest user message has no image.

Impact

This can effectively block a long-running thread after significant additional work has already happened after the image generation. Forking from before the image is not a practical workaround because it loses many later turns of context.

Related Codex App feedback

I also submitted this through Codex Desktop Help -> Send Feedback with Include current Codex session logs enabled.

Correlation ID:

019e1f3d-54f2-7750-8c5b-d323631d6cd7

Additional notes

This appears related to session/thread history handling for image attachments, especially attachments generated from or displayed as local Windows temp paths.