New message queue request is ignored

Feedback ID: 019f7576-165b-70d0-aea5-3a380b11dbbd

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #32982

Powered by Codex Action

Same here — it flashes for a moment and then disappears. Is this a side effect of vibe coding? Even the basic functions in the latest extension are full of bugs, which seriously affects usability!

Related reproduction from the VS Code extension showing that an apparently ignored message may actually be replayed:

• macOS 26.5.2 arm64
• VS Code Insiders 1.130.0-insider
• Codex extension 26.715.31925
• Queue mode enabled

One queued follow-up vanished from the extension UI, but core logs showed it submitted three times as separate turns within 32 ms while the previous turn was still active. All three completed successfully, placing the failure in the client queue path rather than at the server boundary.

The desktop app and extension share the same relevant queued-followup/send-lock flow. The likely race involves queue ownership/state broadcasts plus a temporary lock without durable message-id deduplication.

I checked today’s official extension 26.715.61943 and desktop app 26.715.72028 updates. Their relevant queue paths remain semantically unchanged, so neither appears to contain a fix.

Suggested fix: atomic app-server claim-and-consume, idempotency by queued message ID, revisioned broadcasts, and clearing the composer only after enqueue acknowledgement.

Apparently related: [#34599](https://github.com/openai/codex/issues/34599), [#31128](https://github.com/openai/codex/issues/31128).

I am updating Codex desktop app and this happens as well in:

• Version 26.715.52143 - Released Jul 20, 2026
• Version 26.715.61943 - Released Jul 21, 2026
• Version 26.715.72359 - Released Jul 22, 2026

Still happening with Version 26.721.41059, Released Jul 24, 2026

Still reproducible using Version 26.727.40816 - Released Jul 30, 2026.

<img width="285" height="236" alt="Image" src="https://github.com/user-attachments/assets/b041bbe3-6e9f-419d-8e7c-0e65c96b09a2" />

Still happening.

I am seeing the same issue repeatedly on Codex Desktop 26.803.41515 on macOS with an active task in a project connected over SSH.

I captured one occurrence while inspecting both the local Desktop state and the remote thread:

1. I switched from another task to an active remote task.
2. During thread hydration, the renderer initially had streamRole=null.
3. It then resolved to streamRole=follower.
4. A message submitted during this transition disappeared silently.

The captured state after submission was:

• The message text was present in local prompt history.
• No pending message was displayed.
• queued-follow-ups had no corresponding entry.
• No corresponding turn/start or turn/steer request was observed.
• The message was absent from the remote thread transcript.
• No error or retry action was shown.

The remote thread itself remained responsive, and its existing active turn continued normally. This does not appear to be an SSH outage or remote agent failure.

This suggests a message can be accepted by the composer while stream ownership is still being resolved, before either the owner submission path or follower forwarding path is ready. The text is added to prompt history, but it is not durably queued or delivered.

The issue has occurred multiple times, although I cannot yet reproduce it reliably on demand.

Expected behavior: while streamRole is unresolved, the composer should either temporarily disable submission or persist the message in a durable outbox and forward it once ownership resolution completes. A message that cannot be delivered should remain visible with an explicit retry/error state instead of disappearing silently.

Raw logs and identifiers are omitted because they may contain private environment information, but I can provide additional sanitized event sequences if useful.