Refiling #26388, which was the same bug. That issue was closed by the bot for inactivity (its closing comment recommended opening a new one if still relevant — this is that).
Problem
When a user types a message while Claude is mid-response, the message sits in a queue and gets delivered after Claude finishes. Claude reads it as a reply to its just-completed output — but the user was responding to something earlier.
This came up multiple times in a long architecture-design conversation today. The user would react to something I'd written 2–3 messages back, type their reaction while I was generating a follow-up reply, and submit it. I'd then interpret their reaction as feedback on the new reply I'd just produced. Both of us spent the next turn untangling who was responding to what.
Proposed solution (same as #26388)
The client already knows whether a user message was submitted while Claude was processing. Tag those messages before sending to the model — either with a prefix:
[typed while Claude was writing]
<user message>
or as a system-level annotation:
<message-context>This message was typed while Claude was still responding.
It likely refers to the conversation before Claude's last response, not to that response itself.</message-context>
<user message>
Either gives the model enough context to disambiguate.
Why this still matters
- Voice-input users hit this constantly. Dictation is slower than typing; messages queue often. The user in today's session noted this is "what just happened to us."
- Wasted turns. Both parties spend the next exchange figuring out which message was responding to what.
- Simple client-side fix. No model retraining; just timing metadata the client already has.
Reference
Refiling #26388, which was the same bug. That issue was closed by the bot for inactivity (its closing comment recommended opening a new one if still relevant — this is that).
Problem
When a user types a message while Claude is mid-response, the message sits in a queue and gets delivered after Claude finishes. Claude reads it as a reply to its just-completed output — but the user was responding to something earlier.
This came up multiple times in a long architecture-design conversation today. The user would react to something I'd written 2–3 messages back, type their reaction while I was generating a follow-up reply, and submit it. I'd then interpret their reaction as feedback on the new reply I'd just produced. Both of us spent the next turn untangling who was responding to what.
Proposed solution (same as #26388)
The client already knows whether a user message was submitted while Claude was processing. Tag those messages before sending to the model — either with a prefix:
or as a system-level annotation:
Either gives the model enough context to disambiguate.
Why this still matters
Reference