Worktree setup: surface git's stderr and retry briefly when .git/config.lock blocks configureBaseRef

[seankoji]

Problem

New-thread worktree setup can fail with this message and nothing else:

Workspace preparation failed during provision worktree: Git command failed in GitVcsDriver.createWorktree.configureBaseRef (/path/to/repo): Git command exited with a non-zero status.

The message doesn't say why git failed, so the cause is hard to find. Retrying immediately often fails the same way, then works later with no change.

Cause I found

In my case an empty <repo>/.git/config.lock was present. configureBaseRef writes branch.<name>.gh-merge-base to the shared .git/config, and git refuses a config write while that lock exists.

The lock came from the Claude Code Linux (bubblewrap) sandbox. It bind-mounts over .git/config and config.lock to protect them, which needs an existing target, so it creates an empty config.lock placeholder. The placeholder can stay behind while a sandboxed session is running or after an unclean exit. Tracked upstream at anthropics/claude-code#78818, which is still open.

This hits T3 hard in a repo with many concurrent agent sessions and worktrees sharing one .git/config. I could not find an existing T3 issue for it. The stale lock has no process holding it open, and it later disappeared by itself, so it looks transient.

Plain git can also fail here when parallel git worktree add calls race on the config lock.

Suggestion

1. Include git's stderr (for example could not lock config file ...: File exists) in the surfaced error, or at least in the server log. Today it appears in neither the UI message nor server.trace.ndjson.
2. Retry configureBaseRef briefly on a config-lock error, for example a few attempts over a couple of seconds. Git also has core.configLockTimeout for this.
3. Optionally treat a failed gh-merge-base write as non-fatal: the worktree and branch are already created, and the setting is only a convenience. Warn instead of failing the whole setup.
4. If the lock is still present after retries, name it in the error and tell the user to check for a stale .git/config.lock.

Environment

T3 Code Nightly, Linux, repo with about 40 linked worktrees, Claude Code 2.1.302 running sandboxed sessions in the same repo.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for the write-up. This is the same problem tracked in #11735, an accepted bug where configureBaseRef fails on a held .git/config.lock (including the Claude Code sandbox placeholder), and you've already added your evidence there. Open PR #11773 makes the gh-merge-base write non-fatal, and git stderr in command errors was addressed in #4380 via #8645 (if you still see a bare message on a current Nightly, mention it on #11735). Closing this as a duplicate so the discussion stays in one place; please add the retry and stderr suggestions on #11735 if they aren't covered there yet.