fix(server): skip git status scans while the index is locked

[Gigioxx]

Background Git status scans can repeatedly run LFS clean filters while an index lock prevents caching the results. Git status can still exit successfully, so retry backoff based on command failures would miss this case.

Resolve the working tree's index through Git and check its lock before running status or numstat. Return a clear error while locked and resume on the next request after unlock. The shared status reader covers nested projects and linked worktrees across all clients.

Fixes #9776.

Verification:

• Reproduced with real Git and an instrumented clean filter: three locked status polls invoked the filter three times, each exiting 0. The three new regressions fail on the original implementation.
• With the fix, repeated locked polls invoke no filters, preserve the lock, and resume with correct status after unlock in root, nested, and linked-worktree repositories.
• All 170 tests pass across GitVcsDriverCore.test.ts, GitVcsDriver.test.ts, and GitManager.test.ts. Server typecheck, targeted lint, formatting, and git diff --check pass.

This adds one Git path lookup per local scan. It prevents scans when the lock already exists; it does not cancel a scan if another process creates a lock afterward. No lock deletion, LFS cleanup, or checkpoint changes. The reproduction verifies repeated clean-filter execution, not the reported macOS LFS temp-file accumulation. No UI changes or browser run.

Model: GPT-6. Harness: Codex in T3 Code.

---

Note

Medium Risk
Touches the hot path for background repo status polling across all clients; behavior change is intentional but could surface transient errors during legitimate Git operations that hold the index lock.

Overview
Local status reads now bail out before git status when the repository index is locked, avoiding repeated LFS/clean-filter work while Git holds index.lock (status can still exit 0, so failure-based backoff did not help).

readStatusDetailsLocal resolves the index via git rev-parse --git-path index, checks for index.lock on disk, and returns a clear GitCommandError until the lock is gone; normal status (and downstream numstat) runs again after unlock. Each local scan adds one extra Git path lookup.

Tests cover root, nested cwd, and linked worktrees with a probe clean filter: three locked polls must not run the filter; unlock restores success. The stable-diagnostics test expects the new rev-parse --git-path index call before porcelain status.

^{Reviewed by Cursor Bugbot for commit a91c9a4. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Skip git status scans when index lock is present in GitVcsDriverCore

• Adds an index-path preflight to GitVcsDriverCore.readStatusDetailsLocal using git rev-parse to check for an index lock file before running git status.
• If the lock exists, the method fails early with a GitCommandError index-lock diagnostic instead of running the status command or clean filter. Normal status processing resumes once the lock is removed.
• Risk: File-system errors during the lock check in readStatusDetailsLocal are now wrapped in GitCommandError rather than propagating raw.

^{Macroscope summarized a91c9a4.}

[macroscopeapp]

Approvability

Verdict: Approved at a91c9a4

Macroscope's review found this PR approvable — This is a focused Git status bug fix that adds a lock preflight, avoids repeated clean-filter work during index operations, and resumes the existing status path after unlock. The production logic is localized and covered by root, nested, and linked-worktree regression tests.

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