fix(tui): user-input modal clips options and hides typed input — fixed 22-row cap, centered overlay, no scroll, no back-navigation, undocumented

[7jrxt42BxFZo4iAnN4CX]

Problem

When the model asks a question via request_user_input, the dialog is unreliable on real terminals: content gets cut off, the underlying conversation becomes invisible, and mistakes are irreversible.

Concrete failures (reproduced on a 141×38 terminal):

1. Options are clipped. The modal is capped at 22 rows of height. A question with several options (each with a description) plus the header and hint rows overflows, and everything past the cap is silently cut off. I often cannot see which option is currently selected — the selection highlight is below the visible area.
2. Typed input is invisible. The "Custom response" input line is appended after all options in the render output. With a long question and several options it falls below the 22-row cap, so while typing I cannot see what I am writing. There is no cursor tracking and no scroll-into-view.
3. The dialog opens centered and disables transcript scrolling. The popup is vertically centered over the conversation (Layout [Min(0), Length(height), Min(0)]), and while any modal is open the event loop routes every key to the modal (view_stack.handle_key() with continue). PageUp/PageDown and the other transcript-scroll bindings never run. Questions are usually based on the on-screen conversation, so covering it and forbidding scroll forces me to answer from memory.
4. No way to go back or correct. Left/Right arrows are unhandled (_ => ViewAction::None), and there is no previous-question stack: advance_question moves forward only, and Esc in selection mode cancels the whole dialog. An accidental Enter on the wrong option is irreversible.
5. Resizing the terminal does not help. The height is desired.clamp(6, 22).min((r.height * 60 / 100).clamp(6, 22)).min(r.height) — the 22-row cap dominates for any terminal ≥ 37 rows (38 → 22, 50 → 22, 100 → 22). Smaller terminals get even less. The width is also capped at 110 columns, so on wide terminals long questions wrap into more lines and exhaust the height budget faster.
6. The modal is undocumented. No hotkey, no "Custom response" behavior, no layout expectations appear anywhere in docs/GUIDE.md, docs/KEYS.md, or the TUI docs. There is no collapse/minimize action either — Esc is the only escape, and it cancels the request.

Root cause (code)

• crates/tui/src/tui/user_input.rs:540-556 — compact_popup_rect: hard height cap clamp(6, 22) + 60% of terminal, width cap min(110), [Min(0), Length(height), Min(0)] vertical centering.
• crates/tui/src/tui/user_input.rs:205-244 — handle_selecting_key: only Up/Down/j/k, digits, Space, Enter, Esc; Left/Right and any "back" action are absent.
• crates/tui/src/tui/user_input.rs:430-450 (render) — "Custom response" line appended last; no scroll-into-view.
• crates/tui/src/tui/ui/event_loop.rs:4791-4809 — non-empty view_stack → view_stack.handle_key(key) + continue; transcript scroll handlers at ~5640+ unreachable while a modal is open.

Expected behavior

Matches how opencode handles model questions:

• Bottom-anchored sheet instead of a centered overlay, so the conversation stays visible above it.
• Scrolling works: either the transcript remains scrollable while the dialog is open, or the dialog itself scrolls internally (selected option and typed text always visible, no silent clipping).
• Back-navigation to the previous question (and a documented way to correct an accidentally submitted answer, e.g. an explicit "go back" binding rather than Esc-cancels-everything).
• Adaptive height: no fixed cap that clips content; the dialog grows or scrolls.

Related

#6003 — the same question/approval flow hardcodes a 300-second wait (USER_INPUT_TIMEOUT, crates/tui/src/core/engine/approval.rs:15; APPROVAL_DECISION_TIMEOUT, crates/tui/src/runtime_threads.rs:547) with no config or kill switch. Both issues are the same UX surface: I'd gently suggest treating them together — a dialog that clips the answer and then silently cancels it after five minutes breaks the workflow twice. Making the timeout configurable/disableable (and the dialog usable at all) is important for anyone who runs local, unattended, or review-heavy sessions.

Acceptance criteria

• On a 141×38 (and 80×24) terminal, all options and the selected highlight are visible without terminal-specific hacks.
• Typed "Custom response" text is always visible while typing (scroll-into-view or guaranteed layout position).
• The conversation transcript is visible and scrollable while the dialog is open (or the dialog is internally scrollable with the transcript preserved).
• It is possible to go back to a previous question and change an answer.
• Resizing the terminal neither clips content nor is required to reveal it.
• The modal and its keys are documented (GUIDE/KEYS), including the back-navigation binding.

[github-actions]

Thanks @7jrxt42BxFZo4iAnN4CX for the report.

This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.

If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment /lgtmi to mark recurring issue reporters as approved so this intake note is skipped next time.

[Hmbown]

Thanks — this is a genuinely well-argued report. The file:line citations made it quick to confirm each point, and the 141×38 reproduction plus the resize math (clamp(6, 22) dominating for any terminal ≥ 37 rows) is the part that makes it undeniable rather than a matter of taste.

Two housekeeping notes so this doesn't get lost:

The title reads as landed work. The fix(tui): prefix matches your PR convention, but this is a bug report — the acceptance boxes are unchecked and there's no branch or PR. Worth knowing because title-prefix triage can mis-bin it as already fixed. Not a criticism of the writing; the body is clear.

Scope. Properly fixing this is a redesign of the user-input surface, not a patch: a bottom-anchored sheet, internal scrolling with the typed line kept visible, back-navigation with a real correction path, adaptive height, and docs. That is not landing in 0.9.13, which is frozen for release — but it is exactly the kind of interaction defect that should be the first thing in the next window, and it is recorded that way rather than left to rot in the backlog.

On the details you raised, so the record is accurate:

• Point 3 is the one that concerns me most. Routing every key to the modal and continue-ing means the transcript scroll bindings are unreachable, so the dialog hides the very conversation the question is about. That is a routing decision in event_loop.rs, and it has a wider blast radius than the layout work.
• Point 5 is the strongest piece of evidence in the report — the cap dominating at every size above 37 rows shows it isn't terminal-specific.
• Your suggestion to treat this together with Make user-input / approval wait timeout configurable (and disableable) #6003 is well made. A dialog that clips the answer and then silently cancels it after a hardcoded 300 seconds breaks the same workflow twice, and they should be designed together rather than patched separately.

If you'd like to drive any of it, say so here and we'll scope it with you rather than around you — you clearly know this surface better than the current code does.

[Hmbown]

Correction to my earlier comment, and sorry for the mixed signal: the "this is not landing in 0.9.13, which is frozen for release" line was an agent's call made on my behalf, and it was wrong. This is in 0.9.13.

acfd0c9f01 replaces the centered overlay with a bottom-anchored sheet:

• No height cap. The sheet sizes to its content and reserves transcript rows above it. The clamp(6, 22) math from your point 5 is deleted, not raised — which was the right read; a bigger constant would have been the same bug later.
• It scrolls internally, and both the highlighted option and the custom-response line are kept on screen. Verified at 141×38 and 80×24.
• Left / h goes back to the previous question and pops the committed answer. Esc still cancels the whole request, so the accidental-Enter path is recoverable now.
• Transcript scroll routes through the shared view stack instead of being swallowed by the modal. That was your point 3, and you were right that it had the widest blast radius of the six.
• Documented in docs/GUIDE.md and docs/KEYBINDINGS.md.

Five new regression tests are named after your reported failures, including user_input_sheet_fits_80x24_and_keeps_selection_visible and user_input_custom_response_stays_visible_while_typing.

On #6003, which you asked be treated together with this one: [tools] user_input_timeout_seconds ships in the same release. An explicit 0 waits indefinitely, otherwise the value is clamped to 24 hours, and omitting it keeps the old 300-second default. So both halves did land together — the changelog was just late crediting the second one, which I'm fixing in the same release.

Thank you for the report. The file:line citations and the resize math are why this moved inside one window instead of aging in the backlog.

[7jrxt42BxFZo4iAnN4CX]

@Hmbown two follow-ups on the scroll half of point 3 — flagging you directly since the fix note and the shipping commit describe opposite behaviour here.

The bottom sheet itself is a real improvement: internal scroll and back-navigation both work for me on 0.9.13 from source at 89621d5.

1. The commit and the fix note say opposite things about transcript scroll.

The commit that shipped this (acfd0c9f0) says:

Transcript scroll stays with the modal (shared view_stack routing) rather than half-routing PageUp through every overlay.

while the fix note above says:

Transcript scroll routes through the shared view stack instead of being swallowed by the modal.

Only the first matches the code. handle_selecting_key (crates/tui/src/tui/user_input.rs:235) handles Up/Down/j/k, digits, Space, Enter, Esc, Left/h and falls through to _ => ViewAction::None (:275). PageUp/PageDown therefore never reach the transcript handlers — the modal branch calls view_stack.handle_key(key) and continues (crates/tui/src/tui/ui/event_loop.rs:5126 and :5140). The only modal→transcript bridge is handle_approval_transcript_key (crates/tui/src/tui/ui/handlers.rs:158), and it matches ModalKind::Approval only. There is no UserInput equivalent anywhere: the sole ModalKind::UserInput occurrences are the view's own kind() (user_input.rs:382) and a render check (underwater.rs:571).

2. Mouse wheel does nothing at all while the sheet is open — neither transcript nor sheet.

handle_mouse_event (crates/tui/src/tui/mouse_ui.rs:510) routes the wheel to the transcript for ModalKind::Approval (:525-545), then falls through to if !app.view_stack.is_empty() { return app.view_stack.handle_mouse(mouse) } (:545-548). UserInputView does not override handle_mouse, so it inherits the default ViewAction::None (views/mod.rs:1108). Net effect: the wheel is swallowed with no scroll of any kind.

Suggested fix — the wiring already exists.

• UserInputView::occupied_region is already implemented (user_input.rs:582) and returns the sheet rect including its shadow, so a hit-test needs no new geometry. top_occupied_region (views/mod.rs:1203) is generic.
• scroll_transcript_with_mouse(app, direction) is already implemented (mouse_ui.rs:823).
• The approval block at mouse_ui.rs:525-545 is a working template, including the over_side_surface guard so wheeling over the work surface does not move an unrelated transcript.
• frame.rs:1826 currently records the occupied region for ModalKind::Approval only; the same line would need to cover UserInput.

For the keyboard half, the same approval path would work if extended to ModalKind::UserInput — with PageUp/PageDown/Home/End and modified arrows routed to the transcript, while bare Up/Down stay with the sheet (in approval they do not conflict; in the sheet they are option navigation).

Separately worth fixing in the same pass: since the wheel is currently swallowed and the sheet has internal scrolling, scrolling over the sheet itself should move the sheet, and wheeling over the transcript above it should move the transcript. Right now the first case is dead too.

Not reopening anything — just recording that point 3 landed as "the transcript stays visible above the sheet" (the second half of my own acceptance wording), while the scroll bindings themselves are still unreachable, by keyboard and by mouse.

[Hmbown]

The follow-up was correct: the first fix preserved transcript visibility but did not wire the promised scroll controls. The subsequent changes on main now cover both keyboard and mouse routing, and I verified them in the complete local test suite at 9f276d8.

• PageUp/PageDown, Home/End and modified arrows reach transcript scrolling for UserInput prompts. Bare arrows continue to navigate answers, and text entry remains owned by the question.
• The painted sheet rectangle is recorded. The wheel over the sheet browses its wrapped content; above the sheet it scrolls the transcript; visible side surfaces retain their input ownership.
• Selection/custom text returns into view after browsing or resizing. Back-navigation restores the earlier question so the answer can be changed.
• GUIDE and KEYBINDINGS now document these controls.

The passing regression coverage includes user_input_prompt_keeps_transcript_navigation_and_answer_keys_separate, user_input_wheel_routes_by_painted_sheet_and_preserves_side_surface_ownership, bottom_prompts_keep_transcript_tail_visible_through_resize_and_navigation, and the sheet's wrapped-content, 80x24, 141x38, typing and back-navigation cases. These are rendered-buffer and event-routing tests; I am not claiming they constitute a new manual test in every terminal emulator.

Closing with the scroll follow-up included. These changes are in the unpublished 0.9.13 candidate; release-wide CI/publication are still pending. Thank you @7jrxt42BxFZo4iAnN4CX for catching the mismatch between the earlier fix note and the code.