VS Code extension resurrects an already-submitted user message into the pending Steer bar

What version of the IDE extension are you using?

26.623.31921 (openai.chatgpt-26.623.31921-win32-x64)

What subscription do you have?

Not included here; I can provide it if needed.

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The VS Code Codex extension can resurrect an already-submitted user message into the bottom pending Steer / follow-up card.

This is not merely a queued follow-up becoming steered. In the observed case:

1. The user message was already visible in the conversation transcript.
2. Codex had already answered that message.
3. Later, the same message appeared again in the bottom composer area as a pending card with a Steer action, delete icon, and overflow menu.

The visible pending card preview matched the already-submitted transcript message. The message began with:

你仔细想想吧：本来如果都没有题的...

A screenshot shows the same user message in the transcript near the top, followed by Codex's answer, while the bottom composer simultaneously shows the same message again as a pending steer/follow-up card. That makes the UI treat an old submitted message as if it were still unsent or steerable.

This looks like stale pending-input / queued-follow-up / steer state being restored or reused incorrectly, rather than model behavior. It is especially risky because clicking Steer on that resurrected card could resubmit an old instruction and interrupt or distort the current turn.

What steps can reproduce the bug?

I do not yet have a deterministic minimal reproduction, but the observed workflow was:

1. Use Codex in the VS Code extension.
2. Send a normal message in an existing thread.
3. Codex answers the message; the message is visible in the transcript.
4. Continue using the thread.
5. A previously submitted message reappears in the bottom pending Steer / follow-up card even though it has already been answered.

The issue appeared recently, around 2026-06-25 to 2026-06-27 local time. It may be related to active turns, follow-up queue state, steering, thread resume/replay, or multiple queued/steered inputs, but I have not isolated the exact trigger.

What is the expected behavior?

Once a user message has been submitted and appears in the transcript, it should be removed from pending input state. The extension should not later show the same submitted message in the pending Steer card.

The UI should distinguish these states clearly and consistently:

• already-submitted transcript messages
• queued follow-ups waiting for the current turn to finish
• true steer inputs meant to affect the active turn
• stale or failed pending inputs that need explicit recovery

A submitted-and-answered message should not be actionable as a new Steer input unless the user explicitly re-enters it.

What do you see instead?

An already-submitted and already-answered message reappears in the bottom composer as a pending steer/follow-up card. The card exposes Steer, delete, and overflow actions for the stale message.

Additional information

This seems related to the broader queue/steer/session-state issue cluster, but I do not think it is an exact duplicate:

• #17876: queued prompts unexpectedly becoming steered in the VS Code extension
• #26413: VS Code queued follow-ups stop processing after completed turns resume as markedStreaming=true
• #13892: queued follow-ups leaking into pending steer state in the TUI
• #19975: replay/fork rendering hides steered user messages even though they exist in the JSONL
• #19951: delayed duplicate prompts became steered and Stop did not work

The distinguishing point in this report is that the resurrected message was already present in the transcript and had already been answered before it reappeared as a pending Steer card.