Before submitting
Area
apps/web
Problem or use case
The workspace selector when starting a thread only offers Current checkout or New worktree. There is no way to start a fresh conversation in a worktree that already exists — whether it was created by t3code, or by JetBrains / plain git worktree add.
Concrete flow: I'm working in worktree A, I want a clean conversation, but I want it to keep operating on worktree A instead of the main checkout or a brand-new worktree.
Proposed solution
Add an "Existing worktrees" group to the workspace selector, listing the project's worktrees. The data already exists — vcs.listRefs annotates each ref with worktreePath from git worktree list --porcelain, so externally-created worktrees appear too. Selecting one binds the thread to it via the existing reuseExistingWorktree path (the same one branch selection already uses) — no new git op, and no server/contract changes.
The active-worktree label also gains the worktree's folder name (Current worktree · <name>) so you can tell which worktree a thread is in.
Why this matters
Worktrees are already central to the workflow, but they can only be created, not reattached to. Being able to pick an existing worktree makes it practical to start a new/clean conversation without abandoning in-progress work in a previous worktree.
Smallest useful scope
Just the desktop workspace Select: an "Existing worktrees" group sourced from vcs.listRefs, reusing the existing reuse-on-select path. No server changes.
Alternatives considered
Existing worktrees can already be reused indirectly by picking their branch in the branch selector (it shows a "worktree" badge). This surfaces them as first-class workspace choices instead, which is much more discoverable.
Risks or tradeoffs
Derived from the branch ref list, so it won't list worktrees whose branch isn't within the first 100 refs, or detached-HEAD worktrees. Those would need a dedicated git worktree list RPC. Refiles the idea from #1094 (closed for staleness with an invite to resubmit against current main), rebased on current main. Related: #3070, #2708, #3697.
Before submitting
Area
apps/web
Problem or use case
The workspace selector when starting a thread only offers Current checkout or New worktree. There is no way to start a fresh conversation in a worktree that already exists — whether it was created by t3code, or by JetBrains / plain
git worktree add.Concrete flow: I'm working in worktree A, I want a clean conversation, but I want it to keep operating on worktree A instead of the main checkout or a brand-new worktree.
Proposed solution
Add an "Existing worktrees" group to the workspace selector, listing the project's worktrees. The data already exists —
vcs.listRefsannotates each ref withworktreePathfromgit worktree list --porcelain, so externally-created worktrees appear too. Selecting one binds the thread to it via the existingreuseExistingWorktreepath (the same one branch selection already uses) — no new git op, and no server/contract changes.The active-worktree label also gains the worktree's folder name (
Current worktree · <name>) so you can tell which worktree a thread is in.Why this matters
Worktrees are already central to the workflow, but they can only be created, not reattached to. Being able to pick an existing worktree makes it practical to start a new/clean conversation without abandoning in-progress work in a previous worktree.
Smallest useful scope
Just the desktop workspace
Select: an "Existing worktrees" group sourced fromvcs.listRefs, reusing the existing reuse-on-select path. No server changes.Alternatives considered
Existing worktrees can already be reused indirectly by picking their branch in the branch selector (it shows a "worktree" badge). This surfaces them as first-class workspace choices instead, which is much more discoverable.
Risks or tradeoffs
Derived from the branch ref list, so it won't list worktrees whose branch isn't within the first 100 refs, or detached-HEAD worktrees. Those would need a dedicated
git worktree listRPC. Refiles the idea from #1094 (closed for staleness with an invite to resubmit against currentmain), rebased on currentmain. Related: #3070, #2708, #3697.