AskUserQuestion: skipping a question is reported to the model as "No preference", licensing it to proceed on an assumption
When the user skips/dismisses an AskUserQuestion, the model receives "[No preference]" for that question. The model then interprets this as delegated authority to continue with its own best guess.
Why it's wrong: For a forced-choice question, "Skip" most naturally means "none of these options are acceptable — I'll provide more context/guidance," i.e. a stop-and-wait signal. Mapping it to "No preference → proceed" produces the opposite behaviour: the model silently advances on an assumption the user was actively trying to correct. This is especially dangerous when the questions gate consequential decisions (e.g. a KYC/compliance flow).
Expected: A skipped question should be surfaced to the model as an explicit "declined / awaiting further input" signal (distinct from an affirmative "no preference, you decide" choice), so the model pauses rather than proceeds. Ideally the UI would also distinguish "I have no preference, you choose" from "none of these — let me explain".
3 Comments
This looks like a response-semantics problem rather than only a UI-label problem.
"Skip", "no preference", and "you choose" represent three materially different user intents:
DECLINED_OPTIONS -> none of these options fit; ask for more context
DEFERRED_BY_USER -> I will answer later; stop and wait
DELEGATED_TO_AGENT -> I explicitly authorize the agent to choose
Only the last state should license the model to select an option. A dismissal or skip should not be converted into delegated authority.
I drafted a small implementation-neutral state model with transition rules and conformance cases here:
https://github.com/safal207/DIF/issues/35
The core invariant is:
«No explicit human answer means no confirmed human decision.»
A minimal tool result could preserve provenance explicitly:
{
"question_id": "q-123",
"response_state": "DECLINED_OPTIONS",
"selected_option": null,
"decision_source": "HUMAN",
"human_confirmed": false,
"agent_authority": "ASK_FOLLOWUP"
}
This does not require adopting DIF terminology. The useful part is keeping "DECLINED_OPTIONS" distinct from an explicit "DELEGATED_TO_AGENT" outcome.
I can contribute a JSON Schema and concrete "AskUserQuestion" conformance fixtures if that would help evaluate the behavior.
Strong agree on the framing, and I want to add two things: the semantic gap is wider than "skip", and the team has already conceded the principle in a changelog entry — just not for this path.
1. There are at least three non-answer exits, and they emit three different signals — none of which is "stop and wait".
| Exit | What the model receives |
|---|---|
| Skip / dismiss a question |
"[No preference]"→ reads as delegated authority (this issue) || "Type something" on a single-select question | Whole tool call rejected:
The user doesn't want to proceed with this tool use(#70100) || Card dismissed on web/mobile after typing | Same rejection string, with the typed text dropped entirely (#81223) |
Two of these are attempts to answer that get reported as refusals, and one is a refusal reported as permission to guess. Both errors have the same root: the tool result has no vocabulary for "the user engaged but has not decided yet". Your
DECLINED_OPTIONS / DEFERRED_BY_USER / DELEGATED_TO_AGENTsplit (and @safal207's state model) would cover all three, not just skip — I think that strengthens the case for fixing it at the response-semantics layer rather than patching the skip label.2. The "don't tell the model to proceed" principle is already accepted upstream. 2.1.216 shipped:
That is precisely this issue's argument, applied to free-text answers. The skip path simply wasn't included in that change. So this is arguably not a new design decision to litigate — it is finishing one that was already made.
3. A channel for "none of these — here's my actual answer" already exists, in one form only. On 2.1.220 (Linux, TUI), a question asked with
multiSelect: trueopens the "Type something" input in place and returns the typed text inside the tool result alongside the checked options. Single-select has no such path — its free-text exit aborts the call. Details: https://github.com/anthropics/claude-code/issues/70100#issuecomment-5127672274That matters for the UI half of your Expected: distinguishing "I have no preference, you choose" from "none of these — let me explain" doesn't require inventing a new control. The second intent already has a working implementation; it just isn't reachable from single-select questions, which is where forced-choice gating usually happens.
Hitting this as well, on the Japanese UI — where the mismatch is sharper.
The button is labeled 「スキップ」 (= "skip"). In Japanese that reads unambiguously as "I'm not answering this now" — a deferral. There is no reading under which it means "you decide". So a Japanese-speaking user who skips is almost guaranteed to mean the stop-and-wait signal described in this issue, not delegation.
Concrete instance from my session: I skipped two questions expecting to be asked again later. The model received
[No preference], read it as delegation, and proceeded to implement. The changes happened to be reversible so there was no harm — but the same misread on a deletion or anoutbound message would not have been recoverable.
Worth noting the internal identifier appears to be
no-preference, which suggests the design intent really was "no preference = delegate". If so the English label "Skip" already diverges from that intent — this isn't a translation bug, it's the label and the return value disagreeing in everylocale.
Suggested minimal fix, in addition to the UI split proposed above: return
[Skipped]rather than[No preference]. "Skip = pass over" is a well-established convention across UIs, so changing the return value is cheaper than retraining user intuition. The model can then branch on reversibility — proceed and state the decision explicitly when the action isreversible, ask again when it is not.