VS Code extension queued follow-up messages sometimes disappear before transcript delivery

Open 💬 5 comments Opened Jul 4, 2026 by bob-bach

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What happened?

In the Codex VS Code extension, follow-up messages queued while Codex is actively working sometimes disappear before they are delivered to the chat transcript.

From the user side, the composer accepts the message and appears to queue it, but the message later vanishes. The message never appears in the transcript, and the agent does not receive it.

This happened multiple times in one session. It occurred both when pressing Enter and when clicking the Send button, so it does not appear to be limited to keyboard handling.

Expected behavior

Queued follow-up messages should persist and be delivered on the next turn, or the UI should show an explicit failure without clearing the draft.

Actual behavior

The queued message sometimes disappears and never appears in the transcript. In some cases, a later queued message appears to overwrite or replace the previous queued message; in other cases, queued messages append as expected.

Relevant logs

From the Codex extension log:

2026-07-04 20:17:43.880 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-queued-followups-changed
2026-07-04 20:17:43.924 [warning] [queued-followups] Failed to release send lock conversationId=019f2ead-049d-7813-8cf3-12485edd7d7d error={}

The logs also show many repeated warnings like:

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

And extension-host errors earlier in the same session:

PendingMigrationError: navigator is now a global in nodejs
TypeError: this.diffPanel.dispose is not a function
Error: Channel has been closed

Environment

Codex VS Code extension: openai.chatgpt version 26.623.101652
Display name: Codex – OpenAI’s coding agent
Codex CLI: codex-cli 0.142.5
VS Code remote/server setup
Remote extension host platform: Linux x64
Client target platform seen in logs: win32-x64
Extension setting defaults from package metadata:
chatgpt.followUpQueueMode: queue
chatgpt.composerEnterBehavior: enter

Workaround

Avoid queued follow-ups and use steering instead. Setting chatgpt.followUpQueueMode to steer appears like the safest workaround because the issue seems tied to the queued-followups path.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

#31100

Powered by Codex Action

theophanemayaud · 1 month ago

Additional extension evidence supporting the send-lock/broadcast theory:

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, a queued follow-up disappeared from the extension, but core received the identical message three times with distinct turn IDs within 32 ms. The prior turn was still running, and all three duplicates completed; there was no failed submission or aborted turn.

This suggests stale queue consumers can replay the same message after the temporary send lock is released because successful delivery is not durably recorded.

I downloaded today’s official extension update, 26.715.61943, and compared the relevant implementation. Its enqueue, owner/follower broadcast, send-lock, and post-send removal logic is semantically unchanged from 26.715.31925; I found no fix there.

Suggested fix: app-server-owned atomic claim-and-consume, idempotent turn/start keyed by (threadId, queuedMessageId), revisioned broadcasts, and composer clearing only after durable acknowledgement.

petterip · 29 days ago

I’m seeing the same behavior: a follow-up submitted during an active turn can clear from the composer without remaining visible or being reliably processed.

The uncertainty materially increases usage consumption. Users must resend missing instructions and repeat affected work, while prompts that arrive late can trigger duplicate processing and consume additional quota.

rr34 · 16 days ago

Confirming this on VS Code 1.132.0, Linux x64 under WSL2.

This is user-input data loss in the primary instruction channel, not a cosmetic queue glitch. While Codex is working, the composer visibly accepts a follow-up message and clears it, but the message can then disappear completely: it is absent from the transcript, absent from the queue, never acknowledged, and never received by the agent.

This workflow previously allowed follow-up messages to stack reliably. It now fails often enough that the only safe workaround is to wait for the agent to finish or copy every message before submitting it. That defeats one of the central benefits of an agentic coding interface: correcting, steering, and extending the work while it is underway.

A submitted instruction needs a durable, visible delivery state:

Queued: retained verbatim until delivery.
Delivered: visibly attached to the conversation and acknowledged by the runtime.
Failed: restored to the composer with an explicit error.
A later message must never overwrite an earlier unacknowledged message.
Clearing the composer must not be treated as proof that the message was safely accepted.

Reproduction:

Start a long-running, tool-using Codex task.
Submit one or more follow-up messages while Codex is still working.
Some messages appear to submit, then vanish instead of remaining queued or entering the transcript.
Codex completes without ever receiving those instructions.

Silently destroying instructions after presenting submission as successful violates the most basic contract of a chat interface. It wastes the user's work, can make Codex perform the wrong changes, and forces users to distrust every mid-run submission. This should be treated as a high-severity reliability defect.

DavidHJong · 11 days ago

Additional Windows reproduction with an owner/follower transition after an IPC reset.

Environment:

Windows x64
VS Code 1.131.0
Codex VS Code extension: 26.810.52044
Bundled Codex CLI: 0.148.0-alpha.9
Default follow-up mode: queue

Observed behavior:

A long-running local task was active and coordinating subagents.
I submitted two follow-up messages from the same VS Code chat while the task was still running.
On both attempts, the composer cleared immediately, but no queued message or user-message bubble remained visible.
The active agent continued its original work and never received or acknowledged either message.

Sanitized diagnostic timeline:

The thread initially acquired stream role owner.
About 32 minutes later, the extension logged an IPC connection reset and remounted the renderer.
After remounting, the same visible chat acquired stream role follower; a different/stale client remained registered as the owner.
This follower state appeared again after subsequent renderer remounts.
Each attempted send produced:

[IpcClient] Received broadcast but no handler is configured method=thread-queued-followups-changed

One attempt was followed shortly by another IPC connection reset.
No visible send error was shown.

Persistence checks:

The authoritative session JSONL contains only the original user prompt.
Neither attempted follow-up appears as a user_message, user-role message, steer event, or turn input.
The local queued-items database no longer contains either follow-up.
The original turn continued writing tool and reasoning events, confirming that the agent itself remained active.

This suggests that after the renderer reconnects as a follower, the UI can clear the composer and mutate the follow-up queue without successfully forwarding the message to the owner or preserving it for later delivery.

Expected behavior:

A follow-up must remain visibly queued until delivery is acknowledged; or
it must be forwarded reliably to the owner; or
the composer must retain the draft and show an explicit send failure.