Codex Desktop: stale pasted-text attachment survives app update and breaks subsequent long pastes

What version of the Codex App are you using (From “About Codex” dialog)?

Exact build not captured. The issue appeared immediately after updating Codex Desktop.

What subscription do you have?

Not relevant to the reproduction.

What platform is your computer?

Codex Desktop. Exact OS/build not captured for this report.

What issue are you seeing?

A large pasted-text attachment that was left unsent in the composer disappeared from the chat UI after updating Codex Desktop, but it appears that attachment state remained persisted under the Codex attachments directory.

After returning to the chat following the update, the attachment was no longer visible. When I tried to paste the long text again, the composer/paste UI entered an incorrect state instead of handling the paste normally. I do not remember the exact UI wording, but it behaved as though Codex still had stale state associated with the pasted content / attachment.

The important observation is that deleting the contents of the Codex attachments directory and restarting the app restored normal long-paste behavior immediately.

This suggests a lifecycle/reconciliation problem between persisted pasted-text attachment state and restored composer/draft state across an app update.

What steps can reproduce the bug?

The sequence that triggered it was:

1. Open an existing Codex Desktop chat.
2. Paste a sufficiently long text so Codex converts it into a pasted-text attachment rather than keeping it inline in the composer.
3. Leave that attachment in the composer without sending the message.
4. Update Codex Desktop.
5. Reopen Codex and return to the same chat.
6. Observe that the previously attached pasted text is no longer present in the composer/UI.
7. Paste the long text again.
8. Observe that the paste/attachment UI does not behave normally and appears to retain stale state from the previous attachment.
9. Close Codex.
10. Delete the contents of the Codex attachments directory.
11. Restart Codex and paste the text again.
12. The paste works normally again.

I have only observed this once so far, so the update transition may be an important part of the reproduction.

What is the expected behavior?

After an app update, Codex should keep composer/draft attachment state and persisted attachment state consistent.

If an unsent pasted-text attachment cannot be restored after an update, Codex should clean up or invalidate its persisted attachment/registry state so it cannot affect future pastes.

A stale or orphaned attachment should not make later long-paste operations behave incorrectly.

Additional information

Codex Desktop stores large pasted text as real files under its attachments directory and maintains separate pasted-text attachment state. Related reports document paths such as:

~/.codex/attachments/<uuid>/pasted-text.txt
~/.codex/attachments/pasted-text-attachments.json

The fact that deleting the attachments directory and restarting Codex fixed the problem strongly suggests that some persisted attachment state survived after the composer no longer represented that attachment.

I am not claiming that Codex deduplicates pasted text by content/hash; the exact stale-state mechanism is unknown. Possibilities include an orphaned attachment path, registry entry, pending-removal state, or draft/attachment reconciliation failure.

A useful invariant may be to reconcile on startup/update:

• persisted composer attachment references whose files no longer exist;
• attachment registry entries no longer referenced by a draft/thread;
• orphaned pasted-text files;
• pending-removal entries left across restart/update.

If I reproduce this again, I can preserve and compare pasted-text-attachments.json and the attachment directory before applying the cleanup workaround.

Related issues

• #31020 — large pasted text starts failing after a Codex Desktop update and persisted attachment state survives normal cache cleanup/reinstall. Related, but this report adds a specific trigger involving an unsent pasted-text attachment that disappears from the restored composer after the update.
• #29069 — pasted-text-backed conversation/history can disappear while the attachment still exists on disk. Related state/index consistency issue, but not the same reproduction.
• #25346 — documents the Desktop pasted-text attachment lifecycle/registry and a separate bug where /goal does not materialize those attachments.

This report is specifically about stale/orphaned pasted-text attachment state across an app update affecting subsequent paste operations.

Reproduce the update sequence with an unsent long pasted-text attachment, then inspect the Codex attachments directory and pasted-text-attachments.json before and after restart. Trace how restored composer state is reconciled with persisted attachment files and registry entries. Done means an attachment that cannot be restored is cleaned up or invalidated and no longer affects later long pastes.