Synced from GitHub
Another entry point into the same stored-thread.branch problem, which may be worth covering in the same fix.
t3_thread_launch with workspaceStrategy: { type: "existing_worktree", worktreePath } and no branch: the server does branch = requestedBranch ?? null and never reads the checkout, so the thread stores null while the worktree sits on a real branch. The sidebar shows no branch, and t3_worktree_status returns attached: true, worktreePath: <path>, branch: null. Verified on 0.1.6 by binding a thread to an existing worktree on branch X: the agent's own git rev-parse --abbrev-ref HEAD returns X, the thread record says null.
Two notes on the proposed reconciliation:
- The old
followWorktreeBranchDriftskipped shared worktrees. Threads bound to a long-lived, reused worktree are the main consumers ofexisting_worktree— in our setup a pool of pre-warmed slots claimed per branch — so if that guard still skips them, this entry point stays broken after the fix. - Turn-end reconciliation leaves launch → first-turn-end unlabeled. Resolving the branch at bind time, a
rev-parse --abbrev-ref HEADin theexisting_worktreepath, closes that window and is independent of drift-following.
