[FEATURE] Cowork: multi-choice question widget (AskUserQuestion) interrupts user before they finish reading the response

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 19, 2026

Product area

Claude (Cowork mode) — the multi-choice/clickable-options question interface (internally AskUserQuestion).

Problem

The multi-choice question widget renders immediately, with no delay and no confirmation step, on top of or in place of the reply text the user is still reading. This interrupts the user's ability to finish absorbing the information they need in order to actually make the choice being presented. The interaction is backwards: it demands a decision before it has finished delivering the information the decision depends on.

  • The user is still reading the preceding paragraphs (context, tradeoffs, reasoning) when the options UI takes over the visual space.
  • Reading is physically interrupted mid-response — the interface asks for a choice before the user has finished processing the information behind it.
  • It reads as a "choose your own adventure" pop-up rather than a considered response, which undermines trust for tasks involving real decisions.
  • This happens every time the model invokes the tool, regardless of how much explanatory content precedes the choices.

Why a memory/prompt-level workaround is not sufficient

I have repeatedly instructed Claude, via this account's persistent memory/preference settings, to never use this widget and to ask clarifying questions in plain running text instead. This is not a one-time miss: Claude has ignored the instruction on multiple separate occasions, across multiple sessions, over an extended period. The instruction was saved to persistent memory, worded as an explicit hard rule, and restated after each violation — and Claude still invoked the widget again in a later session, including once more within the very session where this issue was written up.

This demonstrates the underlying issue can't be reliably solved by user-side instruction, memory, or prompting. It needs a product/feature-level fix, not reliance on the model "remembering" to behave correctly on a given turn.

Requested changes (in order of preference)

  1. Add a user/account-level setting to disable the multi-choice question UI entirely — enforced structurally regardless of model behavior.
  2. If retained by default, gate it behind an explicit "ready" step (e.g. "Ready to see the options?") so the user controls when choices appear, only after finishing the surrounding context.
  3. At minimum, guarantee the options never visually interrupt or obscure unread text, and never cause the view to jump or pull focus away from content not yet read.

Impact if unaddressed

Users are asked to decide before they've finished receiving the information the decision depends on — for any task involving genuine tradeoffs (the exact situation this widget is meant for), that defeats the purpose of the feature and degrades decision quality.

View original on GitHub ↗