[BUG] Already-answered user message re-delivered as new input — 3x as consecutive turns, and again mid-turn via the queued-input path (2.1.234)

Preflight Checklist

• [x] I have searched existing issues — closest matches are #86354 and #74637, but neither describes this delivery pattern (details below)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.234, latest published)

What's Wrong?

An already-answered user message is re-delivered to the model as if freshly sent, in two variants within a single session:

Variant A — same message delivered as N consecutive user turns. One message I typed once arrived as three separate consecutive user turns. The assistant answered it in full, then answered it again, then a third copy arrived. No re-send, no retry, no Up-arrow recall on my end.

Variant B — an earlier message re-delivered mid-turn. A message I had sent (and that had been fully answered two turns earlier) was delivered again in the middle of a later, unrelated turn, via the queued-input path — the assistant received it wrapped in the standard "The user sent a new message while you were working" system reminder, attached to a tool result. It began acting on the stale prompt before recognizing it had already answered it.

What the terminal showed for Variant B (my typed prompt was only the first one; the second was never sent by me in this turn):

❯ What's my invocation profile for my role? How can I find that out?

⏺ Let me query it directly with your profile.

  Ran 1 shell command

❯ Look at the logs for that process. There is a ton of them that say calling claude AI. My guess is that this is just a
  labeling error and bedrock was actually called? Can you verify?

⏺ Note: the "calling Claude AI" question was already verified two messages back — [...] Continuing with the
  invocation-profile question.

The re-delivered text is not the model quoting context — it arrives through the input-delivery path and is rendered as a user turn with the ❯ prompt marker.

This has a real cost beyond the display: the model spends full turns re-answering work it already completed, and in Variant B it began executing against a stale instruction while a different question was in flight.

What Should Happen?

A user message should be delivered to the model exactly once. A message already consumed in a prior turn should never be re-injected into a later turn's queued-input path.

Error Messages/Logs

No errors surfaced in the transcript. Nothing appeared in /doctor. The replays are silent — they are indistinguishable from genuine user input from both the model's and the terminal's point of view.

Steps to Reproduce

I do not have a deterministic repro; it appeared spontaneously mid-session. Conditions present when it occurred:

1. Long-running session (multi-hour, heavy tool use — many Bash calls in sequence).
2. Several turns involved tool calls taking 10–60s, during which input is queued.
3. Both variants happened within the same session, roughly 15 minutes apart.
4. Variant A's triple-delivery occurred on consecutive turns with no tool call in flight when I hit enter.

Happy to supply a Feedback ID via /bug from the affected session if that's more useful than this write-up.

Claude Model

Opus 5 (claude-opus-5)

Is this a regression?

Unknown — this is the first time I've hit it. I have no earlier known-good version to point to.

Version

2.1.234

Platform

macOS (darwin 25.6.0), zsh, terminal (not the desktop app)

Related issues

• #86354 — "Previous session messages reinserted in current session with exposed internal tags." Similar reinsertion symptom, also darwin, v2.1.231. That report describes cross-session reinsertion with internal tags rendered; mine is within a single session with no exposed tags, so it may or may not share a root cause.
• #74637 — turn/message desync where a queued message is silently removed. Same subsystem, opposite failure direction (duplication rather than loss).
• #84176, #83103, #85697, #84320 — the broader cluster of mid-turn queued-input defects.

If maintainers consider this a duplicate of #86354, feel free to close and fold the detail in — the within-session duplication and the mid-turn re-delivery are the parts I could not find already described.