fix(server): parallel worktree launches no longer fail on .git/config lock#25700

Launching several worktree threads in one repository at once fails on Git's config lock (reported by a user running queue skills). Every worktree shares one .git/config, and Git takes .git/config.lock without waiting:

• git worktree add -b <branch> -- <path> origin/<base> writes the new branch's upstream. When that write loses the race, Git leaves the branch created but no worktree, so a retry fails with "branch already exists". 12 parallel adds in a scratch repo produced 24 of 49 worktrees.
• The temporary-branch rename after launch (git branch -m) fails after the ref has already moved, so the thread keeps a branch name that no longer exists.
• T3's base records (t3-merge-base, t3-merge-base-ref, gh-merge-base) and first-time submodule URL registration collided and were only logged as warnings, so branches lost their recorded base and worktrees got empty submodules.
• git push -u exits 0 but silently drops the upstream when it loses the race.

Serialize T3's own writers. Git commands that write the shared config take a per-repository lock, keyed by the git common dir. The lock wraps outside the global git process permit, since resolving the repository can itself need one. Covered: upstreams, branch creation, rename and deletion, base records, remote add, checkouts that create a tracking branch, submodule URL registration, and PR branch materialization (new PR branches also use the --no-track split below).

Keep checkouts parallel. createWorktree creates the branch first, then runs worktree add without the lock. Plain local checkouts don't take it either. A lone - start point maps to @{-1}, since git branch does not read it as the previous checkout. Submodule URLs are registered with a locked submodule init before the unlocked clone.

Survive git outside T3. An agent's own git push -u or a terminal can still hold the lock.

• Branches are created with git branch --no-track, which writes no config. When the start point is a remote-tracking ref, the upstream is set afterwards with --set-upstream-to, which also honors branch.autoSetupRebase.
• Plain config writes and upstream changes retry on lock contention (new failure reason config_locked) every 50 ms, up to 10 times. Permission errors print the same prefix but don't match, so they aren't retried.
• Rename doesn't retry, because a failed attempt can leave the ref moved.
• Trade-off: tracking now follows the start point rather than the user's branch.autoSetupMerge setting.

Push without -u. Pushes record the upstream afterwards with the retrying config writer, merge before remote so a lost write leaves no half upstream, plus branch.<name>.rebase when branch.autoSetupRebase asks for it, as push -u did. If that still fails, the push reports setUpstream: false and logs a warning.

Typed host methods. Source-control providers write shared config through git.createBranch and git.writeConfigValue on the host, not raw execute, so a provider can't skip the lock. GitHub's gh-merge-base record and PR branch creation use them. GitCafe's forced PR checkout passes --no-track and relies on the setBranchUpstream call that already follows it.

Parallel remote add. ensureRemote re-checks after a failed remote add and returns the remote a parallel call added for the same URL. It also retries on an external lock, since a failed add writes nothing.

Tests:

• 8 concurrent createWorktree calls from origin/<branch>, then 8 concurrent renames from inside the worktrees, counting overlapping config writers through a wrapping spawner. Peak is 8 on main, 1 with this change; every branch keeps its upstream and base.
• A launch from a remote branch while another process holds the config lock: the branch is created, and tracking lands once the lock is released. Fails at branch creation without the --no-track split.
• A config write blocked by an external lock lands once the lock is released. A launch whose base-ref write stays locked still creates its worktree. A push whose upstream can't be recorded reports setUpstream: false. The release tests drop the lock from the spawner when the blocked command fails, so the retry never races its budget; retries wait on the real clock (TestClock.withLive).
• Two concurrent ensureRemote calls for the same URL, forced to race, both return the same remote.
• Fetching a PR branch into a new local branch while another process holds the config lock: it tracks the remote once the lock is released.
• A push with branch.autoSetupRebase=always records rebase = true.
• - as a start point for a new branch, and missing-ref diagnostics for worktree add with and without a new branch.
• The GitHub provider calls createBranch and writeConfigValue.

vp run check:changed passes.

Not covered: GitLab, Azure DevOps, and Forgejo PR checkouts run glab, az, and tea, which T3 can't lock. A worktree add given a name that exists only on a remote creates a tracking branch without the lock.

Fetch before launch was not the cause: parallel launches against a remote with added latency held up with the existing single retry.

Opus 5.5, Claude Code in T3 Code.

🤖 Generated with Claude Code