Repository navigation
[Bug]: New worktree base branch stays on a non-existent main when the thread is opened while the project is still cloning #25719
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- Use a repository whose default branch is not
main(herestaging;origin/HEAD -> origin/staging, nomainon the remote), and a machine withinit.defaultBranch=main. - Add it to T3 Code by cloning it from the app.
- While the clone is still running, open a new thread for the project in New worktree mode.
- After the clone finishes, send a message.
Expected behavior
The base branch picker settles on the repository's default branch (staging) once the clone finishes, and the worktree is created from it.
Actual behavior
The picker selects main, and the selection stays after the clone finishes. Sending fails at the checkout step:
Workspace preparation failed during provision worktree: Git command failed in GitVcsDriver.createWorktree (/home/matheus/vik-app): git worktree add failed (ref_not_found)
Picking staging by hand in the base branch picker and retrying works.
Impact
Blocks the first thread in a freshly cloned project until the base branch is changed by hand.
Version or commit
Server and client from v0.1.3-nightly.20261026.3726. The same code is on main @ becf853.
Environment
Windows desktop client connected to a server in WSL2 (Ubuntu 24.04, git 2.43.0, init.defaultBranch=main).
The steps are reconstructed from timestamps: the repository's .git was created at 22:36:57 and packed-refs at 22:37:25, and the thread that failed was created at 22:38:02. The unborn-HEAD behavior and the resulting candidate were checked directly; I did not record the picker while the clone was running.
Logs or stack traces
While git clone runs, the new repository already exists with an unborn HEAD pointing to refs/heads/<init.defaultBranch>, and there is no refs/remotes/origin/HEAD yet:
$ git init -q unborn && cd unborn
$ git symbolic-ref --short HEAD
mainstatusDetails reports that unborn branch as the current branch (symbolic-ref --quiet --short HEAD). The ref list is still empty, so in BranchToolbarBranchSelector the worktree base candidate defaultBranchName ?? currentGitBranch resolves to main. The effect then stores it on the draft with setThreadBranch(..., automatic). Once activeThreadBranch is set, the effect never runs again, so the real default branch that appears after the clone is ignored.
Workaround
Select the default branch in the base branch picker before sending.
Related
- [Bug]: New worktree threads fail in a repository with no commits #22017 is the case where the repository really has no commits. Here the repository has commits; only the stale seed from the clone window is wrong.
Activity
zytek commentedon Oct 30, 2026
Confirming a likely instance of this bug with the branch names reversed: the repository uses main, but the first thread requested master.
Environment: Linux arm64 server, T3 Code desktop app connected remotely through t3 connect. The captured failure occurred on server 0.1.2. The user also tried 0.1.5, though whether that updated the client, server, or both is unconfirmed.
Evidence from the machine:
The failed run’s persisted workspacePreparation was {"type":"worktree","baseRef":"master","startFromOrigin":true}.
Git inspection showed local main, origin/main, and origin/HEAD → origin/main, with no local or remote master ref.
At 2026-10-30T20:27:41Z, the server trace recorded GitVcsDriver.createWorktree failing with git worktree add failed (ref_not_found).
The user confirmed that the first thread was opened during cloning and that a second thread works successfully.
mishdotdev commentedon Nov 11, 2026
Another instance, with git's built-in fallback name rather than a configured
init.defaultBranch.Setup: Linux desktop app, server and client on the same machine. I cloned
zen-browser/desktopfrom the app. Its default branch isdev(origin/HEAD -> origin/dev), and there is nomainormasteron the remote.init.defaultBranchis not set, so git names an unbornHEADmaster.Timeline (UTC):
.gitcreated)packed-refsgit worktree add failed (ref_not_found)The failed run's stored workspace preparation is
{"type":"worktree","baseRef":"master","startFromOrigin":true}. The server trace shows the scoped fetch ofrefs/heads/masterreportingcouldn't find remote ref, then the fallback to the baremastername, then the branch creation failing.A second thread opened after the clone finished got
{"type":"worktree","baseRef":"dev",...}and worked.So whatever name git gives the unborn
HEADduring the clone gets seeded:main,master, or a configured default. #25721's "only fall back to a listed current branch" approach would cover this case too.