AskUserQuestion silently discards typed free-text answer on single-select when a different option is selected

Bug: AskUserQuestion silently discards a typed free-text answer when a different option is selected at submit (single-select)

Severity

Silent, unrecoverable deletion of user-authored content. A long answer composed by the user was
destroyed with no warning, no confirmation, and no copy written to any on-disk store. Both parties were
left believing something other than what happened.

Environment

• Claude Code 2.1.229, CLI entrypoint
• Windows 11 Home 10.0.26200
• Occurred 2026-09-07, 19:50 local (PDT)

What happened

The assistant called AskUserQuestion with multiSelect: false and three pre-written options. The
tool supplies its own free-text ("type something else") entry in addition.

The user then:

1. Moved the selection down to the free-text option.
2. Typed a long, multi-line answer — several hundred words of substantive content.
3. Lost track of the cursor position and moved the selection back up to the option list, landing on a

different option than the free-text one.

1. Pressed Enter, believing this would submit the typed answer.

Expected

The typed text is preserved and surfaced. At minimum it should be returned alongside the selected
option so the assistant can reconcile the two. The user's proposed wording:

"The user chose \<option\>, but the user also typed \<very long string from the Type something else option\>. Please verify the user intent."

Acceptable alternatives: warn before submitting, or refuse to discard a non-empty free-text buffer
without explicit confirmation.

Actual

The tool returned only the boilerplate for the selected option, ending:

Questions asked:
- "<the question text>"
  (No answer provided)

The typed text was not included, not referenced, and not recoverable.

The text reached no persistent store — three locations checked

1. ~/.claude/history.jsonl — all 1,047 entries examined. The session had four records in the file;

none contained the answer.

1. The session transcript (~/.claude/projects/<slug>/<session-id>.jsonl) — the rejection record

carries a userFeedback field, which is exactly where the text would be expected to appear. It
contained only the generic boilerplate quoted above.

1. ~/.claude/state/ — contains no draft, notes, or input buffer of any kind.

Timestamps place the loss at submit rather than earlier: the rejection record is stamped 19:50:34,
and the user's first message reporting the loss is stamped 19:50:54.

Precedent — the identical defect was already fixed in the multi-select path

From the shipped changelog:

"Fixed AskUserQuestion multi-select questions silently dropping a typed 'Other' free-text answer when submitting"

This report is the single-select (multiSelect: false) instance of that same failure, which appears
not to have been covered by that fix.

Two further changelog entries suggest the free-text and focus handling in this dialog has needed
repeated repair, and that this area is worth hardening rather than patching case by case:

"Fixed pressing Escape in the AskUserQuestion notes field aborting the turn instead of returning to answer selection"

"Fixed AskUserQuestion telling Claude to continue even when your answer asked it to wait or explain first — free-text answers now get neutral wording"

Why this is worse than an ordinary UI slip

The failure is silent on both sides simultaneously.

• The user believed a long answer had been submitted, and had no signal otherwise.
• The assistant received an explicit (No answer provided) and an instruction to ask what the user

wanted to clarify — so it responded by asking the question again, which read to the user as being
ignored immediately after they had written at length.

Neither party could determine what had happened without separately inspecting the transcript on disk.
A user slip caused it, but the interface offered no path by which the slip could be noticed, corrected,
or recovered — and the content it destroyed was not reproducible.

Suggested minimum fix

Do not discard a non-empty free-text buffer. Return it with the result whenever it is non-empty,
regardless of which option is selected, and let the model reconcile the ambiguity — that is strictly
better than destroying the input, and it is the behaviour already expected in the multi-select path.