Sidebar: project filtering with multi-select

[Andreas-Froyland]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

The project scope picker above the thread list holds one project at a time. So I either look at a single project, or I look at everything.

Neither is what I want most of the time. I usually have two or three repos that are connected, and I want them in one list, because the work in them belongs to the same task. I also use T3 Code for different purposes on different computers while sharing one account, so "All projects" drags in a lot of threads that have nothing to do with what I am doing right now.

The result is that I keep flipping the picker between projects to follow one piece of work.

Proposed solution

Let the scope picker hold more than one project.

• Plain click behaves exactly as it does today and scopes to one project.
• Cmd/Ctrl+click, or Cmd/Ctrl+Enter from the keyboard, adds or removes a project and leaves the popup open so several can be marked in a row. The search text survives toggling.
• "All projects" clears the scope.
• The trigger joins the selected names, and hovering it shows the full list once they stop fitting.
• The scope is remembered, so going to Settings and back, or restarting, does not lose it.

The thread list then shows the union of the selected projects.

Cmd/Ctrl+click marks additional projects while the popup stays open:

The closed picker joins the selected names, truncating when they get long:

Hovering reveals every selected project:

Full interaction: project-multi-select.webm

Why this matters

Related repos are common. A frontend and its API, or an app and the library it depends on, produce threads that are really one stream of work, and the sidebar cannot show them as one today.

It also keeps the picker useful as projects pile up. Right now the only way to see two projects is to see all of them, and that gets worse the more you add.

Smallest useful scope

The modifier toggle and the union filtering are the parts that matter. The rest is optional:

• the hover tooltip only exists because long labels truncate
• persistence could be dropped and the scope reset per session

Single project selection is untouched either way, so anyone who never uses the modifier sees no change.

Alternatives considered

Grouping the sidebar by project or environment (#7836) reorganizes the whole list. This narrows it instead, and the two could coexist.

An environment filter (#6955) is a different axis. Several of the repos I want side by side live in the same environment, so filtering by environment does not separate them.

Global thread filters (#6696) filter by status rather than by project, so that solves a different problem.

Staying on "All projects" and scrolling works, but that is the noise I am trying to get away from.

Risks or tradeoffs

The modifier is not discoverable on its own, so it needs a line in the user guide. Single click does not change, so it stays out of the way if you never reach for it.

A long label needs truncation and a hover to stay readable, which is more state in an already dense row.

A remembered scope has to drop projects that disappear, otherwise you are filtering on something you can neither see nor clear.

Examples or references

Cmd/Ctrl+click to extend a selection is the same gesture as Finder, Explorer, and the VS Code file tree, so it needs little explaining.

Contribution

• I would be open to helping implement this.

Working Demo

#9614

[olafura]

This gist is a demonstration of how this feature could be built or customized with the Qt/QML branch. It is an example to try and adapt, not a complete implementation of the discussion request or a feature shipped in upstream T3 Code.

I made a Qt-sidebar prototype for several project selections. Ctrl/Cmd+click or Ctrl/Cmd+Enter toggles them without clearing the search or closing the popup; plain selection chooses one. All projects clears the filter. Its single-project rail buttons are hidden so they do not conflict with the picker. This gist uses the repository's existing Rosé dashboard example, with the controls above the page.

Selections persist locally. Only the first 50 global Settled rows are published by the current bridge, so older matching rows outside that batch are unavailable. Native sidebar arrows follow visible rows; global traversal shortcuts still use the unfiltered page order.

Demonstration gist and setup.

The screenshot uses demo data.

Code and checks assisted by Codex.

[olafura]

Sorry for the lack of context this is showing how using this technique in the linked discussion would help with your issue #10708

[lmdevv]

I think a simpler approach like the un-merged PR #8142 would be easier to implement and I believe that it fits what the scope better

[mbeckenbach]

Would be enough for me if i could simply filter by machine. Not all of my projects are on all machines.

[kaovilai]

One more angle for the interaction design: modifier-click toggling (Cmd/Ctrl+click, Cmd/Ctrl+Enter) assumes the user can hold a key while pressing the mouse. That does not work one-handed — anyone operating the app with a single hand (accessibility, injury, or a mouse-only workflow) cannot chord a modifier and a click at the same time.

Could multi-select work without modifiers, for example checkbox-style rows in the picker?

• Clicking a row toggles that project in or out of the scope, and the popup stays open so several can be picked in a row with just the mouse.
• An explicit way to finish (click outside, Escape, or a Done action) closes the popup.
• "All projects" still clears everything.
• Plain-click "solo + close" could stay as the quick single-project path, or checkbox rows could replace it — either way the whole flow stays doable with one hand on one mouse.

#8142 already sketched this shape (checkbox menu items, popup stays open while toggling), so there is an implementation precedent.

---

Note

Comment generated with Claude Code (model: GLM-5.3, rits/zai-org/glm-5-3), running in T3 Code.

[kaovilai]

Also think iPad or mobile interface

[juliomuhlbauer]

Related idea that builds on this: #22959 proposes an always-visible row of project icons above the thread list. Click filters to one project, Shift-click or long press adds more (so it works with multi-select here, and one-handed), and each icon shows an activity dot.

[joshka]

Claude Code used to have exactly this: picking a set of projects instead of one or all. I used it constantly for an app plus a fix in a library it depends on, and missed it when it was removed. It's the main thing I'd want here too.

#9614 and #13237 both implemented this and were closed pending direction approval. Is a union filter like this something maintainers would accept, in whatever interaction fits (modifier-click, checkboxes, or the icon row in #22959)?

🤖 Claude Opus 5.5

[danielquintas8]

I have the same problem from the other side. I keep one personal project next to three related work repos, and most days I want to see every project except the personal one. Multi-select would solve that.

[Joelft94]

Adding my use case and a request for a direction call, since #9614 and #13237 were closed pending explicit approval here.

Use case: I have several projects in one install, and some of them are related: they share code, depend on each other, or belong to the same piece of work. "All projects" mixes in everything unrelated, and a single project hides the related ones. So I keep switching the filter back and forth to follow one task.

I see two ways to solve this. Either works for me; I'd rather build whichever you're comfortable with.

Option A: multi-select in the existing filter

• Each project row in the "Filter threads by project" menu gets a checkbox. Clicking the checkbox toggles that project and keeps the menu open. Clicking the project name still scopes to just that project, as today.
• No modifier keys, so it works one-handed and on touch (per @kaovilai's point).
• "All projects" clears the selection. The trigger shows the project name, or "N projects".

Option B: named project sets, defined in Settings

• In Settings, the user creates a named set of related projects (e.g. "Client X", "Personal").
• The filter menu lists those sets alongside individual projects. Picking a set shows threads from all its projects.
• The filter itself stays a pick-one menu. The extra choice lives in Settings rather than in the sidebar.
• This is a much smaller version of the Spaces idea in [Feature]: Multiple Spaces for organizing projects and threads (Arc/Zen-style) #6733: it only filters the list and doesn't reorganize projects.

Shared scope for both:

• List filtering only. Threads stay bound to one project, nothing changes on the server, and defaults are unchanged.
• The web sidebar already filters on a set of project keys (scopedProjectKeys). So for A the core change is turning the remembered sidebarProjectScopeKey into a list, and for B it's saving the sets and resolving one to its project keys.
• Mobile (ThreadListFilters) would get the same behavior so the surfaces don't diverge.

@t3dotgg @juliusmarminge would you accept either of these? If so, which one? I'll send one focused PR covering web and mobile, with before/after screenshots, and link your reply. If neither fits, a clear "no" would help too, so people stop sending PRs for this.

[juliusmarminge]

Closing: current main already covers this as of c38b265adc. If you still see it on a build that includes that commit, reply and we'll reopen.