›_ Codex Issues
Codex Issues / #34599

Messages sent during active work can be dropped instead of steering or queuing

Open 💬 4 comments Opened Jul 21, 2026 by Aure-MandyP
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

In the Codex VS Code experience, messages sent while an agent is actively working can appear to be lost instead of being applied as a steer or retained in the queue for the next turn. The user then has to resend the correction.

Environment

  • Codex VS Code extension build: openai.chatgpt-26.715.31925-linux-x64
  • Platform: Linux x86_64
  • Observed: 2026-07-22
  • Collaboration mode: Default

Expected behavior

A message sent while Codex is working should always do one of the documented actions:

  1. steer the active turn; or
  2. remain visibly queued for the next turn.

It should never disappear without being applied or queued.

Actual behavior

During a long-running tool-using task, messages sent while the agent was working were not reliably surfaced as a steer or queued follow-up. The user perceived them as lost and had to resend them. Later messages could interrupt the active turn, but delivery/queue behavior was inconsistent.

Reproduction outline

  1. Start a long-running Codex task that performs multiple tool calls.
  2. While the run is active, send one or more correction messages.
  3. Continue interacting while the agent is between tool calls or waiting on tool output.
  4. Observe whether every message is either acknowledged in the current turn or remains visibly queued.
  5. In the failing case, a correction is neither visibly applied nor retained, so it must be resent.

Impact

This can cause user corrections or safety-relevant infrastructure details to be missed during active work. It also makes the user uncertain whether subsequent messages are safe to send before the current run finishes.

Suggested investigation

Please inspect client/server event sequencing around active-turn interruption, steer delivery, queue persistence, and turn-aborted transitions. A durable per-message delivery/acknowledgement state in the UI would make failures diagnosable.

No repository contents, credentials, account identifiers, or private source details are included in this report.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34021

Powered by Codex Action

xming521 · 1 month ago

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!

theophanemayaud · 1 month ago

Another concrete extension reproduction from me today, and it has happened multiple times over the past week, it is really annoying to loose messages that took a long time to prepare:

  • macOS 26.5.2 arm64
  • VS Code Insiders 1.130.0-insider
  • Codex extension 26.715.31925
  • chatgpt.followUpQueueMode = "queue"

At 2026-07-22 07:24:54 UTC, one queued follow-up disappeared from the extension UI but reached Codex core three times within 32 ms, with three distinct turn IDs. The preceding turn was still active; all three duplicates were accepted and completed, with no rejection or turn_aborted.

This suggests a client-side queued-followup ownership/state race. The temporary send lock prevents concurrent sends but does not appear to provide durable per-message idempotency, allowing stale consumers to replay a message sequentially.

I also downloaded today’s official extension update, 26.715.61943, and compared its enqueue, owner/follower broadcast, send-lock, and removal paths against 26.715.31925. They are semantically unchanged, so I found no fix in that update.

Suggested fix: app-server-owned atomic claim-and-consume, deduplication by (threadId, queuedMessageId), revisioned queue updates, and composer clearing only after durable acknowledgement.

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

studyreadbook4ever · 15 days ago

Additional reproduction from the Cursor IDE integration on Linux (observed 2026-08-13):

  • Cursor: 3.7.19 (80c653c2c3528e65016a0d304b54486084b470b0, x64)
  • Codex extension: openai.chatgpt 26.5707.41301
  • OS: Linux x86_64 (Arch kernel 7.1.5-arch1-2)
  • Local Codex CLI: 0.144.1
  • No chatgpt.followUpQueueMode override is configured, so the documented default (queue) applies.

What happened

  1. A long-running Codex turn was active in Cursor.
  2. The user typed a short follow-up reporting that the task had succeeded and pressed Enter.
  3. The message did not reach the agent and was not later delivered as a queued follow-up.
  4. Because there was no clear delivery acknowledgement, the user pressed Enter repeatedly.
  5. Cursor eventually displayed the turn as interrupted (localized UI).
  6. On the agent side, the previous run was recorded as turn_aborted; there was no user-message event containing the text submitted before the abort.
  7. Afterward, resending the message in a new turn worked normally.

This was not a normal agent completion. From the agent-visible event sequence, the active turn was aborted while the earlier composer input was lost.

Expected

While a turn is active, Enter should enqueue the message exactly once (or steer it according to the selected mode) and show a durable acknowledgement. If submission fails, the draft should remain recoverable with an explicit error. Repeated Enter should not silently discard the message or ambiguously abort the active turn.

This adds a Cursor-specific reproduction where message loss and a turn_aborted transition occur together. It may be a composer/queue acknowledgement race in the VS Code-compatible extension host.

No session transcript, repository content, account identifier, credentials, or private local paths are included.