[macOS Desktop] Already-submitted message intermittently appears in a new thread's composer

What version of the Codex App are you using?

Codex Desktop 26.831.20005 (build 7524), read from the installed app bundle.

What platform is your computer?

macOS 26.0.1 (build 25A362).

What issue are you seeing?

An already-submitted message from one thread can intermittently reappear as editable text in the composer of a newly created thread.

In the source thread, the message has already been sent and is present in the conversation history. The source thread's composer is empty after submission. However, after creating a new thread, that same submitted text sometimes appears pre-populated in the new thread's composer as though it were an unsent draft.

The exact trigger is not yet isolated. This looks like submitted composer/draft state leaking across thread boundaries.

Steps to reproduce

The issue is intermittent, but the observed sequence is:

1. Open an existing Codex Desktop thread.
2. Type and send a normal text message.
3. Confirm that the message appears in the transcript and the composer is empty.
4. Create a new thread.
5. Observe that the new thread's composer may contain the text of the message that was just sent in the previous thread.

Expected behavior

A newly created thread should start with an empty composer unless the user explicitly entered a draft in that new thread.

After a message is successfully submitted, it should not remain in pending draft state or be restored into another thread's composer.

Actual behavior

The new thread's composer is sometimes populated with an already-submitted message from the previous thread.

Impact

This is confusing and can cause accidental duplicate submission. Because the text crosses thread boundaries, it may also expose content from one task in an unrelated task if the user does not notice it before sending.

Additional information

• The source message is already visible in the source thread's history.
• The source thread's composer is empty after submission.
• The stale text appears specifically after creating a different, new thread.
• A deterministic reproduction has not yet been found.
• No message content is included here because it may contain private task context.

Related but not identical reports:

• #13866 — a sent prompt reappears after leaving and returning to the same thread; closed as completed. This report concerns a current-build, cross-thread leak into a newly created thread.
• #39610 — submitted composer text may remain after Send / Steer. In this report, the source composer has already cleared, and the text later appears in a different new thread.

No source file or test is named. Start by reproducing the send-then-create-thread sequence and trace composer draft state across the source and new threads, using related issues #13866 and #39610 for context. Done means submitted text never reappears in a different new thread's composer, while an explicit draft remains available in its own thread.