[fixfon]

Closes #21328

Problem

git worktree add writes the checkout files first and the index last. Git only trusts an entry's cached stat when the file's mtime is in an earlier second than the index file, so every file written in that last second stays racily clean. Nothing T3 runs after creating a worktree ever rewrites its index (status polling and checkpoint capture deliberately don't, see #14718 and #10792), so those entries stay racy for the life of the worktree and every status refresh and checkpoint capture re-hashes them (#21328).

Change

At the end of GitVcsDriverCore.createWorktree, after the submodule update, the new worktree's index is refreshed once with git update-index -q --refresh. A refresh in the same second as the index write would leave the entries racy, so it first waits until the wall clock is past the index file's mtime second (plus a 25 ms margin for timestamp lag). A failed refresh is logged at Warn and ignored, so worktree creation still succeeds.

Status and capture still never write the index, and clones are unchanged.

Scope and approval

Triaged and accepted by the maintainer as a narrow performance bug: #21328 (comment)

Verification

Two new tests in apps/server/src/vcs/GitVcsDriverCore.test.ts:

• leaves no racily clean entries in a new worktree's index creates a worktree with 21 tracked files and checks that every git ls-files --debug mtime second is below the index file's mtime second, which is Git's own racy rule.
• still creates the worktree when the index refresh fails makes update-index exit 128 and checks the refresh was attempted once and the worktree still exists.

Without the change both fail (21 entries share the index's second; no refresh is attempted). With it both pass, 15 out of 15 runs in a loop. The full GitVcsDriverCore.test.ts and GitVcsDriver.test.ts pass. Format, lint and apps/server typecheck are clean.

Not checked: Linux (tested on macOS only), and timings on a large real repo. Worktree creation now waits up to about 1 s for the index second to pass.

Claude Sonnet 5.5 (xhigh) via T3 Code.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: d479ee11-6d6b-45dd-ba07-482fa725dc73

📥 Commits

Reviewing files that changed from the base of the PR and between 39496d7 and 3a3eb59.

📒 Files selected for processing: 2

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

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.

📝 Walkthrough

Worktree creation now waits past the index timestamp boundary and attempts a quiet index refresh. Refresh failures are logged without stopping worktree creation. Tests cover failure handling and index-entry timestamps.

Changes: Worktree index refresh

Layer / File(s)	Summary
Refresh worktree index apps/server/src/vcs/GitVcsDriverCore.ts, apps/server/src/vcs/GitVcsDriverCore.test.ts	The driver waits past the index timestamp boundary, runs update-index -q --refresh, and continues when the refresh fails. Tests verify worktree creation after a refresh failure and verify that index entries precede the index timestamp.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: macodev00

Merge Risk: ⚪ Minimal · up to 3a3eb

Worktree creation remains available if the index refresh fails, and the new regression test checks that successfully refreshed worktrees avoid racily clean entries. No merge-blocking issue was established.

Security architecture risk: 🔵 Low · up to 3a3eb

The refresh preserves existing access controls and tolerates ordinary failures. However, it widens an existing cancellation window in worktree handoff: a created checkout and branch can remain unattached and require manual cleanup.

Retained concerns

• Low · reliability · inferred: The new interruptible refresh phase widens the existing MCP handoff cleanup gap after checkout creation but before ownership and rollback are established. Cancellation during this phase can leave a worktree and branch unattached to the thread; repeating the handoff with that branch is then rejected.

Security review details

Security Blast Radius

• inferred — The added operation exercises existing server-side Git authority over the newly created worktree and its index. Inspected changes do not add a new service, tenant boundary, credential source, or externally selectable refresh target.

Trust Boundaries and Controls

• observed — MCP handoff continues to require capability and thread scope before execution, and retains its per-thread in-flight guard. The refresh is reached through the existing workflow, manager, and driver chain.

Resilience and Maintainability Implications

• observed — Thread launch records the claimed worktree path before the refresh and has cancellation cleanup for that path. MCP supplies no equivalent early claim callback and obtains the path only when creation returns, so the launch protection does not cover the handoff concern.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the primary change: preventing new server worktrees from re-hashing every file during status operations.
Linked Issues check		Issue #21328 requires one post-creation index refresh for new worktrees. GitVcsDriverCore.createWorktree now resolves the index path, waits until the index mtime second plus a 25 ms margin has passe…
Out of Scope Changes check		The reviewed production diff adds only the worktree index refresh and its timing constant. The reported test diff adds two tests for the same behavior. These changes directly support issue #21328, and…
Description check		The pull request description includes all required sections: Problem, Change, Scope and approval, and Verification. It explains the issue, implementation, maintainer approval, focused tests, observed …

Full details: Linked Issues check

Explanation

Issue #21328 requires one post-creation index refresh for new worktrees. GitVcsDriverCore.createWorktree now resolves the index path, waits until the index mtime second plus a 25 ms margin has passed, and runs git update-index -q --refresh after submodule handling. The refresh is ignored with Warn logging when it fails. The reported tests cover racily clean entries and refresh failure. The summary states that status, capture, and clone behavior remain unchanged.

Full details: Out of Scope Changes check

Explanation

The reviewed production diff adds only the worktree index refresh and its timing constant. The reported test diff adds two tests for the same behavior. These changes directly support issue #21328, and no unrelated production behavior is shown.

Full details: Description check

Explanation

The pull request description includes all required sections: Problem, Change, Scope and approval, and Verification. It explains the issue, implementation, maintainer approval, focused tests, observed results, unverified environments, timing impact, and agent details.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified the refresh behavior as-is at 3a3eb59b77f8ef299882e07117b0a19fafd2a7c4 on linux. no source changes or pushes.

ran vp i and background vp run dev separately on github/main (15fe283272) and the exact pr head, stopping main before starting the pr. drove the web client with the repo's playwright and /usr/bin/google-chrome. created a local git project through the app, then used real codex gpt-6.1-sol turns through the local proxy to create and commit a recipe notebook. no fixtures or replay provider.

• main: all 22 tracked entries shared the newly created worktree index's mtime second; no refresh command ran.
• pr: all 22 entries were older than the index's second. git tracing showed one git update-index -q --refresh after checkout. a second app-created worktree gave the same result.
• real codex read turns completed in the worktrees. a follow-up edit appeared in the client diff as README.md +1 -0; the persisted checkpoint contained the exact added line.
• status, diff, and checkpoint capture left the worktree index's bytes and timestamp unchanged. the original checkout retained its staged STAGED.md and identical index bytes and timestamp.

blacksmith: both focused regression cases passed. the two vcs suites produced 206 passes and one failure in preserves renames, unusual paths, modes, and binary statistics (previousPath of undefined, line 1673). that failure also reproduced with the new refresh call disabled in the isolated worker. hosted ci has no failing checks.

command transcript

Not verified

the same-second condition was reproduced on main, but repeated content hashing or a latency slowdown was not demonstrated on this linux git 2.43.0/ext4 vm. trace2 refresh/sum_scan counters were zero. this verifies the refresh and integration, with no claim of a measured performance improvement.

native electron, ios/android, macos/windows, submodules, and a real filesystem refresh failure were not exercised. the failure fallback passed its existing focused test.