codex - 💡(How to fix) Fix Codex Desktop thread later becomes unusable after historical image attachment from Windows Temp path [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#22442Fetched 2026-05-14 03:36:03
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Participants
Timeline (top)
labeled ×3

Error Message

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: The error appears misleading because the latest user message is text-only. 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.

Root Cause

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

Fix Action

Fix / Workaround

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.

Code Example

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)"

---

PNG (1800, 1540) RGBA
RAW_BUFFERClick to expand / collapse

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.

  6. 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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING