Which project should "New thread" start in? A setting, clear command names, and one place to decide

[joshka]

Which project should "New thread" start in? Bringing the threads together

At least nine issues, discussions and PRs are trying to answer the same question, and several of them conflict. Each one fixes a single entry point or a single sidebar mode, so each lands as a "Needs human approval" change to a product default, with no shared picture of what we're aiming for. This post collects them in one place so we can decide once.

How it works today

Entry point	Default sidebar	Boring sidebar (Labs)
Sidebar New thread button	Picker if 2+ projects, else current project	Current project, no picker (#21039)
chat.new (⌘N)	Picker if 2+ projects	Current project, no picker
Shift+click / chat.newLocal (⇧⌘N)	Current project	Current project
chat.newWithoutProject (⌥⌘N)	No project	No project
Command palette "New thread in X" / "New thread in…"	Current project / picker	Same
Boring sidebar project folder ✎	n/a	That project
Mobile New task	Always "Choose project"	n/a

"Current project" means the project of the thread or draft you're viewing, then the first project in sidebar order (resolveThreadActionProjectRef). The sidebar project filter isn't used anywhere, even though #9416 persists it across navigation. So you can be filtered to project A while viewing a B thread.

The existing threads

Always / more often show the picker

• #26416: in the boring sidebar, New and ⌘N skip the picker. Since #26387 hides idle projects, those projects have no direct way to start a thread.
• #26495 (open, supersedes #26425): the boring sidebar's New and ⌘N open the picker again.
• #22746 (open): show the picker even with one project.

Follow the sidebar filter

• #17988 / #11895: when the sidebar is scoped to one project, New should start there. Triage accepted this for the sidebar button only and left whether ⌘N should match "for a separate decision".
• #14165 (open): implements the button part.
• #7550 (closed): open the picker highlighting the filtered project instead of skipping it.
• #4748 (closed as stale): an earlier version, including remapping the shortcuts.

Show the picker less

• Comments in #17988: a setting so New never asks, and on mobile, New task should open in the last-used project with the keyboard up.
• #29798 (open): the hidden "No project" scratch project shouldn't count toward the 2+ projects rule.

What users actually do

Two kinds of users want different defaults:

1. Single-focus: almost every thread goes into one project. For them the picker is a tax.
2. Switchers: many projects, switching between them constantly. Starting in "the project of the thread I last looked at" is often wrong, and the mistake is silent. You find out after typing your prompt.

Neither group is wrong, and they don't share a sense of what "good" is: what saves one group a step costs the other a silent mistake. A single default will always feel wrong to one of them. That's why each PR above looks obviously right to its author and gets flagged as a change to a product default in review.

Options

A. Keep it as it is. The default sidebar and the boring sidebar disagree, and the sidebar filter has no effect. Users who switch sidebars get surprised (that's how this came up for me).

B. Picker everywhere for New / ⌘N; Shift / ⇧⌘N goes direct (#26495, plus #22746 for one project). Simple and consistent. Single-focus users pay one extra Enter, but only if the picker opens with the right project highlighted.

C. Follow the filter, else the picker (#14165). Good when you're scoped, but behavior now depends on hidden state: the filter is persisted and may not be visible.

D. Picker, with the best guess highlighted (#7550 generalized). New and ⌘N always open the picker. The first row is, in order: the filtered project (if exactly one), else the viewed thread's project, else the last project you started a thread in. Enter confirms, typing switches. Shift+click and ⇧⌘N still go direct to the viewed project. Every New costs one keystroke, never a wrong project.

E. Add a setting ("New thread opens: Ask / Current project"), today expressed only by which sidebar you happen to use. One more setting, but it's the honest answer when the two groups want opposite things.

Proposal

D as the behavior of "Ask", plus E so each group gets a good default:

• One setting, New thread starts in: Ask, with my current project first or My current project. It covers the plain action everywhere: sidebar button, ⌘N, and mobile New task. It replaces the hidden coupling to the boring sidebar, so switching sidebars no longer changes where new threads go.
• Ask is option D: the picker opens with the best guess highlighted (the filtered project if exactly one, else the viewed thread's project, else the last one used), so Enter is the whole cost.
• My current project starts there directly, and the draft's Change project control fixes a wrong guess.
• The opposite action is always one modifier away: Shift+click / ⇧ flips to whichever behavior the setting didn't pick. Folder ✎ buttons in the boring sidebar stay direct.
• No project-count special cases, except ignoring the scratch project (#29798).

Fix the command names as part of this, not later. With a setting that flips behavior, the names have to say what each command does. Today chat.new means "picker or not, depending on sidebar and project count", and chat.newLocal reads as local vs. remote or local vs. worktree, not "current project". Something like:

Today	Proposed id	Proposed label	Does
chat.new	chat.new	New thread	Follows the setting
(none)	chat.newChooseProject	New thread in… (choose project)	Always opens the picker
chat.newLocal	chat.newInCurrentProject	New thread in current project	Never opens the picker
chat.newWithoutProject	chat.newWithoutProject	New thread without a project	Scratch thread

With explicit "always pick" and "never pick" commands, people can bind exactly what they want regardless of the setting. The ids matter as much as the labels, because people see them in keybindings.json. The old chat.newLocal id would keep working as an alias so existing custom bindings don't break.

Maybe: a "how do you work?" preset. A choice like Mostly one project / I switch between many, in onboarding or at the top of the setting, would set the default and explain the modifier. It could help people pick without understanding the mechanics. It may also be over-engineering for one toggle; it's here to see whether others think it's worth it.

Questions for maintainers

1. Is a setting acceptable here, or should there be one default for everyone? If one default, which group pays?
2. Should the sidebar filter decide which project the picker highlights first, or where the thread starts with no picker?
3. Are the command renames (and an explicit "always choose project" command) OK to do together with this?
4. Should mobile New task follow the same setting?

With answers to these, #26495, #14165, #22746 and #29798 can each be merged, adjusted or closed against one decision.

🤖 Claude Opus 5.5