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

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 #56 added Command+Shift+N specifically for a new chat with the same Git state.
• PR #4411 later removed implicit workspace inheritance from every new-thread entry point. This also changed the behavior of the dedicated chat.newLocal shortcut.
• PR #3918 proposed preserving checkout context again, but was closed without merging.
• Issue #3796 describes the related need to start a clean conversation in the current worktree. PR #3798 attempted an explicit worktree picker, but was closed without merging.
• PR #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.

Start at the chat.newLocal shortcut and trace its current call through startNewThreadFromContext to handleNewThread. Add or update the regression test described in the issue for a local feature branch and an existing worktree; done means Command+Shift+N preserves the active branch and worktree while ordinary new-thread defaults remain unchanged.