feat(web): attach composer state drawers#7150

components/ChatView.tsx:4467

Same override as ComposerPendingApprovalActions: size="xs" keeps sm:h-6/sm:text-xs through twMerge, so this banner action is 24px/12px at sm and up rather than the 20px/11px intended here. Suggest switching to the shared micro button size once it exists instead of re-specifying height, padding, and font size per call site.

No longer relevant as of deb67121f12bddcbe8e8a6e48a776981b513fca7

chat-composer-drawer-attached has no definition anywhere: index.css only styles .chat-composer-drawer-surface / .chat-composer-top-drawer, and no :has(), query selector, or theme rule references it. It is emitted at four call sites and asserted in four tests, so the tests currently lock in a no-op string.

Either drop it (and the assertions), or give it the attachment geometry it appears to be named for — the w-[calc(100%-2.75rem)], mb-[calc(-1rem-1px)], pb-6 trio duplicated here and in ComposerBannerStack, which .chat-composer-top-drawer already owns in CSS. One owner for the seam geometry would keep the drawers from drifting apart.

^{Posted via Macroscope — UI Consistency}

Fixed. The attached drawer class now owns the shared attachment geometry in index.css.

chat/ChatComposer.tsx:2713

With the footer now returning null whenever isComposerApprovalState is true, this showCancel={false} leaves the desktop approval state with no way to abort the turn: the previous footer row had "Cancel turn", and the stop button in ComposerFooterPrimaryActions is no longer rendered either (there is no keyboard interrupt binding). Decline only rejects the single tool call. Suggest keeping the cancel action in this compact row (it already fits the mobile branch below) unless the interrupt path is intentionally moving elsewhere.

No longer relevant as of fc5c94b7ca26c3defda146fbb7bbe61d5db79e00

chat/ComposerPendingApprovalActions.tsx:27

size="xs" also emits sm:h-6 and sm:text-xs, and twMerge only drops the unprefixed h-7/text-sm from the same groups — the sm:-prefixed ones survive. So at sm and up these buttons render 24px tall with 12px text instead of the intended 20px/11px, which is exactly the viewport where the new desktop approval drawer row is shown.

The same h-5 px-1.5 text-[11px] geometry override is now repeated four times in this file and once in ChatView.tsx, and it also overrides the variant's base and hover text colors (text-foreground, text-destructive-foreground, whose hover override races ghost-muted's own [:hover,[data-pressed]]:text-foreground in emitted-CSS order rather than being deduped).

Consider putting this durable geometry in components/ui/button.tsx as a named size next to icon-micro (e.g. micro: "h-5 gap-1 rounded-md px-1.5 text-[11px] font-normal"), plus a ghost destructive tone for Decline, and keep only layout/context classes at the call sites. That also removes the sm: leak.

No longer relevant as of deb67121f12bddcbe8e8a6e48a776981b513fca7

chat/ChatComposer.tsx:153

These two constants hardcode in px what index.css expresses in rem: the drawer surfaces are width: calc(100% - 2.75rem) (1.375rem per side) and overlap by --chat-composer-attachment-overlap: calc(1rem + 1px). appearanceFonts.ts sets root.style.fontSize from the interface font-size preference, so at any non-default size the portaled command/stash drawer no longer matches the width or the seam of the attached drawers (the strip rule right below has a comment about deliberately staying in rem for this reason). Suggest deriving both from the root font size:

No longer relevant as of deb67121f12bddcbe8e8a6e48a776981b513fca7

🟡 Medium

https://github.com/pingdotgg/t3code/blob/fc5c94b7ca26c3defda146fbb7bbe61d5db79e00/apps/web/src/components/chat/ChatComposer.tsx#L2691

File-tree mentions are not inserted when dropped over the top drawer in plan follow-up state, because the drawer is outside the element that receives composerMentionDragHandlers. The drawer still appears to be part of the composer, so attach the drag handlers to a wrapper that contains both the drawer and main surface.

✅ Resolved in deb67121f12bddcbe8e8a6e48a776981b513fca7

🟡 Medium chat/ComposerStashBadge.tsx:27

aria-expanded="false" remains false after onToggleMenu opens the stash menu, so assistive technologies report the visible popup as collapsed. Pass the actual isStashMenuOpen state through ComposerStashBadge (replacing the removed menuOpen prop) and use it for aria-expanded.

✅ Resolved in 5cc14855f9c5202274881bc5315e8e6b82120513

Stash trigger ignores open state

Low Severity

The stash tab hardcodes aria-expanded to false after dropping the menuOpen prop. When the stash menu is open, assistive technology still reports the control as collapsed, so the disclosure state is wrong.

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

Approval actions overflow expanded composer

Medium Severity

The expanded approval row puts the full command and all four actions in one non-wrapping flex line inside the narrower top drawer. Focusing the composer on a small screen leaves the stacked, wrapping mobile layout and uses this row instead, so Always allow this session and the other actions can overflow or crowd the command out of reach.

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

chat/ChatComposer.tsx:2704

The approval actions used to sit in their own flex flex-wrap footer row; here they are a shrink-0 sibling on a single line, and .chat-composer-top-drawer has no overflow clip. The four buttons now min out around 310px (Always allow this session alone is ~145px at text-[11px]), while the drawer is only composer width - 2.75rem wide, so once the composer narrows (right panel plus terminal open — the footer's own compact breakpoint is 620px) the buttons spill past the drawer's rounded edge instead of wrapping. Adding flex-wrap lets the button group drop to a second line once the command column is squeezed out.

No longer relevant as of deb67121f12bddcbe8e8a6e48a776981b513fca7

chat/ComposerCommandMenu.tsx:155

Hardcoding text-foreground on the label breaks the highlighted row's color pairing: the row sets bg-accent! text-accent-foreground! (line 135), but a child's own color declaration wins over the inherited one, so the label keeps --foreground on an --accent background. --accent-foreground is contrast-solved against --accent per theme (themePalette.ts readableThemeForeground / updateThemeColorFamily("accentSurface") can return pure white/black while text stays the other polarity), so a custom palette can render this label near-unreadable when highlighted. The description span next to it already carries its own muted tone, so the label can simply inherit.

No longer relevant as of deb67121f12bddcbe8e8a6e48a776981b513fca7

Stash delete blocked on touch

Medium Severity

The stash delete control stays pointer-events-none until hover or focus-within. Row onMouseDown calls preventDefault, so a tap never focuses the row or produces hover. On touch, the hit target stays the restore row, so users cannot delete a stashed prompt from the drawer.

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

🟡 Medium src/index.css:1446

Warning chat-composer-top-drawer[data-variant="warning"] elements always receive --chat-composer-attached-outline from this theme rule, so their warning-colored border is replaced with the ordinary themed outline whenever data-theme-id is present. Exclude the warning variant from this selector (or explicitly override it) so warning drawers retain their warning border.

No longer relevant as of c2a57120390624a31b144abf77928ed0f450df1b

src/index.css:747

--chat-composer-attachment-overlap is only declared on .chat-composer-drawer-surface / .chat-composer-top-drawer (line 712) and on .chat-composer-glass-shell (line 804). ComposerBannerStack puts chat-composer-drawer-slot on its wrapper (ComposerBannerStack.tsx:109) while the surface class lives on the child Alert, and ChatView renders that wrapper as a sibling above .chat-composer-glass-shell (ChatView.tsx:6402-6413, shell at 6428) — so the variable is out of scope there. Custom properties inherit downward only, so calc(-1 * var(--chat-composer-attachment-overlap)) is invalid at computed-value time and margin-bottom resets to 0.

Result: the attached banner never pulls onto the composer, so its masked bottom 1rem + 1px band stays open over the canvas instead of being covered by the composer surface — an attached banner shows a transparent seam gap rather than joining the composer (ThreadSyncStatusPill is unaffected because it carries the surface class on the same element).

Suggest declaring the overlap on the slot itself so the value is defined wherever the geometry is used:

No longer relevant as of c2a57120390624a31b144abf77928ed0f450df1b

components/ChatView.tsx:4473

pb-[1.375rem] compensates for the attached drawer's masked seam, but this item class is applied in both attachment modes. ComposerBannerStack is now rendered with attached={false} whenever the thread-sync pill is showing (lines 6403/6410), and in that branch the same class lands on the alert-glass rounded-[22px] floating pill, leaving it with ~6px top and ~22px bottom padding.

Suggest keeping the seam compensation in ComposerBannerStack's attached branch (next to px-3 pt-2) and passing only symmetric padding from the call site.

No longer relevant as of d070c59252c99f7ed54e42f5ee4ea7c81fa27bcb

The stash tab is suppressed for the composer's own top drawer, but not for the drawers that now attach from outside it, and it is 28px tall above the composer instead of the old 12px pill overhang:

• ComposerBannerStack/ThreadSyncStatusPill use chat-composer-drawer-slot, whose negative margin ends their opaque area flush with the composer's top edge, so the tab's full -top-7 h-8 overhang paints over the banner row (right side, where its action button sits) rather than over the old 8px gap.
• Opening the stash drawer covers its own toggle: ComposerCommandMenuLayer places the portal at bottom = rect.top + overlap and inset 1.375rem per side, so the pointer-events-auto layer spans the entire tab except a ~6px sliver past the drawer's right edge. Clicking the tab to collapse it no longer works even though it still reports aria-expanded="true".

Suggest plumbing the same "a drawer is already attached above" signal ChatView computes for attached into this component and suppressing the tab in that case, and lifting the tab above the drawer layer (or shortening its overhang) so it stays clickable while the stash drawer is open.

^{Posted via Macroscope — UI Consistency}

Fixed. ChatComposer now receives the real external attachment state and hides the stash tab for both banner and sync drawers.

src/index.css:798

The warning outline is dropped under every custom theme. This rule is inside @layer components, while the theme bridge at the bottom of the file (html[data-theme-id] :is(.chat-composer-drawer-surface, .chat-composer-top-drawer), ~line 1446) is unlayered, so it wins over any layered rule regardless of specificity and resets --chat-composer-attached-outline to --app-theme-toolbar-border. With a theme active the pending-approval drawer keeps its 8% tint (the theme rule does not set --chat-composer-attached-tint) but renders the same neutral outline as the info drawer.

Suggest either exempting the variant in the theme rule (html[data-theme-id] :is(...):not([data-variant="warning"])) or routing the warning edge through a separate variable the theme bridge does not assign, so the state override survives the theme cascade.

No longer relevant as of c2a57120390624a31b144abf77928ed0f450df1b

src/index.css:798

The warning outline is dropped under every custom theme. This rule is inside @layer components, while the theme bridge at the bottom of the file (html[data-theme-id] :is(.chat-composer-drawer-surface, .chat-composer-top-drawer), ~line 1446) is unlayered, so it wins over any layered rule regardless of specificity and resets --chat-composer-attached-outline to --app-theme-toolbar-border. With a theme active the pending-approval drawer keeps its 8% tint (the theme rule does not set --chat-composer-attached-tint) but renders the same neutral outline as the info drawer.

Suggest either exempting the variant in the theme rule (html[data-theme-id] :is(...):not([data-variant="warning"])) or routing the warning edge through a separate variable the theme bridge does not assign, so the state override survives the theme cascade.

No longer relevant as of c2a57120390624a31b144abf77928ed0f450df1b

The stash tab is suppressed for the composer's own top drawer, but not for the drawers that now attach from outside it, and it is 28px tall above the composer instead of the old 12px pill overhang:

• ComposerBannerStack/ThreadSyncStatusPill use chat-composer-drawer-slot, whose negative margin ends their opaque area flush with the composer's top edge, so the tab's full -top-7 h-8 overhang paints over the banner row (right side, where its action button sits) rather than over the old 8px gap.
• Opening the stash drawer covers its own toggle: ComposerCommandMenuLayer places the portal at bottom = rect.top + overlap and inset 1.375rem per side, so the pointer-events-auto layer spans the entire tab except a ~6px sliver past the drawer's right edge. Clicking the tab to collapse it no longer works even though it still reports aria-expanded="true".

Suggest plumbing the same "a drawer is already attached above" signal ChatView computes for attached into this component and suppressing the tab in that case, and lifting the tab above the drawer layer (or shortening its overhang) so it stays clickable while the stash drawer is open.

^{Posted via Macroscope — UI Consistency}

Fixed with the explicit external drawer attachment state.

components/ChatView.tsx:4473

pb-[1.375rem] compensates for the attached drawer's masked seam, but this item class is applied in both attachment modes. ComposerBannerStack is now rendered with attached={false} whenever the thread-sync pill is showing (lines 6403/6410), and in that branch the same class lands on the alert-glass rounded-[22px] floating pill, leaving it with ~6px top and ~22px bottom padding.

Suggest keeping the seam compensation in ComposerBannerStack's attached branch (next to px-3 pt-2) and passing only symmetric padding from the call site.

No longer relevant as of c2a57120390624a31b144abf77928ed0f450df1b

src/index.css:937

This is now the only thing painting the composer fill when a top drawer or stash tab is present (the shell ::before and host ::after are display: none just above), but it is inside @layer components while .ultrathink-frame { background: transparent } (~line 2149) is unlayered — unlayered author rules beat every layer regardless of specificity.

composerFrameClassName puts ultrathink-frame on this exact [data-chat-composer-main-surface="true"] element (composerProviderState.tsx:75), so with an Ultrathink: prompt plus a pending-approval/plan drawer or a stash tab the composer loses its card fill entirely and only keeps the backdrop-filter, leaving the timeline blurrily visible through the composer body in both light and dark.

Smallest fixes: paint the split fill on the inner [data-chat-composer-surface="true"] element (which never receives composerFrameClassName), or drop the redundant background: transparent from .ultrathink-frame so the layered fill can apply. Note ::before on this element is already owned by .ultrathink-frame::before, so the fill cannot move to that pseudo-element either.

No longer relevant as of 5cc14855f9c5202274881bc5315e8e6b82120513

Approval detail grows without cap

Low Severity

The compact approval row replaced the old max-h-40 scrollable detail block with whitespace-pre and only horizontal overflow. Multiline command details can expand the top drawer without a vertical bound and push the composer down the viewport.

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

Stash badge hidden during plan

Medium Severity

ComposerStashBadge is gated on !showComposerTopDrawer, and plan follow-up now opens that drawer. Unlike approval or pending user input, plan state still allows editing and ⌘S stashing, but the badge (the only normal way to open and restore the stash) disappears for the whole plan-ready period.

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

Delete covers stash thumbnails

Low Severity

The delete control is absolutely positioned at the trailing edge and always visible on small screens. On entries with attachments, that overlay sits on top of the image thumbnails, so taps near the right edge hit delete instead of restore and the previews are hard to see.

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

Sync drawer stacks on top drawer

Medium Severity

composerBannerAttached already treats sync and composer-owned top state as competing for the same attachment seam, but ThreadSyncStatusPill still renders whenever sync is active. During syncing with a pending approval, user-input, or plan drawer, both the sync pill and chat-composer-top-drawer apply chat-composer-drawer-slot overlap, so two attached drawers stack on the composer and fight for the same inset seam.

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

Plan attachment ownership mismatch

Medium Severity

composerOwnsTopAttachment treats a ready plan as owning the composer seam, but showComposerTopDrawer only mounts the plan drawer when the mobile composer is expanded. On a collapsed mobile plan-ready thread, banners and the sync pill detach even though no top drawer is present, so status chrome floats with the wrong attached layout.

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

Plan drawer attachment state lags

Medium Severity

Plan follow-up ownership of the composer attachment seam depends on composerTopDrawerVisible, which is updated from ChatComposer in a passive useEffect. Parent ComposerBannerStack / ThreadSyncStatusPill attached flags therefore lag the actual plan drawer by at least one paint, so banners and sync can briefly fight the plan drawer for the seam (or stay detached after the drawer collapses).

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

chat/ThreadSyncStatusPill.tsx:22

The detached pill loses its edge: alert-glass only supplies a translucent --background fill plus a backdrop blur, and this branch drops the previous border border-border/60 and shadow-sm with no replacement. Over the chat canvas (also --background) the bar ends up with no visible boundary, and it is inconsistent with the sibling detached surface — ComposerBannerStack's detached branch is an Alert, whose base border (colored by the * { border-border } base rule) keeps its outline under the same alert-glass rounded-[22px] treatment.

Suggest restoring the border/shadow on the detached branch only; the attached branch draws its own outline through chat-composer-drawer-surface::before.

No longer relevant as of e47d5a4d35b18c2e62e23e26c2f4806da4030b39

🟡 Medium src/index.css:1493

In dark t3-chat, attached default drawers render a generic color-mix(...) outline while the main composer edge renders #241e28, so the seam has mismatched outlines. The dark @variant here overrides the inherited --chat-composer-outline; extend the T3-specific override to attached drawers or derive this value from --chat-composer-outline.

No longer relevant as of 2843d45cb0b2f48f8466f4e520db49e927f17838

chat/ComposerPendingApprovalPanel.tsx:34

aria-label on <code> is not exposed: <code> maps to ARIA role code, which prohibits an author-provided name, so assistive tech drops it. That was harmless before because the panel also rendered visible context (PENDING APPROVAL, Command approval requested, and the Command / File to read detail label); with all of those removed, a screen reader now reaches this drawer as a bare command string followed by Cancel / Decline / Always allow this session / Approve, with nothing stating that an approval is pending or which kind it is. The data-variant="warning" tint on the drawer is the only remaining cue, i.e. colour alone. fallbackLabel does not cover this — it only renders when approval.detail is null.

Suggest moving the name onto a container that accepts one (or adding an sr-only span with detailAriaLabel), keeping the compact row visually unchanged:

No longer relevant as of 2843d45cb0b2f48f8466f4e520db49e927f17838

chat/ChatComposer.tsx:2856

Adding !topAttachmentOccupied removes the only visible stash affordance in a fairly common state. embeddedStashBadge is only rendered inside the composer's own top drawer (pending approval / pending input / plan-ready), so when the seam is taken by an external attachment — composerBannerAttached && composerBannerItems.length > 0 or the thread-sync pill — nothing renders the badge at all, and both the click target and the stash count disappear.

That is not a rare state: backgroundLivenessBannerItem (ChatView.tsx:4454) keeps a Monitoring / N agents working banner up for the whole time a thread has background liveness, and woke-thread / branch-mismatch / system banners behave the same way. The only remaining route is ⌘S with an empty composer (stashCurrentPrompt falls through to setIsStashMenuOpen), which is undiscoverable.

Suggest keeping a badge in this case rather than dropping it — e.g. render embeddedStashBadge inside the composer surface (or hand it to the occupying banner as trailing content) when topAttachmentOccupied is true, so the tab is only traded for an inline badge, never for nothing.

No longer relevant as of 2843d45cb0b2f48f8466f4e520db49e927f17838

src/index.css:1499

This bridge hardcodes the outline instead of preferring the composer's own edge token, so per-theme overrides of that edge no longer reach the attached drawers. The layered default is --chat-composer-attached-outline: var(--chat-composer-outline, …), which in-shell drawers (.chat-composer-top-drawer) inherit from .chat-composer-glass-shell; this unlayered rule replaces that indirection with a fixed value.

Concretely, under html[data-theme-id="t3-chat"] in dark mode the composer edge is #241e28 (line 1506, explicitly chosen over the derived value), while the drawer attached directly to it resolves to color-mix(in srgb, var(--app-theme-input) 30%, var(--background)) — two different edge colors meeting at the seam that is supposed to read as one surface.

Keeping the indirection with the theme value as the fallback preserves the out-of-shell/portaled drawers (banner stack, sync pill, command and stash menus) that genuinely need it:

No longer relevant as of 2843d45cb0b2f48f8466f4e520db49e927f17838

This pill and ComposerBannerStack's front item both hardcode the attached-drawer treatment (chat-composer-drawer-surface + chat-composer-drawer-attached + chat-composer-drawer-slot), but that contract assumes exactly one surface joins the composer's top edge. ChatView renders them as ungated consecutive siblings (ChatView.tsx 6401/6404 and 6407), and chat-composer-drawer-slot gives each one margin-bottom: calc(-1 * var(--chat-composer-attachment-overlap)).

So when a banner and a sync phase are live together — e.g. opening a settled or snoozed thread (parkedThreadBannerItem) while cached messages reconcile — the banner pulls this pill into its own masked overlap: the banner's ::before is transparent across those 17px (it expects the composer surface and outline to paint over them) while the pill paints its 16px top corners and 1px top border inside that strip, leaving a notch at the joint and a double edge instead of one continuous drawer. ChatComposer's .chat-composer-top-drawer is a third surface with the same geometry and the same collision.

Suggest deriving the treatment rather than hardcoding it — take an attached prop here (as ComposerBannerStack already does for its stacked items) and let only the surface directly above the composer attach, with the others keeping the detached alert-glass styling.

^{Posted via Macroscope — UI Consistency}

Fixed. Banner, sync, and top-drawer surfaces now use the shared stacked attachment rules without double seams.

ComposerBannerStack now correctly derives attachment via its attached prop, but ThreadSyncStatusPill still hardcodes chat-composer-drawer-surface chat-composer-drawer-attached chat-composer-drawer-slot on line 11 and doesn't accept an attached prop. Since both can render simultaneously (ChatView 6437–6444), the double-seam issue persists when a banner and sync phase overlap.

Stash menu survives pending input

Medium Severity

Hiding the stash badge whenever showComposerTopDrawer is true (including pending user input) does not close or gate the stash menu. An already-open menu stays mounted because render only checks !isComposerApprovalState, and with the badge gone there is no click target to dismiss it. Choosing a row still runs restoreStashEntry, which writes the normal composer draft rather than the active pending answer—the broken affordance this PR aimed to hide.

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

This shared constant exists to defeat the micro size's own type scale: micro declares text-xs, but buttonVariants' base string keeps sm:text-sm, and tailwind-merge treats the sm: modifier as a separate group, so from 640px up the button renders 14px text in a 20px box. xs right below it pairs text-sm sm:text-xs for exactly this reason.

The result is the same override duplicated at two call sites in this PR - here and ChatView.tsx:4473 (className="text-[11px] sm:text-[11px]" on the background-work action) - which is the treatment the shared size should own.

Suggest fixing it in the primitive (apps/web/src/components/ui/button.tsx, size.micro) by pairing the small-screen and sm: type scale, then dropping both call-site overrides so the variant keeps ownership of its typography:

^{Posted via Macroscope — UI Consistency}

The tab now sits entirely inside the area the stash drawer paints over, so opening the stash hides its own toggle.

-top-7 h-8 puts the tab between the composer's top edge −28px and +4px, at z-0 behind the main surface. ComposerCommandMenuLayer portals the drawer to document.body as fixed z-[70] with bottom = innerHeight - surfaceTop - composerOverlap and left/width inset by only 1.375rem per side (ChatComposer.tsx 145-163), so its opaque region ends exactly at the composer's top edge and covers the tab's full 28px overhang. Escape (or the composer.stash shortcut) becomes the only way to collapse the drawer, and menuOpen no longer has any rendered effect — it only feeds aria-expanded, which is now set on an invisible control. The pre-PR pill signalled the open state (border-border text-foreground opacity-100) and was only clipped by ~4px.

Suggest keeping the tab out of the drawer's footprint (e.g. inset the drawer's right edge past the tab, or render the tab inside the drawer layer while it is open) and restoring an open-state treatment so the toggle still reads as expanded:

^{Posted via Macroscope — UI Consistency}

Fixed. The open stash drawer now has a compact visible Close stash button.

chat/ComposerStashMenu.tsx:156

Adding pointer-events-none makes the hover reveal gate interaction, not just opacity, while the touch escape hatch is a viewport query (max-sm:) rather than a pointer query. On a coarse pointer at ≥640px there is no hover, so the button stays pointer-events-none opacity-0; tapping the row runs onRestore and closes the menu, so a stashed entry can no longer be deleted at all. Before this change the button was opacity-0 but still tappable.

This repo gates touch reveals on the pointer rather than width (e.g. ThreadTerminalDrawer.tsx:1759 uses pointer-coarse:hidden / pointer-coarse:block). Suggest swapping the width query for a pointer query:

No longer relevant as of b034b4120e367b79cc71b1600942b78df4584bca

chat/ComposerPendingApprovalPanel.tsx:36

whitespace-pre + overflow-auto makes this a horizontal scroller inside a row that is one 11px line tall, and the app's global scrollbar rule only sets a width (index.css: ::-webkit-scrollbar { width: 6px }), so a horizontal lane falls back to Chromium's ~15px default — taller than the command text above it, and always visible (styling ::-webkit-scrollbar opts every scroller out of overlay scrollbars). The previous panel wrapped instead (whitespace-pre-wrap [overflow-wrap:anywhere] in a max-h-40 box), so the lane is new here; .chat-markdown pre::-webkit-scrollbar { height: 7px } exists for exactly this gap.

Suggest sizing the lane at the owner so the row keeps its compact height:

No longer relevant as of b034b4120e367b79cc71b1600942b78df4584bca

chat/ChatComposer.tsx:2731

This row is the only body in the top drawer that stops at px-3; every sibling state uses the composer's px-3 sm:px-4 column — the plan banner (ComposerPlanFollowUpBanner, px-3 py-2 sm:px-4), the collapsed approval branch just below (line 2763, px-3 pt-2 sm:px-4), and the pending-input panel (px-1 sm:px-2 header + px-3 sm:px-4 panel). So from 640px up the approval command sits 4px closer to the drawer edge than whatever replaces it, and the content shifts sideways when the drawer switches state.

Suggest matching the shared column:

No longer relevant as of f5bd5efd9a28cf7025073c6c9e76bf24aeec678d

Fixed by matching the drawer content column with sm:px-4.

chat/ComposerPlanFollowUpBanner.tsx:11

The three states of the new top drawer now disagree on their leading type, and this one inverts its own hierarchy: the constant label is text-sm/text-foreground/90 while the plan title beside it dropped from text-sm font-medium to text-xs text-foreground/85, so the fixed word is now larger and higher-contrast than the content it describes.

Across the drawer the same slot leads with text-xs font-medium text-muted-foreground for pending input (ComposerPendingUserInputPanel.tsx:190) and text-[11px] for a pending approval (ComposerPendingApprovalPanel.tsx:36). Since ChatComposer swaps these in place inside one .chat-composer-top-drawer, the leading text jumps 14px → 12px → 11px as the state changes, and this is the only 14px text left in the drawer after the compaction the rest of the PR applies.

Suggest matching the pending-input header so the plan title stays the emphasized part of the row:

No longer relevant as of f5bd5efd9a28cf7025073c6c9e76bf24aeec678d

Suppressing the tab on externalDrawerAttached also removes the only acknowledgement that ⌘S worked.

ComposerStashBadge is the sole pointer entry point to the stash (toggleStashMenu has no other call site) and the sole success signal for a stash — stashCurrentPrompt only toasts on failure (written/durable), so on the happy path the badge's count and pulse are the entire feedback (see its own doc comment: "On save the badge gives one quiet acknowledgement").

externalDrawerAttached is true for any composer banner (background liveness, woke, update) or the sync pill (ChatView.tsx:6251), and none of those states block stashing: ⌘S still clears the prompt and images, but with the tab gone there is no toast, no count, and no pointer way back into the stash. Touch has no ⌘S at all, and the stashCurrentPrompt empty-composer fallback only opens the menu when the composer is already empty.

Hiding the tab is right — it would collide with the drawer above it — so the smallest fix is to keep some affordance alive in that state rather than restoring the tab: e.g. surface the stash count/toggle in the footer row while the tab is suppressed, or toast on a successful stash when it isn't rendered.

^{Posted via Macroscope — UI Consistency}

Fixed in 690bf89ec. The tab stays hidden beside attached drawers, but the same count, pulse, and toggle move into existing controls. Expanded, collapsed, and pending mobile layouts all keep a pointer entry, and the inline control remains clickable while the menu is open.

The surfaces that stack in the attached-drawer column disagree on their content inset from sm up.

This banner is px-3 and ThreadSyncStatusPill is px-3 (ThreadSyncStatusPill.tsx:11), while every body inside chat-composer-top-drawer uses the composer's px-3 sm:px-4: the approval row (ChatComposer.tsx:2737), the collapsed approval panel (2769), ComposerPlanFollowUpBanner.tsx:9, and ComposerPendingUserInputPanel.tsx:220. All of them share the same --chat-composer-drawer-inset column and are rendered directly on top of one another, so at ≥640px the banner/pill text starts 4px inside the top drawer's text, and content shifts sideways as the stack changes.

Suggest adopting the same px-3 sm:px-4 here and in ThreadSyncStatusPill.

^{Posted via Macroscope — UI Consistency}