[RETRACTED — not a Claude Code bug; local tooling was injecting keystrokes] AskUserQuestion returns a fabricated 'answered' result when its UI vanishes/is dismissed, instead of an explicit no-answer

Summary

When an AskUserQuestion prompt's UI disappears before the user can read or act on it, the tool call can still resolve as if the user made a real selection — with no signal in the result distinguishing it from a genuine answer. This is more dangerous than the known "dismiss discards the answer" bugs (e.g. #81223, #58750) because here the tool does NOT report a dismissal/discard at all: it reports a normal, confident "answered" result, so the calling model has no way to tell the difference between real consent and a phantom one.

Observed behavior

• A single-select AskUserQuestion with 4 options was issued to the user.
• The user reports: "the options to your question disappeared before I could read them. I don't know why. it auto-selected the first option."
• The tool result recorded a normal answer (answered: <first option's text>), with no error, warning, or dismissed/cancelled flag.
• The auto-selected option happened to be the one the assistant had listed first (which, per the tool's own convention, is typically the recommended option) — so the phantom answer looked plausible and agreed with the assistant's own recommendation, making it harder to catch.
• The decision being "approved" was a security-relevant one (who edits an in-flight internal-auth control two teams were touching concurrently) — exactly the class of decision where a fabricated approval is most damaging.
• No other AskUserQuestion had been issued earlier in the session, and no other input was pending, ruling out an obvious stale-queued-input explanation.

Why this matters

Tools like AskUserQuestion exist specifically so an agent can pause for real human judgment before acting. If the UI can vanish and still return a well-formed "answered" result, the tool silently converts "I need permission" into "I have permission" — defeating the entire purpose of asking, with no way for the agent to detect it happened.

Expected behavior

An AskUserQuestion that is dismissed, times out, or otherwise loses its UI before the user acts on it should NOT return a normal answer. It should return an explicit no-answer/cancelled/dismissed result that the calling model can distinguish from a real user selection, so the model re-asks (or otherwise fails closed) instead of proceeding on a phantom approval. If a default-on-dismiss behavior is ever intentional, it should be surfaced in the tool result as such (e.g. defaulted: true), never indistinguishable from a genuine user choice.

Related issues

This looks related to but distinct from:

• #81223 — dismissing a card silently discards the typed answer (data loss, not fabricated approval)
• #73490 — AskUserQuestion auto-dismisses after 60s while mid-answer
• #71028 — prompt discarded by a single Esc keypress
• #58750 — Cowork Desktop: card never reaches renderer, silently resolves as "Dismissed" on app quit

Those all describe the prompt being lost and the tool correctly (or incorrectly) reporting a discard/dismissal. The bug here is narrower and arguably worse: the tool reports a successful answer with no indication anything went wrong, when the user never saw or interacted with the options at all.

Environment

• Observed 2026-08-04, terminal/CLI Claude Code session (not Cowork/Desktop).