Manual, collapsible thread groups with optional colors

[coreldh]

Problem

A project is the right execution boundary, but it is not always the right organizational boundary.

For example, within one project I may have several related threads:

• Galeno — Fable 5.1
• Galeno — Astra
• Galeno — Sol

They belong to the same project, but represent different roles or workstreams. As the number of threads grows, a flat project list becomes hard to scan and it is easy to lose the relationship between them.

Proposal

Add user-created thread groups inside a project.

A group would be a named, collapsible section in the project’s thread list:

Pergamum
  ▾ Galeno
      Galeno — Fable 5.1
      Galeno — Astra
      Galeno — Sol
  ▸ Catena Aurea
  ▾ Other threads
      ...

Users could:

• Create, rename, delete, reorder, and optionally color groups.
• Move a thread into a group through the context menu or drag-and-drop.
• Keep unassigned threads in an Ungrouped section.
• Collapse or expand a group with one click.
• See an aggregate activity indicator on a collapsed group when it contains a working thread, an approval request, or something needing review.

A small per-thread color accent could be a useful follow-up, but group colors are the important first step. Color should be supplementary rather than the only status signal, so the UI remains accessible.

Why manual groups

This is deliberately not a request for automatic grouping, AI-generated tags, or grouping solely by worktree.

Those approaches can be useful, but the person managing the work understands the meaningful relationship between threads: they may be different models reviewing the same task, separate stages of a rollout, or parallel roles in one initiative.

Manual grouping gives that person a lightweight way to express the structure without changing repository, project, branch, or worktree ownership.

Smallest useful scope

• Groups are scoped to a project.
• Manual create / rename / reorder / delete.
• Manual thread assignment and removal.
• Collapsible group headers.
• Persistent group membership and collapsed state.
• A visible aggregated status badge for collapsed groups.

Out of scope for a first pass:

• AI-generated tags or automatic grouping.
• Changes to worktree, branch, project, or provider behavior.
• Replacing search, filters, attention ordering, or Spaces.
• Nested groups.

Related ideas, but not duplicates

• [Feature]: Thread grouping / filtering #5653 proposed tags for grouping/filtering threads.
• [Feature]: Group threads by worktree #3697 proposed grouping automatically by worktree.
• [Feature]: Multiple Spaces for organizing projects and threads (Arc/Zen-style) #2293 proposed higher-level Spaces for projects and threads.
• [Bug]: Collapsing a project with many visible threads blocks the UI for seconds #3962 confirms that project-level collapsing already exists, though it has a performance issue for very large lists.

This proposal is a manual, user-defined layer inside the existing project/thread hierarchy.

Question for maintainers

Would this fit the Sidebar V2 direction? In particular, should group membership be durable server-side user metadata, while presentation choices such as collapse state and color remain device-local?

I am looking for product direction first and will not open an implementation PR without it.

[umitaltintas]

Manual groups make more sense than automatic ones here.

I have around 25 projects in t3code, arranged on disk under a few parent folders. Roughly half have no git remote, so the existing repository grouping produces nothing for them. Anything derived from git identity keeps missing that shape. A manual group doesn't care.

Same gap one level up, for the project list itself (#6754). If a group were just a named, collapsible, user-ordered container, one implementation could cover both.

[rexkirshner]

+1, and a slightly simpler version of this that would cover my use: user-named shelves in the default sidebar that behave exactly like the existing Settled shelf. Collapsible, and you drag threads into or out of them. No colors or nesting needed. Today Pinned/Active/Settled are the only buckets, and with many parallel threads I'd like a few of my own (e.g. "project A", "infra", "personal", etc).

[jvitormelo]

+1. One concrete use for a manual collapsible group: a group for threads bound to scheduled tasks/automations. Right now I use Pinned for that, but it can't be collapsed and has no visible boundary (I opened #21908 for a divider). A named, collapsible group would solve both.

[juliomuhlbauer]

+1, and here is a use case that I think makes a strong argument for manual groups: a collapsible "Saved" group for threads I want to keep forever.

Some threads are reference material: a setup walkthrough, a debugging session I'll want to look at again, a research thread. I want to keep them for good and get back to them in one click, but I don't want them taking up space in the sidebar. None of the current states fits:

• Pinned keeps them in reach, but it can't be collapsed, so five or six reference threads crowd out the threads I'm actually working on.
• Settled mixes them in with every finished task thread, so they're hard to find again.
• Snoozed is time-based, and these threads have no date to come back.
• Archived hides them almost completely, and opening an archived thread by link currently sends you to the home screen (Opening an archived thread by its link sends you back to the home screen #16443).

A user-created, collapsible group would fix this without adding a new lifecycle state. I'd make a "Saved" group, collapse it, and expand it when I need something. Two things that would make it work well for this case:

1. Threads in a group are never auto-settled, or at least they stay in their group whatever their settled state is. Being in the group is the signal that I want to keep the thread.
2. Group membership is visible to search and the command palette, so I can find a saved thread without expanding the group.

Related: #6899 (standing threads that never terminate) and #19325 (a collapsible group for drafts saved for later).

Update: I wrote this up as a focused proposal in #22958, which also suggests making Pinned collapsible.

[rakeshvmehta]

+1. Concrete use case: I switched from Codex and topic sections are the one thing I really miss. All my work lives in one multi-repo project (backend, frontend and a shared config repo under one parent folder), so grouping by project or repo puts every thread in a single list. In Codex I keep them in named sections by area of work and collapse the ones I'm not on.

On scope: #15988 (related thread groups) already gets most of the way there. If a group could have its own name without needing a real top thread, that would cover this with very little extra state, no separate sections system. Same theme shows up in #6733, #6751 and #6902, about 60 upvotes combined.

[timvdhoorn]

+1. For what it's worth, I run a fork with a patch that covers a related case: threads an agent opens (via t3_thread_launch, create_threads or delegate_task) nest under the thread that opened them, as a collapsible family with an aggregate status row. This is how it looks for me:

The disclosure row summarizes the family ("6 child threads · 1 failed · 2 working · 2 settled"), each child shows its status icon where the time would be, and folds persist per device. Settling the opener moves the whole family to Settled, collapsed.

Patch: patches-tt/0003-feat-nest-agent-opened-child-threads-under-their-ope.patch (the server side is upstream PR #16699).

It's automatic rather than manual, so it doesn't replace the groups proposed here, but the same header, fold and aggregate-status UI could serve a manual group with a name instead of a head thread, as @rakeshvmehta suggests with #15988.