fix(web): collapse the resting composer#7855

While resting the footer becomes an absolute overlay, but the prompt row only reserves pr-12 (48px) — exactly the compact send button plus px-2. The right action group still renders inlineTasksBadge / inlineStashBadge (lines 3448-3449), and those are reachable in a resting state: they only need externalDrawerAttached (composer banner items or an active thread sync in ChatView), which is not part of hasExpandedChrome. The inline tasks badge alone ("Tasks" + segments + n/m + dismiss) is well over 48px, and the overlay has no background, so it lands on top of the prompt text/placeholder.

Consider suppressing the inline badges while resting (or counting them as expanded chrome) so the reserved padding stays truthful:

^{Posted via Macroscope — UI Consistency}

🟡 Medium chat/ChatComposer.tsx:143

previousHeightRef retains the height from the last isResting transition, so growing the composer while it remains expanded and then blurring animates from the current tall height to that stale value, causing a visible jump before collapse. Keep the previous height synchronized with layout/resize changes rather than updating it only in this effect.

✅ Resolved in 2ee2ae14a2b7e02915fa86474be8eff57bae2562

chat/ChatComposer.tsx:190

previousHeightRef is only refreshed when isResting flips, so it is stale whenever the expanded height changed in between — e.g. focus the composer (measured at ~1 line), type a multi-line draft, then click away. The collapse then animates from the old, shorter height, so the surface snaps down by the draft's extra height in a single frame before the 180ms animation plays, which is exactly the flow this PR targets.

Consider keeping the measurement fresh, e.g.:

No longer relevant as of 2ee2ae14a2b7e02915fa86474be8eff57bae2562

chat/ChatComposer.tsx:2517

isComposerFocused is true for focus anywhere in the form, so a wheel gesture can scroll-collapse the composer while focus sits on a footer control (model picker trigger, runtime-mode select, plan toggle). Collapsing applies hidden to the group that owns that focused button (line 3567), so the browser drops focus to <body> — and since focus is then outside the form, neither onKeyDownCapture nor onFocusCapture can un-collapse it, leaving keyboard users stuck. Until now the resting layout could never hide a focused control because it required !isFocused.

Suggest only collapsing when the prompt editor itself holds focus:

No longer relevant as of 2ee2ae14a2b7e02915fa86474be8eff57bae2562

🟡 Medium chat/ChatComposer.tsx:2602

In an idle desktop thread without the branch context strip, restingControlsHost is null while isComposerResting still becomes true, so the footer hides composerControls and the model, runtime-mode, and traits controls disappear. Gate the resting state on restingControlsHost (or mount the host independently) so controls remain rendered until they have a portal destination.

✅ Resolved in 4ec84ebb2e61b8b41eab6c1f3416d5628a27a5f9

Resting controls vanish without host

High Severity

When the composer is resting, footer model/traits/mode controls are hidden and only reappear via a portal into restingControlsHost. That host only exists when BranchToolbar mounts under showComposerContextStrip. If the strip is absent (non-git primary-only projects, or toolbar returns null), resting hides those controls with nowhere to render them.

^{Reviewed by Cursor Bugbot for commit c80648642a71f9a418520dc8a77ea9b949e80413. Configure here.}

Picker remounts on resting open

Medium Severity

Opening the model picker from the resting strip sets isComposerModelPickerOpen, which clears resting and moves composerControls from the toolbar portal back into the footer. That fully remounts ProviderModelPicker under a new trigger while open is already true, so the popover jumps from the strip to the expanding footer (and can flicker or briefly lose its anchor).

^{Reviewed by Cursor Bugbot for commit c80648642a71f9a418520dc8a77ea9b949e80413. Configure here.}

chat/ChatComposer.tsx:3850

When restingControlsHost is null the resting layout still hides the inline footer controls here (and renders null at line 3853) while the portal at line 3367 renders nothing — so the model picker, plan/build toggle and runtime-mode select disappear from the UI entirely until the user clicks into the composer.

This is reachable: BranchToolbar is the only host and it is gated by showComposerContextStrip, i.e. hasActiveProject && (isGitRepo || showEnvironmentIndicator), which is false for a non-git project folder with a single primary environment.

Consider feeding host availability into the resting decision (e.g. an extra hasControlsHost: restingControlsHost !== null input to shouldUseRestingComposerLayout) so the composer only rests when it has somewhere to put its controls.

No longer relevant as of 4ec84ebb2e61b8b41eab6c1f3416d5628a27a5f9

chat/ComposerControl.tsx:9

Dropping h-7 min-h-7 px-2.5 hands geometry back to buttonVariants, but the default here is size="sm" = h-8 gap-1.5 px-[calc(--spacing(2.5)-1px)] sm:h-7. Below sm every existing composer control (model picker, plan/build toggle, runtime select) now renders 32px tall instead of 28px, so the mobile footer this PR otherwise preserves changes height.

Same pattern for ComposerControlChevron (lines 45-51): the new size-3 + opacity-50 default also applies to the expanded composer, replacing the semantic text-icon-muted token with an opacity hack, while the newly added className param is never passed by any caller.

Consider keeping the previous defaults and opting into the smaller/muted resting treatment per size — e.g. size === "xs" ? undefined : "h-7 min-h-7" inside ComposerControl/ComposerSelectControl, and passing the resting chevron tone through the new className prop.

No longer relevant as of 4ec84ebb2e61b8b41eab6c1f3416d5628a27a5f9

The host is visible from md up, but the composer's resting layout starts at sm: BranchToolbar uses useIsMobile() (max-md) for its mobile row, while ChatComposer derives isMobileViewport from useMediaQuery("max-sm").

Between 640px and 767px the composer therefore rests, the inline footer controls get hidden, and this portal target is display: none — the model picker, plan/build toggle and runtime select are neither visible nor reachable (the measurement hook also bails out on clientWidth === 0). That window is easy to hit in a narrow Electron window or split view.

Consider making the two breakpoints agree: gate the resting layout on max-md as well, or expose this host (and a strip layout that fits it) from sm up.

^{Posted via Macroscope — UI Consistency}

components/BranchToolbar.tsx:539

overflow-hidden clips both axes, and this host is only as tall as its content (the strip is items-center, controls are h-7 sm:h-6), so the focus-visible:ring-2 ring-offset-1 that buttonVariants paints outside the box on the portaled resting controls — plus the provider icon's negatively offset badge — gets cut off top and bottom. The strip itself already uses overflow-x-clip overflow-y-visible for exactly this reason; using the same pair here keeps the horizontal clipping while letting the ring render.

No longer relevant as of 1b0fbc813b154216177bea1e38ee089e3d54f3ef

New threads can rest on blur

Medium Severity

shouldUseRestingComposerLayout never checks whether the composer is on an existing server thread. Scroll-collapse correctly requires routeKind === "server", but blur resting only needs a controls host, so draft and new-thread composers with a context strip still collapse to the single-line layout when unfocused, contradicting the PR and docs that keep the full composer for new threads.

^{Reviewed by Cursor Bugbot for commit 4ec84ebb2e61b8b41eab6c1f3416d5628a27a5f9. Configure here.}

🟡 Medium chat/ChatComposer.tsx:2706

When the resting composer’s model picker is opened, isComposerResting remains true, so the portaled popup appears while the editor/footer stays clipped to the 50px resting layout; the timeline scroll-collapse listener also remains active. Include isComposerModelPickerOpen in composerHasExpandedChrome so opening the picker expands the composer and disables scroll collapsing.

This is intentional. Expanding here moves the trigger out of the resting portal and remounts it while the popover is open, which destabilizes the popup anchor. The popup itself renders through PopoverPrimitive.Portal, so it is not clipped by the resting composer. The scroll-collapse handler also requires the contenteditable editor to be the active element; opening or interacting with the picker moves focus away from the editor, so wheel events cannot collapse it further.

chat/ComposerControl.tsx:12

The xs chevron's -me-1 is silently dropped inside the Button-based composer controls: buttonVariants ships [&_svg]:-mx-0.5 in its base, which emits .\[\&_svg\]\:-mx-0\.5 svg (specificity 0-1-1) and out-specifies the chevron's own -me-1 (0-1-0). So ProviderModelPicker.tsx:195 and the traits trigger (TraitsPicker.tsx:550, :556) keep margin-inline: -2px, while ComposerSelectControl (SelectTrigger, whose variants carry no [&_svg] margin) does get the intended -4px end tuck — the resting row ends up tucking its chevrons inconsistently by 2px. This regressed when [&_svg[data-composer-control-chevron]]:-mx-0.5 was dropped from composerControlClassName, which used to own chevron margin from the control class at higher specificity. Consider re-owning it there; note ComposerControl.test.tsx:37 only asserts the class string, so it cannot catch this.

No longer relevant as of ba6cd2a74e59b68415dfd5a929c10eb60ad7be86

chat/ChatComposer.tsx:2916

Every other control in the resting row is scaled to the new xs contract (ComposerControl/ComposerSelectControl → h-7 sm:h-6, ComposerControlIcon size="xs" → 12px), but the overflow trigger is CompactComposerControlsMenu, whose trigger is a hardcoded Button size="sm" with a size-4 ellipsis (h-8 sm:h-7, px-2). Resting is desktop-only, so the sm: values apply: the moment a block overflows, this 28px/16px trigger lands in a 24px/12px row that the host and the strip lay out with items-center, so the context strip grows ~4px taller and the icon is visibly a step larger than its siblings.

Smallest fix is to let the menu take the size it is rendered at — add a size prop to CompactComposerControlsMenu (default "sm", rendered through ComposerControl so the xs geometry/treatment stays owned by the primitive) and pass size="xs" from this resting-overflow call site.

No longer relevant as of abd8c56e3390ae4e7676d464464ded3d368658e1

Resting badge loses instance identity

Medium Severity

For size="xs", the resting model trigger sets badgeContent to "none" and shrinks the chip while still showing the badge whenever shouldShowInstanceBadge is true. Same-driver instances without an accent lose the initials that previously identified them, and the trigger label only shows the model name, so those instances become indistinguishable while resting. The size-3 sidebar path avoids empty chips unless an accent is present and puts the instance name in adjacent text instead.

^{Reviewed by Cursor Bugbot for commit abd8c56e3390ae4e7676d464464ded3d368658e1. Configure here.}

chat/ProviderInstanceIcon.tsx:43

data-provider-instance-icon has no reader anywhere in the repo — no CSS rule, no Tailwind arbitrary variant, no querySelector, no test. The same holds for data-chat-provider-model-picker-content added in ProviderModelPicker.tsx:167; the resting row measures [data-chat-provider-model-picker] (the trigger) and tints the glyph through activeProviderIconClassName instead.

Consider dropping both attributes, or wiring them to the rule/measurement that needs them, so a shared primitive used across the sidebar, command palette and settings does not ship a selector surface nothing owns.

No longer relevant as of 08ac5ab81a551317c83307215f29a78cffa4496c

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

chat/ComposerControl.tsx:43

The new resting/expanded split only has two branches (xs vs everything else), but size is typed as the full buttonVariants union here and on ComposerControl, ComposerControlChevron and ComposerSelectControl (and forwarded that way from ProviderModelPicker and TraitsPicker). Any other real size — compact, micro, icon-xs — silently lands in the expanded branch, where expandedComposerControlClassName (h-7 min-h-7 gap-1.5 px-2.5) then overrides the variant's own height/padding instead of the mismatch being caught.

ComposerFooterModeControls and CompactComposerControlsMenu already narrow to "sm" | "xs"; consider using that same type across these primitives and the two pickers so the size contract cannot be mis-set. (Left without a suggestion block since it has to change in all four places plus the two picker prop types at once.)

No longer relevant as of 08ac5ab81a551317c83307215f29a78cffa4496c

The badge no longer fits the glyph it is supposed to annotate. At xs the icon box is 12px while the badge is at minimum 10x10 (h-2.5 min-w-2.5, and two 6px initials plus px-px + 1px border push the width to ~11-12px) offset only 1px outward, so it covers roughly 70% of the 12px provider mark — the resting trigger stops showing which provider is active. At sm the same badge is 12px over a 16px glyph offset 2px outward, i.e. ~40% coverage, which is why the expanded trigger still reads.

The resting row is 24px tall, so the glyph does not need to shrink: keeping it at 16px lets one badge contract serve both sizes and preserves instance identity.

Separately, indicatorBackground now infers a surface (var(--background)) from a geometry prop. The surrounding surface is a call-site concern (and the strip is a translucent glass surface, not --background); consider passing it explicitly from ChatComposer alongside activeProviderIconClassName.

^{Posted via Macroscope — UI Consistency}

Fixed in 08ac5ab81. The resting picker keeps the established 16px glyph / 12px initials badge pairing within the 24px row, and the badge surface is now supplied explicitly by ChatComposer instead of inferred from size.

components/BranchToolbar.tsx:270

Skipping the host here also drops it from the strip's compact decision, so the strip will never collapse its labels to make room for the resting controls — and the host is the one child that can be starved to zero.

At md+ the host is the only flex-1 child (BranchToolbar.tsx:538, flex: 1 1 0% + min-w-0), so its base size is 0 and it only ever gets leftover space. needed now counts the env group and the branch selector plus stripGap * (groups - 1) — with the host skipped, groups drops to 2, so only one of the strip's two flex gaps is counted. When env + branch content lands in the resulting band (available - 8 < content <= available - 4), nextOverflows stays false, the labels stay expanded, and the host is laid out 0–4px wide.

That state is not self-correcting: ChatComposer only checks restingControlsHost !== null and the 48rem viewport before switching to the resting layout (ChatComposer.tsx:2711), which applies hidden to the inline footer controls, and useRestingComposerControlsLayout.measure() bails at currentHost.clientWidth === 0, so it cannot even fall back to the overflow menu. The model picker, plan/build toggle and runtime-mode select are then clipped away by the host's overflow-x-clip until the user focuses the composer. Because the strip is width-capped (max-w-[calc(48rem-2.75rem)]), a particular branch/environment label combination can sit in that band persistently rather than only during a resize.

Smallest fix: reserve a floor for the host so the strip compacts instead of starving it — give the host a min-w-* and add that reserved width plus the missing gap to needed here — or have hasAvailableRestingControlsHost treat a sub-threshold measured host width as "no host" so the composer stays expanded.

No longer relevant as of 83f44c8b6b1f7bb3e3417e9d16e1f9f98ddd68ed

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🟡 Medium chat/ChatComposer.tsx:457

hiddenCount can remain too low at narrow widths, leaving a visible resting control clipped instead of moving it into the overflow menu. getBoundingClientRect().width measures the flex item's already-shrunk border box, and fixedWidth also excludes the separator's mx-0.5 margins; measure each block's intrinsic width and include those margins in the required width.

No longer relevant as of e529356e7b88dcda38246f137af01e83c2dccfcb

File-integrity note rather than styling: tooling that scans this blob byte-for-byte reports a NUL (0x00) at ~offset 89755, which lands on the comment / useEffect lines a few rows above this one (≈1743-1745). The merge base has no such byte, and git's own binary heuristic only sniffs the first 8 KB — so diffs and CI stay quiet while grep-class tools stop searching the file mid-way (matches after ~line 1742 become invisible).

Worth confirming with grep -c $'\0' apps/web/src/components/chat/ChatComposer.tsx and re-typing the affected line if it is there, so the file stays plain text for grep/blame/lint.

^{Posted via Macroscope — UI Consistency}

Checked byte-for-byte. The file does contain six NUL bytes, but the same six bytes exist in merge base e67074f80933a27bd3cdc4e24f486358407690fb and in freshly fetched upstream/main. Blame assigns the affected attachment-key lines to 200fa826b0. This PR did not introduce them, so I am leaving that unrelated pre-existing serialization cleanup out of scope.

The merge-base inference in the failed check is incorrect: the immutable e67074f8 blob contains six NUL bytes at offsets 82021, 82040, 82417, 82441, 86117, and 86127; freshly fetched upstream/main contains the same six. Commit 200fa826b0 contains six and its parent contains zero. Nonetheless, 627e5a083 now spells all six as escaped \0 source literals, preserving the runtime separator values while making the source plain text. The working-tree count is zero, and a full apps/web/src source scan found no other non-binary source files with this byte class.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

This static label hand-mirrors buttonVariants size="xs" (the interactive branch below it, line 140) but drops sm:text-xs. The mobile row renders up to md, so between 640px and 767px the locked label reads 14px while the same control unlocked reads 12px. The other two locked labels in this family do include it (BranchToolbarEnvironmentSelector.tsx:52, BranchToolbarEnvModeSelector.tsx:54), so this looks like drift rather than intent.

^{Posted via Macroscope — UI Consistency}

This descendant rule takes font-weight ownership away from the primitives without doing any work. It compiles to .…:font-normal [data-composer-context-control] { font-weight: 400 } (specificity 0-2-0), which beats a control's own font-medium utility (0-1-0) — including buttonVariants' base weight on any tagged trigger. All six tagged elements today either set font-normal themselves (BranchToolbarEnvironmentSelector.tsx:52/:85, BranchToolbarEnvModeSelector.tsx:54/:88, BranchToolbarBranchSelector.tsx:762) or carry no text (the separator and the resting host), and the strip's own font-normal on the line above already inherits — so the rule changes nothing now and only leaves a trap for the next tagged control that wants a heavier label.

Consider dropping it and letting each control own its weight:

^{Posted via Macroscope — UI Consistency}

🟡 Medium chat/ChatComposer.tsx:2993

Changing from one desktop server thread to another leaves composerScrollGestureRef carrying the previous thread's accumulatedDeltaPx and collapseSuppressed values, so the first wheel event in the new thread can collapse or suppress its composer based on the old thread's gesture. Include the active thread identity in this effect's dependencies so its cleanup resets the gesture state during navigation.

✅ Resolved in 184017997ec1d003da12709bdcfb933f10c4a3a2

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🟢 Low user/composer.md:16

Narrow web layouts do not keep the full composer: at max-sm, an unfocused composer collapses to the prompt row and hides the editor/footer. This sentence incorrectly describes that existing mobile behavior as full-sized; distinguish the desktop resting layout from the mobile collapse behavior.

✅ Resolved in 184017997ec1d003da12709bdcfb933f10c4a3a2

Existing threads animate from expanded

Medium Severity

Existing-thread composers cannot render in the resting layout on first paint. hasLayoutSpace starts as false and restingControlsHost is filled only after the toolbar ref commits, so isComposerResting is false for the first layout. useComposerRestingTransition records that expanded height and then animates to 50px over 180ms. Opening or landing on an existing thread shows the full composer collapsing instead of already sitting in the compact resting state.

^{Reviewed by Cursor Bugbot for commit 99005c13af1b3e3ee7d717ea6aca4c8b8ff6cd49. Configure here.}

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Document the attachment opt-out.

The PR objective says attachments retain the full composer. This sentence says the prompt can enter the resting state while attachments remain present. State that attachments keep the composer expanded, or align the implementation with this documentation.

🟡 Medium chat/composerEventScope.ts:3

Unrelated portaled SelectPopup and MenuPopup elements are treated as composer floating layers, so ChatComposer keeps isComposerFocused set when focus moves into those controls and remains expanded after focus leaves the composer. The generic [data-slot] selectors match every application popup; scope these selectors to a composer-owned marker, as the drawer selector already does.

✅ Resolved in 653c8b8d68900af927006a2641fa34e98919b5cc

Open picker remounts on rest

Medium Severity

canScrollCollapseComposer ignores an open ProviderModelPicker, so a focused composer can rest mid-pick. Resting unmounts composerControls from the footer and remounts them through the toolbar portal with open still true, which closes or teleports the menu.

^{Reviewed by Cursor Bugbot for commit 6878d6d595ec9df6dc89b861a83932c04865dfc1. Configure here.}