fix(web): keep the current worktree on the new-local-thread shortcut

[maria-rcks]

Cmd/Ctrl+Shift+N (chat.newLocal) routed through the generic startNewThreadFromContext, which inherits only the project by design, so a quick parallel chat started from a feature-branch thread silently landed on the project's configured new-thread defaults instead of the branch and worktree the user was looking at.

The shortcut now goes through its own startNewLocalThreadFromContext, which reads the active thread or draft's branch, worktreePath, and env mode and passes them to handleNewThread — the same explicit options the thread menu's "New thread on " already uses, with startFromOrigin: false so reusing a checkout never re-bootstraps it. Every other new-thread entry point (Cmd+N, the sidebar button, the command palette) keeps the #4411 project-defaults behavior.

Verified: vp run --filter @t3tools/web typecheck exit 0, no errors. vitest run apps/web/src/lib/chatThreadActions.test.ts --pool=forks 12 passed, including two new cases covering worktree inheritance and the branch-only local case (vp test run fails to boot its default thread pool in my environment, on unmodified origin/main files too, so I ran the same runner with --pool=forks). vp lint on the three changed files exit 0.

Out of scope: the sidebar's "new thread" button advertises the chat.newLocal shortcut label as the keyboard twin of shift+click in single-project setups. Shift+click still uses project defaults, so that tooltip pairing is now slightly loose; changing it would touch a second entry point's behavior, which this fix deliberately leaves alone.

Fixes #9656

UI evidence

Compared parent b7b3ef1e6f and head d40a3b4 using the same real sandbox repository and existing feature/worktree-shortcut worktree. Selected that worktree in the branch picker, entered an unsent draft, then pressed Cmd+Shift+N. The parent resets the new draft to main; this change retains the selected branch and worktree. This verifies the client draft flow; provider execution was not tested.

Evidence captured with gpt-6-astra (low reasoning) in Codex.

Done by Claude Opus 5 (1M context) in Claude Code.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Starting a local chat thread now preserves the currently viewed branch and worktree.
  • Local threads retain the appropriate environment settings and remain on the local checkout rather than starting from the origin.

• Bug Fixes

  • Improved behavior when creating local threads from active chats or drafts.
  • Added fallback handling when no active thread or draft is available.

[macroscopeapp]

🟠 High lib/chatThreadActions.ts:143

startNewLocalThreadFromContext always passes startFromOrigin: false, so a draft with envMode: "worktree", no worktreePath, and startFromOrigin: true creates its worktree from the stale local branch instead of origin. Preserve the draft's setting when no existing checkout is being reused, while keeping false for real threads or drafts with an existing worktreePath.

Suggested change

	startFromOrigin: false,
	startFromOrigin: thread || worktreePath ? false : draft?.startFromOrigin,

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/web/src/lib/chatThreadActions.ts around line 143:

`startNewLocalThreadFromContext` always passes `startFromOrigin: false`, so a draft with `envMode: "worktree"`, no `worktreePath`, and `startFromOrigin: true` creates its worktree from the stale local branch instead of `origin`. Preserve the draft's setting when no existing checkout is being reused, while keeping `false` for real threads or drafts with an existing `worktreePath`.

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a localized shortcut bug fix with focused production changes and regression tests, preserving the active branch/worktree without altering generic thread creation or product defaults. An unresolved High-severity edge case remains for origin-based worktree drafts without an existing worktree path.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 2842c694-4681-4d16-b802-67d6a6d42f4e

📥 Commits

Reviewing files that changed from the base of the PR and between b7b3ef1 and d40a3b4.

📒 Files selected for processing (3)

• apps/web/src/lib/chatThreadActions.test.ts
• apps/web/src/lib/chatThreadActions.ts
• apps/web/src/routes/_chat.tsx

Included review availability: Your plan provides up to 10 included reviews per hour; 7 remain after this review.

---

📝 Walkthrough

Walkthrough

The change adds a context-aware local thread action. It preserves the active branch and worktree, derives the environment mode, disables origin starts, and connects this behavior to the chat.newLocal shortcut with regression tests.

Changes

Local thread context

Layer / File(s)	Summary
Context-aware local thread action apps/web/src/lib/chatThreadActions.ts, apps/web/src/lib/chatThreadActions.test.ts	The action accepts branch and worktree context, derives environment settings, forces startFromOrigin: false, and falls back to defaults when no context exists. Tests cover worktree and branch-only cases.
Local shortcut integration apps/web/src/routes/_chat.tsx	The chat.newLocal shortcut now calls startNewLocalThreadFromContext, while chat.new keeps the generic action.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Severity of issue fixed: Medium

Suggested reviewers: t3dotgg, juliusmarminge

Merge Risk: ⚪ Minimal · up to d40a3

Cmd/Ctrl+Shift+N now creates local chats in the active branch and worktree while regular new-chat behavior remains unchanged. Current merge-readiness risk is minimal.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 3 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The implementation satisfies issue #9656 by preserving the active thread or draft’s branch, worktree path, and environment mode for chat.newLocal, while keeping generic new-thread entry points unchang…
Out of Scope Changes check	✅ Passed	The changes are limited to the new-local-thread action, its shortcut wiring, and regression tests. They directly support issue #9656 and do not introduce unrelated behavior changes.
Title check	✅ Passed	The title clearly and concisely describes the main fix: preserving the current worktree when using the new-local-thread shortcut.
Description check	✅ Passed	The description explains what changed, why it changed, scope boundaries, validation results, linked issue, and UI evidence. It does not use the template headings or checklist, but it provides the requ…

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[maria-rcks]

Note

Written by claude-fable-5-1 on behalf of Maria

Converting to draft pending a maintainer call. Two independent reviews of this head found the same problem: chat.newLocal never carried branch/worktree state (pre-#4411 it called handleNewThread(projectRef) with no options; chat.new did the carrying), and docs/user/keybindings.md documents both shortcuts as using new-thread defaults. Repurposing it is a product decision rather than a bug fix, and the change also flips startFromOrigin on an already-open draft.

If a shortcut for "New thread on " is wanted, the cleaner route is a new keybinding rather than changing this one. Happy to rework it that way if a maintainer confirms.

[shivamhwp]

Note: GPT-6 on behalf of shivam (@shivamhwp).

Preserve an origin-based draft's startFromOrigin when worktreePath is null. There is no existing checkout to reuse in that case, and forcing false changes where the pending worktree will start. The current new-thread handler applies these explicit options even when it reuses the already-open draft.

The product-decision hold remains appropriate. Before #4411, startNewLocalThreadFromContext passed only the project, while the generic action carried checkout context. The current documentation still says both shortcuts use project defaults. Please resolve that intended behavior before repurposing the shortcut.