Codex VS Code extension drops sometimes follow-up prompt submitted while agent is still running

This issue is affecting my Codex client as well. I find that it happens 100% of the time when completing a tooling action.

Also seeing this, and it is still present on a newer build.

Environment

• Codex VS Code extension: 26.707.41301 (newer than the 26.623.x in the report above)
• OS: Windows 11

What I see
After I post a message it sometimes vanishes from the composer as if submitted, but is not processed. It is intermittent, not every time. Two distinct outcomes:

• Sometimes the message reappears in the stream a bit later and does get handled.
• Other times it is gone for good and never comes back.

This matches the follow-up-while-the-agent-is-running scenario described here, and lines up with the queued/stuck behaviour in #26683. Flagging that it reproduces on 26.707.41301, so it is not fixed in the latest release.

I am having the same problem. 100% times.

I can reproduce this consistently in a VS Code Remote-SSH → Docker Dev Container environment.

Environment:

• Windows client
• VS Code 1.128.0, commit fc3def6774c76082adf699d366f31a557ce5573f
• Codex extension 26.707.41301 on both the local VS Code host and the remote Dev Container
• Bundled Codex CLI 0.144.0-alpha.4
• Model gpt-5.6-sol
• Remote extension host: Linux x86_64 in a Docker Dev Container

Observed behavior:

1. Start a long-running Codex turn.
2. While it is still running, enter a follow-up prompt.
3. Submit the prompt.
4. The composer is cleared within approximately 250 ms.
5. No queued-message entry is created, and the prompt is never processed.

Sometimes the prompt briefly appears and then disappears. The original turn continues running normally.

Relevant sanitized log pattern during reproduction:

[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

These warnings can occur in large bursts while the active turn and background agents continue producing reasoning events.

Additional isolation performed:

• Local and remote extension versions were aligned to 26.707.41301; the problem still reproduced.
• No ECONNRESET, timeout, or Remote Extension Host disconnect occurred during the latest recorded reproduction.
• Downgrading the remote extension to 26.5623.101652 made queued follow-ups work again in the same environment.
• However, that older version cannot use gpt-5.6-sol and reports that a newer Codex client is required.
• Returning both local and remote sides to 26.707.41301 reproduced the disappearing follow-up again.

This suggests that the composer clears optimistically before receiving a durable enqueue acknowledgement, while the thread-state/IPC consumer is desynchronized or missing its handler.

Expected behavior:

• Clear the composer only after the follow-up has been durably queued, or
• Restore the prompt and show an explicit error if enqueue fails.

I have short screen recordings showing the composer clearing without a queue entry and can provide sanitized logs if useful.

having sam eissue

Same, irritating issue.

Adding detail to my earlier confirmation: follow-up messages sometimes disappear after I press Enter while Codex is working, with no indication whether they were accepted.

This directly wastes usage quota. Lost instructions require resending and often repeating work, while delayed delivery can duplicate work that was already restarted.

same here using pre-release version 26.5727.51351

same here using pre-release version 26.5727.51351

although i'd like to add that it doesn't alwasy fail, The follow-up seemed to get through when the agent is not busing churning out results.

Same issue here.