[BUG] AskUserQuestion preview layout drops the auto-added "Other" free-text row — the user cannot answer in their own words

Status Open
Reported on v2.1.251
Maintainer reply None cached
Activity 0 comments · opened Aug 29, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

When a single-select AskUserQuestion question has any option carrying a preview field, the UI switches to the side-by-side preview layout. That layout builds its row list from the model's options alone. It never appends the auto-added __other__ row, so the free-text escape hatch is gone for that question.

This contradicts the tool's own description, which the model is given verbatim:

There should be no 'Other' option, that will be provided automatically.

An agent that follows that instruction — never authoring its own "Other" option, because the harness promises to add one — and that also follows the documented advice to use preview for concrete comparisons, produces a question the user cannot answer in their own words at all. The two documented behaviours are in direct conflict.

The affected code path is the split inside the question component: a question renders through the plain list component only when it is multi-select, or when no option carries a preview. The plain list component appends the __other__ input row unconditionally. The preview component does not append it, and has no equivalent row.

The only free-form path that survives in the preview layout is the n ("add notes") chord shown in the footer. That is not equivalent, for three reasons:

  1. It is not visible in the option list. A user looking for the text box sees a list that simply ends.
  2. Submitting with notes and no option selected sends the literal answer value (notes only), not the user's text. The text arrives in a separate notes field, so any agent that reads the answer value alone sees a sentinel.
  3. That path is itself already reported as lossy — see #65894, which is a different defect on the same affordance.

What Should Happen?

The side-by-side preview layout should carry the same __other__ row as the plain list layout: a final row labelled "Other" that opens a free-text input. Whatever else changes about preview rendering, a person should never lose the ability to answer a question in their own words because the agent attached a comparison pane.

Steps to Reproduce

Issue one AskUserQuestion call containing two questions, identical except for the preview field:

{
  "questions": [
    {
      "header": "Probe A",
      "question": "Do you see an Other row under these choices?",
      "multiSelect": false,
      "options": [
        {"label": "Yes", "description": "The Other row is present."},
        {"label": "No",  "description": "The list ends after these choices."}
      ]
    },
    {
      "header": "Probe B",
      "question": "Do you see an Other row under these choices?",
      "multiSelect": false,
      "options": [
        {"label": "Yes", "description": "The Other row is present.", "preview": "SAMPLE PREVIEW TEXT"},
        {"label": "No",  "description": "The list ends after these choices.", "preview": "SAMPLE PREVIEW TEXT"}
      ]
    }
  ]
}

Observed on 2.1.251: question 1 shows the "Other" row. Question 2 does not. The layout choice is per question, so both behaviours are visible in a single call.

Error Messages/Logs

No error is emitted. The row is silently absent.

Claude Model

Opus — Claude Opus 5 (claude-opus-5)

Is this a regression?

Unknown. I have not tested an earlier build for this specific behaviour.

Claude Code Version

2.1.251 (Claude Code)

Related

  • #65894 — the n notes path in this same preview layout drops the highlighted option. Different defect, same affordance. If the "Other" row were restored, that path would stop being the only free-form escape hatch in the preview layout.

View original on GitHub ↗