Chat message sent while AskUserQuestion is open reports to the model as a user dismissal
What happens
An AskUserQuestion is presented. The user types an unrelated chat message and presses enter. The ask closes, and the model receives:
[User dismissed - do not proceed, wait for next instruction]Why it matters
That string is indistinguishable from a deliberate refusal, so the model treats a decision as made when the user never made one.
In my session the assistant reported an item as "parked on your word" and stopped work on it. It was parked on a keystroke aimed at something else entirely. The user only found out because they happened to contradict it a few turns later.
The failure is silent in the direction that hides it: nothing in the transcript distinguishes an ask that was superseded from one that was answered no. Neither side has any signal that a decision was manufactured.
Expected
Either the ask survives the chat message and stays open, or the model receives a signal that separates the two states, for example:
[Ask superseded by a new user message - still unanswered]Anything that distinguishes the user said no from the user said something else.
Reproduction
- Have the assistant present an
AskUserQuestionwith two or more options. - Before answering, type any chat message.
- Press enter.
- The ask closes and the model reports a dismissal.
Environment
Claude Code desktop, Windows 11, Opus 5.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Still relevant. A chat message typed while an
AskUserQuestionis open still closes the ask and delivers[User dismissed - do not proceed, wait for next instruction]to the model.The problem is entirely in that string. It is indistinguishable from a deliberate refusal, so the model treats a decision as made when the user never made one, and reports work as parked on a choice that was actually a keystroke aimed elsewhere.
Same family as #77015, where clicking the notification for an open question cancels it. In both cases a neutral interaction is reported to the model as an explicit cancel, and the model has no way to tell the two apart. Distinguishing dismissed from interrupted would fix both.
Still open. The defect is one string. When a user types an unrelated chat message while an
AskUserQuestionis open, the ask closes and the model receives[User dismissed - do not proceed, wait for next instruction].That is indistinguishable from a deliberate refusal, so the model records a decision the user never made. In my session the assistant reported an item as parked on the user's word and stopped work on it. It was parked on a keystroke aimed at something else. The user found out several turns later by contradicting it.
Nothing in the transcript separates an ask that was superseded from one that was answered no, so neither side has a signal that a decision was manufactured. Either keep the ask open across the chat message, or send something that distinguishes the two states, for example
[Ask superseded by a new user message - still unanswered].Still open. On #77015, another user independently reported a third case: approving a permission prompt in a different session dismissed an open question, and the model was told "The user did not answer the questions."
So there are now three neutral interactions that close an open question and report it to the model as a non-answer: a chat message (this issue), a notification click, and a permission approval in another session (#77015). A distinct "superseded, still unanswered" signal would cover all three.