feat(web): start a thread in an existing worktree

[Brechard]

Closes #3796.

What changed

Adds an "Existing worktrees" group to the workspace selector so a thread can be started directly in a worktree that already exists (t3code-created or one made by JetBrains / git worktree add), instead of only "Current checkout" / "New worktree".

• deriveExistingWorktreeOptions builds the list from the branch refs — each ref already carries worktreePath from git worktree list (vcs.listRefs) — excluding the main checkout and the current worktree, deduped by path.
• Selecting one binds the thread to it: draft via setDraftThreadContext, server thread via updateThreadMetadata (stopping a running session first). No git op runs — the server adopts the existing worktree path as the thread cwd, mirroring the branch selector's existing reuseExistingWorktree path.
• Added to both the desktop workspace Select and the mobile radio menu.
• The active-worktree label now includes the folder name (Current worktree · <name>) so you can tell which worktree a thread is in.

Why

Worktrees could be created but not reattached to when starting a thread. This makes it practical to start a clean conversation while continuing to operate on a previous worktree.

Notes

• Web-only; no server/contract changes (reuses vcs.listRefs + existing acceptance of a pre-existing worktreePath on thread create).
• Rebased on current main; refiles the idea from Add open-worktree mode and reuse existing worktrees on send #1094 (closed for staleness, invited to resubmit).
• +263 lines, incl. unit tests for deriveExistingWorktreeOptions and the label helpers.
• Known limits: worktrees whose branch isn't in the first 100 refs, and detached-HEAD worktrees, aren't listed.

Before

After

---

Note

Medium Risk
Touches thread cwd binding, session stop, and first-send worktree creation races in the composer; mistakes could run turns in the wrong directory or spawn duplicate worktrees, though behavior reuses existing metadata adoption paths with no server changes.

Overview
Adds an Existing worktrees section to the workspace picker (desktop select and mobile menu) so threads can bind to worktrees already on disk—not only Current checkout or New worktree.

deriveExistingWorktreeOptions builds that list from branch refs’ worktreePath (from git worktree list), excluding the main checkout and active worktree, with canonicalizeWorktreePath for dedupe/exclusion across path spellings. Picking one sets branch + worktreePath via draft context or updateThreadMetadata (stopping a live session when needed), without creating a new worktree.

Optimistic state in ChatView, BranchToolbar, and the branch selector keeps labels, branchCwd, and first-send logic aligned before metadata lands: pending worktree path overrides avoid spawning a new worktree on a racing first message, and the first send can await metadata that includes the chosen path. Workspace labels now show the folder name (e.g. Current worktree · feature-a).

Unit tests cover deriveExistingWorktreeOptions and updated label helpers.

^{Reviewed by Cursor Bugbot for commit 78862d4. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add existing worktree selection to the branch toolbar for starting threads

• Adds an 'Existing worktrees' group to both the desktop (BranchToolbarEnvModeSelector.tsx) and mobile (BranchToolbar.tsx) workspace selectors, listing worktrees derived from VcsRef.worktreePath (excluding the main checkout and active worktree).
• Selecting an existing worktree optimistically updates env mode, workspace label, and branch picker context without waiting for server confirmation.
• On first message send, the chosen worktree path is passed directly so no new worktree is created; for server threads, branch and worktreePath are persisted before the turn starts via updateThreadMetadata.
• Adds canonicalizeWorktreePath in worktreeCleanup.ts to normalize paths (backslashes, trailing slashes) for deduplication and exclusion comparisons.
• Risk: optimistic state in ChatViewContent and BranchToolbar must be cleared correctly on thread change and mode switches; mismatches could cause a send to target the wrong worktree.

^{Macroscope summarized 78862d4.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 8adaf0de-393a-4c4c-81b6-67b364ed3bd7

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Needs human review

1 blocking correctness issue found. This PR introduces a new feature for starting threads in existing worktrees, which constitutes significant new user-facing capability. Additionally, there is an unresolved high-severity review comment identifying a potential bug where stale worktree path overrides may cause operations to target the wrong checkout.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

There are 3 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f7c4947. Configure here.}