Repository navigation
t3_thread_launch accepts an explicit branch that already exists, then the thread fails with branch_already_exists #31263
Description
What happened
An agent launched a new worktree thread through t3_thread_launch with a branch name that already existed and was checked out in another T3 worktree. The tool call reported success, so the agent carried on. The new thread then failed before its provider started, and the error didn't name the branch.
Diagnosis
checkWorktreeBase is the check t3_thread_launch runs before it accepts a launch. It validates the base ref, not whether the requested branch already exists. Provisioning then runs in the background, where GitVcsDriverCore.createWorktree runs createBranchAt unconditionally, and git refuses. By then the caller already has a threadId and runId, so an agent can't correct the name in the same turn.
The message also reports the wrong step and leaves out the branch: the failing command is git branch, but the text says git worktree add failed.
This is still the code on main at 935818e.
Steps to reproduce
Reproduced against an isolated server on 0.1.7 and on 0.1.8-nightly.20261104.4192:
git init -b main repo && cd repo && git commit --allow-empty -m initgit worktree add -b feature/taken ../wtt3 project add .t3 thread start --json --worktree main --branch feature/taken --provider claudeAgent --model claude-haiku-5-5 . "reply ok"
The command exits 0 and prints a threadId and runId. The thread then fails with the error under Evidence.
On 0.1.7 I got the same result for a branch that exists but isn't checked out anywhere (git branch feature/idle).
Expected: the caller finds out in the tool result that the branch is taken, and no failed thread is left behind.
Version
0.1.6 (first hit), reproduced on 0.1.7 and 0.1.8-nightly.20261104.4192
Environment
macOS 26.7.1, git 2.54.0, Node v26.0.0, Claude Code 2.1.318
Evidence
$ t3 thread start --json --worktree main --branch feature/taken ...
{"threadId":"mcp:<id>","projectId":"<id>","runId":"run:thread:mcp%3A<id>:ordinal:1"}
exit=0
# failure recorded on the thread
Workspace preparation failed during provision worktree: Git command failed in GitVcsDriver.createWorktree.createBranch (<project>): git worktree add failed (branch_already_exists)
# git state afterwards: the existing branch and worktree are untouched, nothing new
<project> [main]
<wt> [feature/taken]In the original occurrence (0.1.6) the launch failed about 57 ms into worktree creation.
Related issues
Not a duplicate of these, which share the error or code path:
- [Bug]: Worktree launch reported an immediate "branch already exists" failure 7 hours after it was requested #26577: same error, but that report is about the failure taking 7 hours to appear.
- [Bug]: A failed worktree checkout leaves its new branch behind, so every Retry fails with branch_already_exists #29515 and fix(server): a failed worktree checkout no longer blocks every Retry #29584: a branch left behind by a failed checkout. Here the branch existed before the launch, so that cleanup doesn't apply.
- [Bug]: Worktree launch with an explicit branch name fails opaquely when a branch already owns its prefix (e.g. werkstatt vs werkstatt/baseline) #29297 and fix(server): worktree launches refuse branch names an existing branch blocks #29328: a branch name blocked by its prefix. The new pre-check only matches
existing/andbranch/prefixes, so an exact match still gets through. - fix(server): launching a worktree thread on a taken branch name no longer fails #29228: renames a taken branch to
name-1. fix(server): worktree launches refuse branch names an existing branch blocks #29328 says explicit names are never renamed, so the two PRs disagree on what should happen. That direction is the decision a maintainer needs to make here.
If refusing is the direction, adding an exact-name match to the #29328 pre-check would cover this.
Fix applied or workaround
Pick an unused branch name and launch again. Nothing was changed on the machine.
Filed by
Claude Opus 5.5 in Claude Code (running inside T3 Code), following the T3 triage playbook. Filed with gh, because this account can't apply the via-triage label.
Activity
VanTanev commentedon Nov 13, 2026
Note
🤖 GPT-6.1 Sol responding on behalf of VanTanev
Another observed incident on Windows with Codex
gpt-6.1-sol, medium reasoning effort.T3 had already created the requested branch and attached its worktree to the original thread.
The agent then called
t3_thread_launchwith the same explicit branch name.The tool returned
status: "preparing"with new thread and run IDs.That new thread failed before its provider started.
The sequence comes from persisted thread activity and a recorded
t3_worktree_statusresult:The original thread records successful workspace preparation.
Its agent calls
t3_thread_launchwith this strategy:{ "type": "worktree", "branch": "t3/theo-tooling-research", "baseRef": "origin/master", "startFromOrigin": true }The new thread records this error:
After the failure, the original agent calls
t3_worktree_status.The tool returns
attached: true, the same branch, and an existing worktree path.A recorded read of that worktree's Git
HEADalso names the same branch.The duplicate launch was an agent error.
The agent should have checked its workspace state before it requested another worktree.
This incident also confirms the failure mode in this issue.
The launch result does not identify the branch conflict.
The later error omits the branch name and existing worktree.
The original user asked for a new worktree.
The failed thread's initial message said to continue in that worktree.
That message could not prevent the error because workspace preparation failed before its agent started.
Related context: #28986.
This incident began in a user-created thread whose worktree was already attached, rather than an agent-created receiving thread.
Observed once on November 13, 2026.
No separate minimal reproduction or provider-request capture was performed.
The installed T3 version is unknown.
The evidence establishes the duplicate request and failure, but does not establish which workspace context reached the original model.
The original agent later found the existing worktree and continued there.
Private paths, thread IDs, and unrelated research details are omitted.
pouyarezvani commentedon Nov 14, 2026
Another case on 0.1.10-nightly.20261114.4695, where reusing the existing branch was the point of the launch.
An agent wanted a thread for an open PR whose branch already existed locally and was not checked out in any worktree, so it called
t3_thread_launchwith:{ "type": "worktree", "baseRef": "<pr-branch>", "branch": "<pr-branch>", "startFromOrigin": false }The thread failed during workspace preparation:
The only way through was to delete the local branch and launch again with the remote copy as
baseRef.#31279 turns this into an up-front refusal, which is much better than a failed thread, but the launch still cannot do what was asked.
GitVcsDriverCore.createWorktreealready checks out an existing branch when it gets nonewRefName;ThreadLaunchServicealways passesnewRefName: branch. A possible next step:existing_worktreeinstead.baseRefis the branch itself or resolves to the same commit: check it out (refName: branch, nonewRefName) instead of creating it.baseRef: refuse, since reusing it would silently ignore the requested base.Case 2 makes "open a thread on this PR's branch" a single launch.