Project quick-switch rail grouped by machine

[hzcheng]

Problem

When working across several projects on local and remote machines, I frequently use the project filter or command palette to change context.

Those controls are useful, but I would like an always-visible way to:

• Quickly return to a small set of projects.
• See which projects are working, have an unseen completion, or need attention—even outside the current thread filter.
• Distinguish projects hosted on different machines.

This is an additional navigation surface, not a replacement for the existing project filter or command palette.

Proposed behavior

Add a narrow project-icon rail alongside the thread list on web and desktop:

• Group entries by machine. A visually distinct machine icon sits above its projects. Clicking it opens a searchable show/hide checklist; it does not switch connections or collapse the group.
• Preserve existing filtering semantics. Clicking a project selects its sidebar scope, with modifier-click supporting multi-selection. The rail reuses the existing scope state rather than introducing another filter model.
• Show existing activity signals. Project icons indicate working, unseen completion, and attention states. The machine header can indicate attention in projects hidden from the rail.
• Separate visibility from project state. Hiding an icon does not archive, unpin, delete, or change the current project filter. Checklist edits apply immediately and keep the popup open.
• Keep preferences client-local. One client remembers separate visibility choices for its connected machines, without server-side preference synchronization.

Local and remote copies of a repository have separate rail entries; the thread list's existing repository-grouping behavior stays unchanged.

Scope and defaults

The prototype initially shows three logical entries per machine. This is initialization only, not a limit: users can show more, and entries are not automatically reordered or replaced based on recent use.

Projects explicitly added or created on that client become visible; newly discovered projects do not continually expand the rail. The machine's checklist remains accessible when all its projects are hidden.

The rail stays within the sidebar content area, hides with the sidebar, and is not proposed for the mobile layout. No saved project groups or connection-management workflow are intended. The core rail requires no new server endpoints, database schema, or synced preference state.

Related discussions

I found #31438 (breadcrumb switchers) and #33191 (multi-project/server filtering). This proposal focuses on keeping project shortcuts and activity visible while no picker is open; it does not introduce saved Work/Personal groups or app-wide server filters.

Direction and scope

I have a working prototype in my fork to explore the interaction, but have not opened an upstream PR. I would like to confirm the direction and scope before preparing one.

1. Is a persistent project rail a direction maintainers would consider, or would you prefer improvements to the existing filter/palette?
2. If the direction is welcome, what scope and initial-visibility default would you prefer? Should project-specific keyboard navigation be deferred to keep the first PR focused?

Prototype screenshots

These are screenshots of the working prototype with demonstration projects. Machine names and paths are anonymized; the views are cropped to focus on the sidebar and conversation area. These examples show one machine; the proposed rail groups additional machines below it.

1. Project shortcuts and activity at a glance

The rail sits beside the thread list. Green dots indicate unseen completions in the demo projects.

2. Searchable visibility checklist

The machine icon opens a show/hide checklist with a master checkbox. Changes apply immediately without closing it.

3. Visibility does not change the active filter

The API project icon is hidden, but its thread scope remains selected. The small blue marker under the machine icon identifies a hidden selected project.

[chomamateusz]

I have been running a horizontal version of this for a few weeks: a row of project icons under Search, with a count badge per project coloured by the most urgent state, and a combined badge on the overflow chip for projects outside the current selection. Two things from daily use that support your proposal: reusing the existing scope state was enough (no second filter model), and the badge for projects outside the filter is the part I rely on most. Screenshots: #36370