Web UI: message sent after dismissing an AskUserQuestion popup renders out of chronological order
Summary
In a remote/web Claude Code session, dismissing an AskUserQuestion popup (closing it without selecting an option) causes the user's next chat message to render out of chronological order — it appears above Claude's follow-up text instead of below it. This makes it look like Claude produced one long uninterrupted block of text with no user interaction in between, when in fact the user did reply and Claude's later text is a response to that reply.
Environment
- Affected: web/remote session UI
- Not affected: a terminal multiplexer (tmux/screen over SSH) attached to the same session showed the correct chronological order for the same exchange
This strongly suggests the bug is in the web client's message rendering/ordering, not in the underlying session/event log, since the same session viewed via terminal was correct.
Steps to reproduce
- Claude calls
AskUserQuestionwith a multiple-choice prompt. - User dismisses/closes the popup without selecting an option (exact trigger unconfirmed — possibly a stray click, or closing via an "X"/back gesture).
- Claude receives a "user dismissed" signal (no answer text) and sends a short text reply acknowledging this and asking the user to clarify.
- User replies in plain chat with their actual answer/decision.
- Claude's next message acts on that answer.
Expected
Transcript order: [dismissed popup] → [Claude: "pausing, let me know how you'd like to proceed"] → [User's reply] → [Claude's next response acting on the reply].
Actual (web UI only)
The user's reply renders above Claude's "pausing" message:
[dismissed popup] → [User's reply] → [Claude: "pausing, let me know..."] → [Claude's next response]
This reads as if Claude generated a continuous, uninterrupted block of text (the "pausing" line immediately followed by the substantive response) with the user's own message misplaced earlier in the thread, rather than appearing between the two Claude messages where it chronologically belongs.
Impact
Purely cosmetic/trust issue — no evidence the underlying conversation state, tool calls, or file edits were affected; the terminal view of the identical session showed correct ordering and correct causality (Claude only acted after the user's reply arrived). But it's confusing and, in a legal/professional context, undermines confidence that the displayed transcript accurately reflects what was said and in what order.
Repro note
Willing to provide a redacted screenshot showing the misordering if useful, but the original session contains sensitive (legal case) content that should not be shared publicly — happy to provide a genericized repro instead if a maintainer wants more detail.