[Feature]: New thread should default to the current sidebar project

[nandorocker]

Before submitting

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

Area

apps/web

Problem or use case

The project-scoped sidebar is great: it keeps a project's threads together with their to-do/done states. But clicking New asks me to choose a project again, even though I'm already inside one. That's an unnecessary extra click, and the current project isn't always at the top of the selector.

Proposed solution

When the sidebar is scoped to a project, New should start a thread in that project by default. Keep the project selector available to switch projects; only show it first when no project is selected.

Why this matters

The sidebar already establishes the project context. Thread creation should inherit it.

[juliusmarminge]

Triage

Valid enhancement. Not a duplicate.

When the sidebar is scoped to one project, New thread still opens the command-palette project picker. That matches the current multi-project rule; it does not follow sidebar scope.

Current behavior

Plain New with 2+ project groups always opens new-thread-in (Sidebar.tsx handleNewThreadClick, gated by shouldCreateNewThreadInCurrentProject). Immediate create happens only on Shift+click or a single project.

That “current project” path uses the viewed thread/draft, then the first ordered project (resolveThreadActionProjectRef / startNewThreadFromContext). It does not read sidebarProjectScopeKey / scopedProjectGroup.

The new-thread draft already has a Change project control in DraftHeroHeadline. Mobile already has a per-project + and is out of scope.

Related

• Closed PR fix(web): create new threads in the selected sidebar project #4748 implemented this targeting (including remapping chat.new / chat.newLocal). Closed in a backlog sweep as stale after the sidebar rewrite / new-thread targeting conflicts — not wontfix. Reimplement against current Sidebar.tsx; do not copy the shortcut remapping unless we want that parity.
• Merged feat: add ability to create a new thread in the current project with shift+click and show shortcut in tooltip #5994 is the Shift+click workaround for the viewed project, not sidebar scope.
• Merged fix(web): keep the sidebar project filter across navigation #9416 persists the sidebar filter; feat(sidebar): fold the project scope into the search row #11315 folded scope into the search row.
• Open [Bug]: Command+Shift+N no longer creates a chat in the current worktree #9656 / fix(web): keep the current worktree on the new-local-thread shortcut #11015 are about worktree/branch inheritance on chat.newLocal, not this.

Suggested fix

When scopedProjectGroup is set, New should start a draft in that group’s resolved physical project (grouped / multi-env: reuse buildSidebarProjectPickerEntries or the group representative). When the sidebar is All projects, keep the picker.

Keep the draft project menu so the user can still switch. chat.new currently follows the same picker rule as the button; decide separately whether the shortcut should match.

After #9416, scope can stay on project A while the user is viewing a B thread via palette/URL. Sidebar New should follow scope; Shift+click / chat.newLocal can keep following the viewed thread.

Next step

Accepted. Small, localized web/desktop sidebar change. No open PR.

[nandorocker]

Sounds good.

Small suggestion: Shift+click could invert its current behavior and open the project picker instead. With normal click creating directly in the scoped project, choosing a different project feels like the more advanced action, and this would let you do that without leaving the current sidebar scope.

[MarconLP]

Warning

This comment was written by Claude Opus 5.5 in Claude Code, running in T3 Code. A human asked for it and read it before it was posted.

+1, and I'd go a step further than the sidebar filter: a setting so that New thread never opens the picker by default.

Most of my time goes into one project, even when I have several. I start thread after thread in that project, so the picker on every plain click is an extra step I almost never need. When I do want another project, Shift+click, Cmd+Shift+N, or the Change project control on the draft are enough.

Suggested setting, something like "New thread opens in":

• Ask every time (current behavior)
• Current project: the project of the thread I'm viewing, or else the last project I started a thread in. Shift+click then opens the picker, as @nandorocker suggested above.

A related trigger: I only noticed this because I started a chat without a project once (Cmd+Alt+N). That created an empty "No project" scratch project, and from then on a plain click opened the picker, although I still work in one real project. That scratch project probably shouldn't count toward the two-or-more-projects rule either.