fix(server): keep worktree creation working when git config is locked

[Gigioxx]

What Changed

A held .git/config.lock makes worktree creation fail after checkout has already succeeded, leaving the caller without the new worktree. Treat the optional branch.<new>.gh-merge-base write as best-effort: log a warning and return the usable worktree.

Why

The shared Git driver covers both thread bootstrap and direct worktree requests. Base-branch resolution already falls back to the default branch when this metadata is missing, so a locked config should not prevent starting a thread. Required checkout failures and cancellation still propagate.

Closes #11735.

Scope and approval

Maintainer-triaged bug: triage comment on #11735 (labels bug, accepted), which confirms configureBaseRef failing on a locked config after a successful git worktree add. This PR only makes that optional metadata write non-fatal; orphan cleanup for other failures is not part of it.

Verification

• Reproduced before the fix with the real driver and a temporary repository containing .git/config.lock: configureBaseRef failed with exit 255.
• After rebasing onto 0cf482b08b (Claude Opus 5.5, this session; resolved a test-file conflict by keeping main's new submodule and parallel-progress tests alongside this regression):
  • vp test run src/vcs/GitVcsDriverCore.test.ts -t worktree (apps/server): 19/19 passed, including the regression, which checks the returned branch, checked-out content, missing optional metadata, and the untouched lock.
  • vp lint and vp fmt --check on apps/server/src/vcs/: clean.
  • apps/server tsc --noEmit was not completed after the rebase (the machine was too loaded to finish it); it passed before the rebase. CI covers it.
• Not checked: Windows file locking behavior.

No UI changes.

Checklist

• This PR is small and focused
• I explained what changed and why
• No UI changes requiring screenshots
• No animation or interaction changes requiring a video

Created with GPT-6 in Codex. Rebase by Claude Opus 5.5 via Claude Code.

[macroscopeapp]

Approvability

Verdict: Approved at fc7431a

Macroscope's review found this PR approvable — This is a narrowly scoped server bug fix that makes optional worktree metadata configuration best-effort while preserving required worktree creation behavior. A regression test covers the locked-config scenario, resulting worktree contents, missing metadata, and lock preservation.

Notes:

• Diff unchanged. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: b888be8d-21ab-4239-b6f1-7d8781e95680

📥 Commits

Reviewing files that changed from the base of the PR and between f328db3 and fc7431a.

📒 Files selected for processing (2)

• apps/server/src/vcs/GitVcsDriverCore.test.ts
• apps/server/src/vcs/GitVcsDriverCore.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

createWorktree now treats gh-merge-base configuration as best effort. A locked .git/config no longer prevents worktree creation, and a test verifies the worktree remains valid while the lock file is unchanged.

Changes

Worktree base-ref resilience

Layer / File(s)	Summary
Best-effort base-ref configuration and validation apps/server/src/vcs/GitVcsDriverCore.ts, apps/server/src/vcs/GitVcsDriverCore.test.ts	createWorktree catches base-ref configuration failures, logs a warning, and completes successfully. The test covers creation with an existing .git/config.lock, expected worktree contents, missing gh-merge-base, and preservation of the lock file.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: t3dotgg

Merge Risk: ⚪ Minimal · up to fc743

Worktree creation remains available when optional base metadata cannot be written, with no actionable merge-blocking risk identified.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The change satisfies #11735. createWorktree now catches failure from the optional branch.<new>.gh-merge-base configuration, logs a warning, and returns the created worktree. The git worktree add…
Out of Scope Changes check	✅ Passed	The changes are limited to GitVcsDriver.createWorktree and its regression test. Both changes directly support #11735. No unrelated product behavior or files were changed.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2…
Title check	✅ Passed	The title is concise, conventional, and clearly describes the fix for worktree creation when Git configuration is locked.
Description check	✅ Passed	The description explains the problem, fix, scope, linked issue, verification results, limitations, and agent usage. It uses "What Changed" and "Why" instead of the template's "Problem" and "Change" he…

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

Dismissing prior approval to re-evaluate fc7431a

[henrikkvamme]

A held lock is not the only trigger. Concurrent worktree creation in one repository causes the same failure, without a sandbox or any lock file left behind.

On 2026-10-09, an app launched three worktree threads into one repository in the same second. One of them failed during workspace preparation:

Workspace preparation failed during provision worktree: Git command failed in GitVcsDriver.createWorktree.configureBaseRef ... Git command exited with a non-zero status

Each createWorktree call writes branch.<new>.gh-merge-base in the main checkout, and every git config write takes .git/config.lock. When two writes overlap, one of them exits 255.

Reproduction in a fresh repository, with git 2.54.0 on macOS:

git init -q
for i in $(seq 1 12); do git config branch.b$i.gh-merge-base main & done; wait

In three runs of 12 parallel writes, 5, 2 and 3 writes failed. All 10 failures were exit 255 with error: could not lock config file .git/config: File exists.

This PR makes the write best-effort, so it also covers the concurrent case. A short retry alone would fix the race, but not a lock that a sandboxed command holds for minutes. That makes this PR the better fix.