Group sidebar threads by project and by the session that started them

[jagadhis]

Area

apps/web (desktop via web), packages/contracts, apps/server

Problem

When a session hands work off to agents, the sidebar loses track of where that work came from.

• Threads an agent opens with create_threads or t3_thread_launch show up as unrelated top-level rows. Nothing on the new thread records which session opened it. The only trace is senderThreadId on its first message, so the sidebar can't connect it back to its session.
• delegate_task children have lineage.parentThreadId, but the sidebar hides all subagent threads, so you can't reach a delegated task from the sidebar at all.

With a few sessions fanning out work across a couple of projects, the inbox becomes a flat list where I can't tell which thread belongs to which session. #18045 describes the same pressure from the filtering side ("threads started by agents now outnumber the ones I start myself").

Proposal

An opt-in Thread grouping setting (Settings → General → Organization), off by default. When it's on:

1. Project headers inside each existing section (Pinned / Active / Working / Snoozed / Settled). They're collapsible, show a thread count, and remember their state per section. Section membership, settle, snooze and pin work exactly as they do today.
2. Threads a session started nest under that session, behind a small "N threads from this session" row that's collapsed by default. It also shows "· N working" / "· N need you" when that applies.
   • Launched threads (create_threads / t3_thread_launch) nest when they're in the same section as their session. Otherwise they stay top-level in their own section.
   • T3-delegated tasks (delegate_task, subagent + creationSource: "mcp") become visible, follow their session's section and nest under it. Provider-native subagents stay hidden, as they are today.
   • A group sorts at its most recently active member, so a busy child brings its session to the top.
   • The project and session groups containing the open thread are always expanded.
3. Drag reordering is disabled while grouping is on, so pinned and active order keys never have to account for nested rows.

To make (2) possible for launched threads, the server records the launching thread on the new thread: an optional lineage.launchedByThreadId, set by create_threads and t3_thread_launch. It's optional and additive. relationshipToParent stays "fork" | "subagent", so existing clients and the code that checks those values are unaffected.

Implementation

I have a working implementation on my fork: jagadhis/t3code@main...jagadhis:t3code:feat/sidebar-session-groups

• The grouping is a pure function in Sidebar.logic.ts with unit tests. The server change is covered by the existing create_threads integration test and the t3_thread_launch handler test.
• Web only for now. Mobile keeps its current list (threadListV2.ts hides subagents the same way) and could follow separately.

Questions for maintainers

• Is opt-in grouping in the inbox sidebar a direction you'd accept, or would you rather solve this with filtering ([Feature]: Filter sidebar threads by who started them #18045) or in the thread relationships panel?
• Is an optional launchedByThreadId on lineage the right place to record the launching session, or would you prefer something else, such as deriving it from the first message's senderThreadId?
• Should existing launched threads be backfilled from that senderThreadId, or only new ones?

If the direction looks right, I'm happy to open a PR scoped however you prefer.

[vaststudios]

I built this for the legacy sidebar and opened it as #20953 so there's working code to look at. It hasn't been approved, so treat it as a proposal.

• t3_thread_launch and create_threads record the calling thread as an optional launchedByThreadId on the new thread. It needs no migration, and clients that don't read it look the same as before.
• The legacy sidebar nests launched threads under the thread that started them, up to three levels deep, with a connector line.
• Provider subagents nest under their lineage parent instead of disappearing. They start folded because you can't chat in them, and a hover chevron unfolds them. A folded thread shows how many threads it hides.

Before	After	After (unfolded)

I've run it on my own install for a couple of days with real orchestrator sessions. I'd like to know whether this direction fits, especially the new field on the thread shell and folding subagents instead of hiding them (#15812, #20808). The v2 sidebar could use the same field later, but I left it alone.

[vaststudios]

Update: I merged my two PRs into one, #21267, and opened #21266 to discuss the direction (grouping launched threads and subagents under their launcher, folding, and paging long thread lists). Feedback there is welcome.