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.

[vekaev]

+1, with a case for nesting, which the proposal lists as out of scope.

I work feature-first inside one project. In billing-service a single effort like "Increase revenue" ends up with four or more threads: investigation, the pricing change, the migration, the review. Inside that effort there are sub-efforts with their own threads, so one level of groups gets flat again quickly. What I want is folders inside folders, with the project icon idea carried over to folders.

A second case: forks. When I fork a thread to try another approach, the fork lands as a loose "<title> fork" row. I'd like forking to put the original and its fork together in a subfolder named after the original, and later forks of either to land in that same subfolder, so each family of attempts stays together.

I'm building both in my fork to try the shape:

• Folders are project-scoped and server-side, so they sync across devices. They nest up to 6 levels, can have an icon, and can be renamed, moved or deleted. Deleting a folder moves its threads and subfolders up one level, and Undo restores it.
• Moving a thread into a folder doesn't bump its updatedAt. Pinned, snoozed and settled threads stay on their shelves and show their folder as a label.
• A fork creates the family subfolder on the server, so it works the same from web, mobile and agent-started forks.
• Collapse state is per device. Older clients and mobile keep the flat list.

Questions for maintainers:

1. If manual groups happen, should they nest, or stay one level as proposed here?
2. Should forks group with their source? feat: related threads stay together as a group #15988 groups launched threads under their opener but leaves forks out.

I won't open a PR without a direction from you.

Written with Claude Opus 5.5 (claude-opus-5-5) in Claude Code, running in T3 Code.

[romanzdk]

I built a working version of the user-named shelves suggested above, mainly for “Waiting for me” and “Waiting for someone else”. I’ve been using it in a macOS fork.

The scope is small:

• Create, rename, delete and collapse named sections in the default sidebar.
• Move threads through Thread actions → Move to section, or drag and drop.
• Show a dashed drop box for every custom section while dragging, similar to Settled, including empty or collapsed sections.
• Remember names, membership and collapse state locally. Deleting a section keeps its threads.

Here are screenshots from the working build, using demo threads:

Named sections	Dragging into a section

Source at the tested revision. This prototype uses device-local storage; it does not sync groups across devices or add native mobile support. It has no nesting or colors.

Would maintainers approve a focused upstream PR for this named-shelves scope? In particular, should membership stay device-local or use server-side metadata? I would keep the fork’s branding, authentication scheme and packaging changes out of the PR.

[SouthCarpet]

Claude Fable 5.1 on behalf of SouthCarpet.

+1, with a use case from the new Boring sidebar (group by project) in #21039.

We run several workstreams from one T3 project, projects-vault. The apps have separate repositories under apps/, but their threads start from the root because our local agent tools live there.

Our active threads share one project folder. Most of our threads are on the separate Settled shelf. Project folders do not separate workstreams within one project, and this mode does not let us drag threads into a manual order.

To show what we mean, we built a small client-only prototype on a branch from current main (no PR, branch proto/sidebar-groups on SouthCarpet/t3code). The screenshots are quick renders from that rough build with demo data, not polished UI.

1. Right-click a thread, choose Add to group, then choose a group or New group…. A grouped thread also gets Remove from group. The items sit after Snooze, before Rename thread.
2. Groups fold inside the project folder in the boring sidebar, and show as named sections in the default sidebar. A collapsed group shows its count and a status dot.
3. Right-click a group header: Rename group, Group settings…, Delete group (its threads become ungrouped).
4. Group settings: an icon for the group, chosen with the same picker as the project icon (icon, emoji or monogram, same colors). It shows in the submenu, on the group header and on the rows of its threads, so threads of one project can still look different per workstream. The dialog also has two optional Auto-add rules, off by default: threads that run in a sub-folder of the project, or in a given git repository (or both), join the group without a manual step.
5. Drag: an explicit drop on a group header adds the thread. Leaving the group boundary does not remove it. That keeps membership separate from pinning and moving work to Settled.

Default sidebar and boring sidebar with the same three groups (one collapsed):

Add to group in the native menu, and the Group settings dialog:

Would you consider named groups within a project, or should this use the thread-led groups proposed in #15988? If named groups fit the direction, should groups and membership be device-local or shared through the server?

We can prepare a focused PR after maintainers approve the direction and first supported surface.

[steverajeckas]

+1 from a Codex switcher. Named, collapsible sections are the one thing I miss most.

I'm not an engineer. I run marketing projects through T3. Each outcome (a campaign, a page rebuild, a research project) gets one manager thread plus several worker threads that the manager launches. They all live in one project folder, so today they land in a single flat list. With 15+ outcomes running, that list gets hard to scan quickly.

In Codex I keep one section per outcome, with the manager pinned first and its workers underneath, and I collapse whatever I'm not working on. What would make T3 match that for me:

• Named, collapsible sections inside a project that I can rename and reorder
• A way to pin one thread to the top of a section (the manager)
• An option for threads an agent launches to land in the same section as the thread that launched them
• Ideally, the T3 MCP tools could create sections and move threads into them, so my agents can keep the sidebar organized themselves

[EdoMon93]

+1. I'd like to manually link threads as related and have a "Related threads" index in the right sidebar.

When several conversations concern the same piece of work, I want to jump between them without searching the full thread list.

The smallest useful version would let me:

• Link and unlink existing threads.
• See related threads by title in the right sidebar.
• Click to navigate between them, keeping the links visible so I can move back and forth.

#15988 looks close on grouping. Could those same relationships also power this right-sidebar index?