Sidebar: group the inbox by environment, project or provider — with rows that stop repeating themselves

[BarretoDiego]

Update — the prototype now covers the full sidebar workflow

The first version of this proposal only grouped the inbox. After using it as my daily sidebar, I kept following the same rule: the structure that tells you where work lives should also be the place where you act on it.

The current prototype now covers grouping, ordering, section actions, project removal, per-project settled history, and navigable environment/project scopes. It is still one working branch, but the commits are layered so maintainers can take only the pieces that fit the product direction.

Screenshots — current prototype

Full sidebar with environment → project grouping, compact thread rows, per-project history, and scope-owned actions.

Grouping controls	Sorting controls
Choose one or two grouping axes without changing the provider filter.	Sort by activity, creation time, alphabetical order, or switch to custom ordering.

Custom section order	Environment scope
Reorder sections in place while nested groups remain inside their parent.	Breadcrumb navigation opens an environment page with its projects and threads.

Project scope keeps active, snoozed, and settled work together and exposes the same project actions as the sidebar.

What is in the current version

• Environment → Project is the useful default. A flat list remains available, but the default now answers “which machine?” and “which project?” without repeating both on every thread.
• Grouping and filtering remain orthogonal. Group by environment, project, or provider; add a second axis; filter all shelves by provider; sort by activity or creation time.
• Sections can be ordered. Busiest-first, alphabetical, or custom. Drag a section or use Move up/Move down; nested sections only move within their own parent.
• Quiet projects stay visible. A project with zero live threads still has a section, so it remains one click away from new work instead of disappearing from the navigation.
• Actions live on the scope they affect. Environment headers add a project. Project headers create a thread or open project settings. The same actions are available from the context menu.
• Remove project is reversible in the right place. It is kept in the project-section context menu, shows the path/environment/thread count, and confirms before removing the project from the sidebar.
• Settled history belongs to the project. When grouped by project, every project ends with its own collapsed Settled shelf and incremental Show more row. Other grouping modes keep the global shelf.
• Collapsed sections summarize attention. Approval, input, failure, unseen completion, and running counts use the same status classifier as their child rows.
• The breadcrumb is navigation, not decoration. Environment and project names above a thread open scope pages with their projects/threads and the same Active, Snoozed, and Settled model as the sidebar.
• Cards only say each fact once. A grouped row removes metadata already stated by its ancestors while keeping status, pin, snooze, settle, and PR affordances.

Why this is one model instead of several sidebar features

Grouping alone exposed two dead ends: empty projects vanished, and a visible project header could not start work. Adding actions without ordering made active sections jump around. Adding ordering without per-project history let the global Settled shelf grow without context. The pieces reinforce one small mental model:

A section represents a real scope, remains visible, owns its actions, and owns the history that belongs to it.

The implementation keeps that model client-side where possible. Grouping, sorting, attention rollups, and row compaction are pure derivations over thread shells already in memory. There is no sidebar polling, continuous animation, or new websocket traffic for layout.

Branch and commit layers

Working branch: feat/sidebar-plan-limits

The sidebar work can be reviewed or cherry-picked in layers:

1. fbd582567 — group, filter, and sort the inbox
2. d88d9e899 — start a thread from a project section
3. 1eb9b4d0a — open the project picker in a chosen environment
4. 3b59e63f7 + 342acabfd — make headers own their actions and settle the compact-row UX
5. 2828bb2b8 — remove a project from its section
6. 781dc6ff3 — custom section ordering
7. 21583f9e0 — navigable environment/project scopes

The branch tip also contains the provider plan-limit meter. I am opening that as a separate Discussion because its server/provider contracts deserve an independent product decision.

Surfaces and compatibility

• Web and desktop get the full grouped sidebar and scope navigation.
• Settings are client-local with decode defaults, so older and newer clients can connect to the same server.
• Provider filtering uses driver kind rather than instance id, so multiple accounts of the same provider do not create unstable filters.
• Project removal uses the existing project command path; it is not a client-only disappearance.
• User documentation lives in docs/user/thread-sidebar.md; vocabulary additions are in the internal glossary.

What I deliberately kept out

• No subagent counts: the sidebar shell does not currently carry the activity data needed to do this honestly.
• No replacement of the existing flat card design.
• No new server-side grouping projection.
• No mobile redesign hidden inside a web-sidebar proposal.

The original problem

The v2 sidebar becomes hard to scan once one user has multiple environments, projects, and providers. A single project filter is too narrow, while one flat list repeats metadata and makes the user reconstruct scope row by row.

The prototype keeps today’s thread semantics and makes scope visible, actionable, and stable. Is this the sidebar direction maintainers want? If yes, the commit stack above is intentionally shaped so it can land in smaller PRs rather than as one large change.

[zhuziqi97]

I support this direction. I work across multiple projects, and having to click New and then choose a project each time is inconvenient. Keeping projects visible, even without active threads, and adding a New thread action to each project header would make this much easier to use.

[AdEx-Partners-DE]

@zhuziqi97 the "click New, then choose a project" step bothered me too. A small fix that needs none of the bigger restructuring: in my fork, when the sidebar is filtered to a project, New thread starts in that project directly, and an empty filtered list says "No threads in ‹project› yet" with its own button. Tried in a dev build: filter to a project without threads, click, the draft is in the right project.

Code: 3b670887b on stark/main.

---

Posted by Claude (Opus 5.5, Claude Code via T3 Code) on behalf of @AdEx-Partners-DE.

[jieyuexing]

Note

Drafted by Claude Opus 5.5 in Claude Code (via T3 Code); reviewed and posted by @jieyuexing.

+1 for environment → project as the default. A multi-machine data point:

I run threads on three environments every day: a Mac, a Windows work machine, and WSL on that Windows machine. The current sidebar puts all of them in one inbox, and these are the places where it gets hard to follow:

1. No machine axis. The list can be scoped by project, but there is no way to group or filter by environment. A row on another machine gets a small machine icon, and the machine name only appears on hover.
2. Same-named projects show up twice. The same repository checked out on the Mac and on Windows appears as two identical entries in the project scope menu, told apart only by the icon.
3. Delegated work across machines floods the inbox. When a coordinator thread on the Mac starts worker threads on the Windows environment, those land as top-level inbox rows. Subagents on the same environment are hidden in the Agents surface, so cross-machine delegation is the noisy case. Grouping by environment would keep them together under that machine.
4. Repository grouping merges sibling projects. Three projects that are subfolders of one repository share a remote, so the default "repository" grouping turns them into one scope labeled with the remote path. "Separate" splits them again but also stops matching the same project across machines. Choosing environment and project as explicit grouping axes, as in this prototype, avoids having to pick between the two.

If the full proposal is too large to take at once, an environment scope or filter next to the project scope would already cover most of this.

[AdEx-Partners-DE]

A smaller cut of the same idea, in case a first step is easier to take than the full prototype.

In my fork "By project" is one value of a thread-order setting (next to Manual and By status). It does only two things:

• keeps each project's active threads together, in the existing order inside the project
• puts a thin heading above each block: project icon, project name, thread count

No collapsing, no per-project actions, no environment level, no change to Settled or Snoozed. The headings are plain elements between the rows, not part of the sortable list, because the order is automatic in that mode. That kept the change to about 50 lines in Sidebar.tsx on top of the sort function.

Two things that showed up with about ten projects open (one day of use so far):

• The heading earns its place even without collapsing; it is what makes the block readable. The project name on every row then becomes the repetition this discussion describes, so dropping it from grouped rows would be the obvious next step. I have not done that.
• Project order needs a rule. Mine is a per-project priority (High / Normal / Low from the row's context menu), then the existing order. Without it the blocks sit in whatever order the first thread of each project happens to have.

#17795 asks for nearly the same heading (icon, name, count), with collapsing on top.

Branch (web only, mobile not covered): https://github.com/AdEx-Partners-DE/t3code/tree/feat/sidebar-inbox-order-and-project-colors

Posted by Claude (AI) on behalf of @AdEx-Partners-DE; not reviewed by a human.

[AdEx-Partners-DE]

An update to "no collapsing" above, because I gave in after a day: a click on the project heading now folds that project's block, remembered per browser. Two details that made it safe to use: a folded heading shows a dot when something in it waits on you, and the thread you have open stays visible. Tried in a dev build.

Code: 9cc482783.

---

Posted by Claude (Opus 5.5, Claude Code via T3 Code) on behalf of @AdEx-Partners-DE.

[jog068]

Note

Drafted by Claude Opus 5.5 in Claude Code (via T3 Code); reviewed and posted by @jog068.

Another data point for project grouping, plus one piece I haven't seen in this thread yet: a Needs you shelf on top.

My problem. I work across 5 to 8 projects. The flat inbox mixes them all, and each active thread is a three-line card, so about six fit on screen. I lose track of which project a thread belongs to and what is waiting on me.

What I built (opt-in, local branch). A Sidebar layout setting with Inbox and Projects. Inbox stays the default. Projects shows:

• Needs you. Threads from any project that wait on an approval or input, failed, or finished while I was away. Blocked comes first, then failed, then done. The thread also stays in its project, so the shelf is a view, not a move.
• Pinned, unchanged.
• One collapsible header per project. Each has a + for a new thread there, then one-line 28px rows (status dot, title, time). The 6 most recent threads show (configurable), then "Show N more", then "N settled".
• Snoozed, at the bottom.

Why the shelf. Grouping by project gives a stable map, but a status inside a collapsed project gets buried. The shelf keeps the inbox's "what needs me" answer without reshuffling the tree whenever a status changes.

Scope. Web and desktop only; mobile is unchanged. It reuses the existing lifecycle partition, project grouping and collapse state, so settle, snooze, pin, search and keyboard shortcuts keep working. Drag-reorder is off in this layout for now.

I'm happy to open a PR if a maintainer is open to this direction, or to fold the Needs-you idea into whichever grouping design you prefer.

[grahamfarrar]

+1 for grouping by environment. I want to see every project at once, organized by environment, not filtered down to one.

I run two environments from one desktop and phone: a Personal server and a work server (Glass House) on the same Mac. Right now their projects mix together in one list. What I want is a section per environment with its projects under it. Each section should collapse, and the order of the sections should be adjustable.

A workaround today is Manual project sort, dragging each environment's projects next to each other. There is still no header to show where one environment ends and the next starts, and every new project has to be dragged into place by hand. Environment → project grouping from your prototype is exactly this.

[ScottN-PV]

Note

Drafted by Claude Opus 5.5 in Claude Code (via T3 Code); reviewed and posted by @ScottN-PV.

+1 for project grouping with compact rows. Here is a mockup of the layout I'd use every day:

What it changes from today's sidebar:

• Project groups. Each project has one header with its icon, name, thread count and a collapse chevron. The rows under it no longer repeat the project name.
• One line per thread. Each row shows a status dot, the title, the provider or working icon, and the time since the last activity. Branch and model move to the thread header, which already shows them.
• Status tabs instead of sections. The tabs at the top read All, Working (4), Review (2) and Settled, and they filter the grouped list. The counts tell me what needs me without scrolling.
• Settled stays out of the way. It collapses to one line with a count at the bottom (354 for me).

I run 8 to 10 active threads across 3 projects. Today's card rows fit only about half of them on screen, so I scroll to find out which project a thread belongs to. With this layout the whole set fits in one view.

Related: #17319 (compact rows for every section) and #17795 (collapsible project boxes).
``

[matdac6]

Note

Drafted by Claude Opus 5.5 in Claude Code (via T3 Code); reviewed and posted by @matdac6.

+1 for grouping the inbox by project. One request on the scope: please make "hide projects with no active threads" an option, or the default for the grouped inbox.

I have ~30 projects registered but work on 2–3 at a time. The flat inbox mixes those 3 together, and the legacy per-project tree is worse for me because it lists all 30. The view I want is the current inbox, unchanged, with each project's active threads under one collapsible header showing the project name and thread count. Projects with zero live threads shouldn't appear at all.

@AdEx-Partners-DE's smaller cut above (a heading over each project's active block) is basically exactly this.