[Bug] AskUserQuestion silently auto-rejected when user messages queued

Bug Description

Bug: AskUserQuestion silently auto-rejected when user messages are queued

Product: Claude Code v2.1.167 (model: Opus 4.8 / claude-opus-4-8[1m])
Date: 2026-06-07
Severity: medium (interactive prompts are silently lost)

Summary

When the user has queued one or more messages while the assistant is working, a subsequent AskUserQuestion tool call is auto-rejected and the question UI never renders to the user. The assistant receives "The user doesn't want to proceed with this tool use," but from the user's side no question/options were ever shown — so it looks like nothing happened, and the decision the assistant was trying to surface is silently dropped.

Repro

1. Assistant is running a long task (e.g. a subagent).
2. User types one or more messages while it's working (they queue).
3. Assistant finishes and calls AskUserQuestion.
4. The queued message(s) get delivered, and the AskUserQuestion is rejected without ever displaying the question card.

Observed

• Assistant got tool result: The user doesn't want to proceed with this tool use. The tool use was rejected...
• User reported: the question prompt / options never appeared on their screen.

Expected

One of:

• Render the AskUserQuestion card even if there's queued input (let the user answer or dismiss it), OR
• If queued input supersedes the question, tell the user explicitly ("a question was skipped because you'd already sent a message"), rather than silently rejecting it.

Impact

The assistant's attempt to get an explicit decision is lost; the user never sees the options, and may not realize a choice was being requested. Easy to mistake for the assistant ignoring them.

Hypothesis

Queued/pending user messages take priority and cancel the pending interactive tool call before its UI is presented.

Environment Info

• Platform: darwin
• Terminal: tmux
• Version: 2.1.167
• Feedback ID: 0733c941-3bc9-45d7-85f4-e799c8142d83

Errors

[]