[Bug]: Command+Shift+N no longer creates a chat in the current worktree

[kyrregjerstad]

This was generated by AI during triage.

Before submitting

• I searched existing issues and did not find an open duplicate.
• I included enough detail to reproduce and investigate the problem.

Area

apps/web

Steps to reproduce

1. Open a thread that is attached to a feature branch or worktree.
2. Press Command+Shift+N to quickly start another chat for parallel work in the same project.
3. Type a prompt and send it without changing the workspace controls.
4. Inspect the new thread's branch and working directory.

Expected behavior

Command+Shift+N should create the new chat in the branch and worktree of the thread that was active when the shortcut was pressed.

This was the shortcut's original purpose. PR #56 introduced mod+shift+n as "new chat with same Git state."

Actual behavior

The new chat keeps the project but drops the active branch and worktree. It uses the project's configured new-thread defaults instead, which can place the agent in the main checkout, another branch, or a fresh worktree.

This is extremely frustrating during feature work. The natural flow is to press Command+Shift+N, send a small parallel task, and return to the original chat. The new draft looks close enough to the current context that it is easy to send the message before noticing the workspace changed. It often takes longer than I would like to admit to realize that the agent has been working in the wrong worktree.

The shortcut still maps to chat.newLocal, but its handler now calls the same generic startNewThreadFromContext path as an ordinary new thread. That function intentionally inherits only the project. It does not pass the active branch or worktreePath.

Impact

Major degradation or frequent failure

An agent can inspect or edit the wrong checkout before the user notices. Apart from wasted time, this can put changes on the wrong branch and make parallel work unreliable.

Regression history

• PR Add shortcuts for terminal close and chat with same Git state #56 added Command+Shift+N specifically for a new chat with the same Git state.
• PR Stop new threads inheriting checkout/branch from viewed thread #4411 later removed implicit workspace inheritance from every new-thread entry point. This also changed the behavior of the dedicated chat.newLocal shortcut.
• PR Preserve checkout context when creating threads #3918 proposed preserving checkout context again, but was closed without merging.
• Issue [Feature]: Start a thread in an existing worktree (not only current / new) #3796 describes the related need to start a clean conversation in the current worktree. PR feat(web): start a thread in an existing worktree #3798 attempted an explicit worktree picker, but was closed without merging.
• PR feat(web): reuse existing worktrees #8517 adds a picker for existing worktrees. It does not restore the fast shortcut behavior.

Suggested fix

Keep the generic new-thread commands aligned with project defaults, but restore the distinct behavior of chat.newLocal:

• Resolve the active thread or draft's branch, worktreePath, and environment mode.
• Pass that workspace context explicitly to handleNewThread.
• Keep Command+Shift+N bound to this command.
• Add a regression test proving the shortcut preserves both a local feature branch and an existing worktree.

Version or commit

Current main as of September 4, 2026.

Environment

macOS, web/desktop client

Workaround

Create the draft, then manually select the previous or existing worktree before sending. A thread's context menu may also offer "New thread on branch." Both are slower and easy to forget when the shortcut suggests that it already preserves the current Git state.

[Mnigos]

This is intentional since #4411. That PR removed the implicit branch/worktree carry-over from every new-thread entry point, Cmd+Shift+N included, so new threads always follow the project's configured defaults. The explicit ways to reuse the current checkout are still there: "New thread on " in the thread's sidebar context menu, and "Previous worktree" in the composer's workspace selector.

If a keyboard shortcut for "New thread on " would be welcome, that seems like the cleanest way to get the old speed back without reverting the defaults decision. Happy to do that if a maintainer confirms.