AskUserQuestion option previews truncate ('N lines hidden') with no way to expand or scroll

Status Open

Maintainer reply None cached

Activity 3 comments · opened Jul 16, 2026

Description

When the model calls the AskUserQuestion tool with options that include multi-line preview content, the TUI renders a side-by-side layout (option list on the left, preview box on the right). If the preview content is taller than the box, it is cut off with a marker like:

── ✂ ── 8 lines hidden ──

There appears to be no way to reveal the hidden lines while the dialog is open.

What I tried

ctrl+o (transcript viewer) — the general "expand" binding; does not apply inside the open dialog
ctrl+e — only works inside the transcript viewer, not in the dialog
arrow keys — move the option selection, do not scroll the preview
mouse wheel — scrolls the terminal scrollback, not the preview box
The dialog footer hints "press n to add notes", but shows no hint for expanding the preview

I also checked the docs — the interactive-mode reference, the keybindings reference, and the changelog contain no binding for expanding or scrolling a preview inside the question dialog, so this looks like a genuine gap rather than an undocumented shortcut.

Why it matters

Previews exist precisely so the user can compare concrete alternatives (code snippets, UI mockups, config variants) before answering. When all but the first line is hidden, the user is asked to choose between options they cannot read. In practice this pushes users to answer blind, cancel the dialog, or ask the model to re-print the options as plain chat text — defeating the purpose of the preview feature.

Expected behavior

One (or more) of:

A key to expand or scroll the focused option's preview, advertised in the dialog footer next to the existing hints
Auto-sizing the preview box up to the available terminal height
At minimum: documenting the limitation (and any workaround) in the interactive-mode / keybindings docs

Steps to reproduce

Have the model call AskUserQuestion with a single-select question whose options contain preview strings of ~10+ lines
Observe the preview box renders only the first line plus ── ✂ ── N lines hidden ──
Try to expand or scroll the preview — no key or mouse interaction reveals the hidden lines

Environment

Claude Code v2.1.211
Linux (devcontainer), interactive terminal session

View original on GitHub ↗

3 Comments

spaceriqui · 3 months ago

commenting so it doesn't auto close, although this is a bug but tagged as enhancement.

Here's a good writeup: https://github.com/anthropics/claude-code/issues/38674

dgutson · 1 month ago

Still reproducible on 2.1.251 (Linux).

Adding the measurable part, which I don't think has been stated in the thread and which anyone can check by resizing the window while a dialog is open — the pane re-renders live:

Visible preview lines ≈ terminal rows − 26. Everything past that is dropped and replaced by the ✂ — N lines hidden rule.
The preview hard-wraps at ≈ terminal columns − 34, because the option list to its left occupies a fixed-width column.

The second point seems underweighted here. Since the inset is fixed rather than proportional, a narrow terminal spends two or three lines on a paragraph that would take one at full width — so the count of hidden lines grows considerably faster than the shortfall in rows would suggest. On an 80-column terminal a preview can be more than half hidden. The practical consequence is that widening the window is currently a more effective workaround than making it taller, which is neither intuitive nor discoverable from the UI.

Worth noting for anyone proposing a fix: the pane appears to carry no scroll state at all, and ↑/↓ are already spoken for by the option list, so there is no free key to scroll with. Options that avoid a new mode:

ctrl+u / ctrl+d (or shift+↑/↓) scrolls the preview, leaving ↑/↓ on the options.
A key that opens the full preview in $PAGER or $EDITOR — the same move ctrl+g already makes for the notes field.
Don't hard-truncate: let the preview take the height it needs and scroll the dialog as a whole.

(2) alone would close the hole, and the content is already formatted and in memory.

One process note: this is the fourth report of the same thing. The original, #62362, was auto-closed as stale in May rather than resolved, and #82086 and #88657 followed. The duplicate count here is mostly an artefact of that auto-close, not four independent discoveries.