[Feature]: Collapsible composer so the thread is readable while a question or approval is pending

[AaronAbuUsama]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

The composer has no way to get out of the way. When it grows — a pending user-input / ask-user card with several options, a pending approval, a long draft, attachments — it eats a large share of the thread viewport, and the conversation above it is what I actually need to read in order to answer it.

Concretely, when an agent asks a question I want to scroll back through what it just did and decide from that. Today the panel that renders the question is pinned at full height (apps/web/src/components/chat/ComposerPendingUserInputPanel.tsx, rendered from ChatComposer.tsx) — neither file has any collapse affordance or max-height, so the only way to see more of the thread is to scroll a shrunken viewport a few lines at a time.

The Claude Code desktop app handles this well: the input box can be collapsed to a thin bar, the full thread is visible behind it, and expanding it restores exactly what was there.

Proposed solution

A collapse toggle on the composer:

• A chevron / caret in the composer header (and a keyboard shortcut) collapses it to a single slim bar showing just enough state to know why it's there — e.g. "1 question pending", "Draft (3 lines)", "Approval pending" — plus the expand affordance.
• Collapsed state reclaims the full height for the message list, so the thread scrolls normally behind it.
• Expanding restores the exact prior state: draft text, selected radio/checkbox answers, attachments, scroll position within the panel. Collapsing must never discard a draft or a selection.
• State is per-thread and remembered while the thread is open. A new pending request should auto-expand (or at least flash the bar) so a collapsed composer can't hide a question the agent is blocked on.

Why this matters

The composer is the single biggest fixed-height element in the chat view, and it is largest exactly when the thread content matters most — when the agent is blocked on you and you need to review the context before answering. Right now answering a question means answering it half-blind, or losing the question off-screen while you scroll. This affects every user on every ask-user / approval interaction, and gets worse on small windows and split layouts.

Smallest useful scope

A single collapse/expand toggle on the web composer that preserves draft + selections, with no persistence across reloads and no keyboard shortcut. That alone solves the "I can't read the thread while a question is pending" problem.

Alternatives considered

• Resizing the window / maximizing the panel — doesn't help; the composer scales with it.
• Scrolling the message list — technically possible, but the usable viewport is a few lines tall when a multi-option question is pending.
• A max-height with internal scroll on the pending-input panel — cheaper, but it only caps the worst case; it still can't get the composer out of the way.
• Prior art: Claude Code desktop's collapsible input box.

Risks or tradeoffs

• A collapsed composer must not hide a pending request the agent is blocked on — hence auto-expand (or a clearly-labelled bar) on a new request.
• Draft/selection state must survive the collapse; losing a half-filled answer would be worse than the current behavior.
• Same problem exists on mobile, where the viewport is smaller still (see [Bug]: Mobile request_user_input card overflows the viewport and cannot be scrolled #5009 — mobile request_user_input card overflows the viewport), but the interaction there probably wants a different shape (sheet/drag handle) rather than a straight port.

Contribution

• I would be open to helping implement this.

[dtown123]

bad comment pls ignore

[AaronAbuUsama]

I think this comment is meant for another thread ser

[dtown123]

Ah crap, sorry, too many tabs

[Vantrongs]

Part of this has landed since: the question card collapses to its header with the chevron, and on desktop the composer rests to a single line when you scroll the thread up (#7855, #10437). Two of the cases above still keep it at full height, though:

1. A pending question. The composer treats it as expanded chrome (pendingUserInputs.length > 0 → showComposerTopDrawer → composerHasExpandedChrome), so a scroll never rests it, even after I collapse the question card to its header. The card shrinks, but the answer field and the footer stay full height.
2. A multiline draft. hasMultilinePrompt blocks resting (fix(web): preserve multiline composer drafts during timeline scrolling #10444), so a draft of a few lines keeps the composer tall while I scroll back to check something before sending.

#10444 keeps multiline drafts open so they're easy to review and edit, which makes sense while I'm typing. A rule that keeps that and covers both cases: decide by where focus is when the scroll happens.

• Focus outside the composer (I clicked on the thread, e.g. on message text) and I scroll up → rest the composer as usual. A multiline draft shows its first line, the way a single-line draft does now; a pending question shows its header row.
• Clicking back into the composer expands it with the draft, caret and selected answers intact.
• Caret in the composer → scrolling the thread, e.g. back through the agent's messages, doesn't rest it, so a draft or an answer I'm writing stays open while I check something above.

This doesn't bring back collapse on blur (#10437): losing focus alone changes nothing, it only decides what a scroll does.

The pending-question case is filed as a bug: #14231.

Code references are to main @ d2c9281.