Repository navigation
[Bug]: Thread details side-tabs (Subagents/Lineage/Automations/Background Tasks) disappear once rows populate #15304
Description
Activity
Note
Grok responding on behalf of Julius.
Triage
Thanks for the detailed report, @tarunravi! I can confirm this on
mainat71dbaf1. The sections really are being folded away, not failing to mount.ThreadDetailsPanelonly renders two of these blocks whendensity === "full"and the thread isn't a draft:ThreadAutomationsPanelatapps/web/src/components/chat/ThreadDetailsPanel.tsx:225ThreadRelationshipsPanelatapps/web/src/components/chat/ThreadDetailsPanel.tsx:229
So there are two gates rather than four. This card has no separate Background Tasks section, and Subagents are rows inside the single Lineage section (
ThreadRelationshipsControl). Both panels returnnulluntil they have rows, which is why their headings don't show while they're empty.ThreadDetailsCardstarts atfullwhile the measured full height is still0. Once the measured full tree is taller than the card,resolveThreadDetailsCardDensityinthreadDetailsCardLayout.tssteps down tocompact. The card's max height is the canvas height minus 24px, or less when the preview overlaps it. Populated Lineage is capped (max-h-[13.5rem], with its own scroller), but Lineage plus Automations still sits on top of Workspace and Version Control, and on a ~800px window that total can be taller than the card. The new rows paint atfull, theResizeObserverrecords the taller height, anddata-densityflips tocompact, which unmounts the same panels.That full height is cached per
environmentId:threadId:card widthand isn't measured again while the card iscompact, because those panels aren't mounted then. A taller window or a wider card can bringfullback. Losing the rows that caused the overflow can't, because the cached height still fails the fit check.The
ScrollAreadoesn't help here, because density is picked so the tree fits before that viewport ever scrolls.Likely fix area
- One option is to keep Automations and Lineage mounted below
full, let the existing card scroll, and remeasure when their rows change. - Removing every
density === "full"check would reach further than this bug. The environment selector and workspace branch controls are folded on purpose, andthreadDetailsCardLayout.test.tscovers that compact and essential folding.
A maintainer will decide on the fix direction.
- addedbugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.via-triageFiled through npx t3 triageFiled through npx t3 triage
on Oct 3, 2026 Opened PR #15348 for the Previous agents expansion trigger described here.
Expanding the completed-agent list overwrote the card's fitting measurement with the taller content, which selected compact density and unmounted Lineage. The patch keeps a stable minimum measurement for density decisions and retains the latest expanded height separately so the floating preview still clears the real card.
Verified with 16 completed agents in the T3 Browser panel: in a 420px-tall chat canvas, the card remains 396px tall and Lineage stays mounted; showing all 16 agents produces a scrollable list. The PR includes before/after screenshots, a recording, and focused regression coverage.
This addresses expansion after the collapsed card has been measured. It preserves intentional folding when available space drops and does not claim to resolve every initial-population scenario in this issue.
Note
Grok responding on behalf of Julius.
This should be fixed by #16635, which just merged to
main. Lineage is no longer counted when the card picks its density, so populating or expanding Lineage rows doesn't flip the card tocompactand unmount the section anymore. The expanded rows now use the existing scroll areas. If Automations rows still fold the card on a current build, comment here and we'll reopen.
Area
apps/web
Steps to reproduce
dataset.densityhas flipped fromfulltocompact.Expected behavior
Populating Subagents / Lineage / Automations / Background Tasks rows should not remove those same sections. The card already renders inside a
ScrollArea, so added content should scroll, not gate the sections out of existence.Actual behavior
The four sections disappear exactly when they gain content.
ThreadDetailsPanelgates all four ondensity === \"full\":apps/web/src/components/chat/ThreadDetailsPanel.tsx:227(Automations),:231(Background Tasks),:239(Subagents),:243(Relationships/Lineage) — each{density === \"full\" && !props.draftId ? ... : null}densitycomes fromresolveThreadDetailsCardDensity(height, contentHeights)(apps/web/src/components/chat/threadDetailsCardLayout.ts:3-10), computed inThreadDetailsCard.tsx:55; the measured content height grows when the rows populate, sofullcontent no longer fits and density folds tocompact— unmounting the rows that caused the growth.ThreadDetailsCard.tsx:86-91) and never re-expands within the same content; card placement also returnsnull(popover fallback) when width < 240 (threadDetailsCardLayout.ts:26) or height < 160 (threadDetailsCardLayout.ts:34).Impact
Major degradation or frequent failure
Version or commit
origin/main @ 71dbaf1
Environment
macOS, web app (
apps/web), any thread with subagents/automations/background tasks present.Suggested fix direction
Drop the
density === \"full\"conjunct from the four gates inThreadDetailsPanel.tsx:227-247(keep the existing!props.draftIdcheck) and let the existingScrollAreainThreadDetailsCard.tsx:108scroll the overflow, instead of unmounting sections precisely when they have content.Before submitting