perf(server): run Git for Windows' real git.exe, not its launcher

[SunkenInTime]

On Windows, the server now runs Git for Windows' real git.exe instead of the cmd\git.exe launcher in front of it. Measured on a dev server seeded from a real install (60 threads), 8 minutes each, main and this branch alternated twice:

	main	this PR
Processes started	3,776	2,712 (−28%)
CPU, server and children	118.8 s	100.1 s (−16%)
Launcher (cmd\git.exe) runs seen	441, 395	0
Kernel tokens leaked per 100 git launches	105 to 109	1 to 5 (idle: 3 to 4)

Problem

Git for Windows' installer puts only <Git>\cmd\git.exe on PATH. That file is a 46 KB launcher. It sets MSYSTEM, HOME and PATH, then starts the real git.exe as a second process. So every git command T3 runs costs an extra process.

The launcher also leaks. Each run leaves about one kernel token reference behind that Windows never frees until reboot. The seeded server above runs about 9,800 git commands an hour, so the count reaches millions within a week or two. On this PC at 3 million leaked tokens, process creation slowed from 2.9 ms to 9.4 ms at the median, and 2 to 11% of launches took over 100 ms. Node's spawn() creates the process on the main thread, so every slow launch is also a stall in the server's event loop. A reboot clears it.

#11221 reported the launcher. #12600 fixed the PATH-scan half of that issue and left the launcher alone.

Change

preferGitForWindowsBinary in packages/shared/src/shell.ts runs inside resolveSpawnCommand. When the resolved path is Git for Windows' launcher (<Git>\cmd\git.exe, or <Git>\bin\git.exe in the portable build), it returns <Git>\<build>\bin\git.exe, checking ucrt64, clangarm64, mingw64, then mingw32. Anything else, including Scoop and Chocolatey shims, comes back unchanged.

• It keeps the launcher when MSYSTEM is set. The real binary adds its own folders to PATH only when MSYSTEM is unset. With MSYSTEM set and Git's folders off PATH, a #!/bin/sh hook can't start. develdeco/jig hit exactly this in perf(gitx): run git's own binary, not a launcher in front of it develdeco/jig#19. A desktop-launched server has no MSYSTEM; one started from Git Bash keeps today's behavior.
• The swap is cached with the PATH scan, keyed on whether MSYSTEM is set. Its file checks cost about 0.28 ms of synchronous stat calls on this machine, so uncached they would make every cached lookup about 8x slower (288 µs vs 35 µs). The cost: a Git upgrade that moves the real binary can fail git commands for up to the cache's 30 seconds.
• Git for Windows supports running the real binary directly (git-wrapper, aimed at callers that run git "tens of thousands of times"). Its location isn't stable, though: 2.56 moved x64 builds from mingw64 to ucrt64. If none of the folders exist, T3 runs the launcher as before.

GitVcsDriverCore.executeRaw, which runs most of the server's git commands, spawned the bare name git through Node's own PATH lookup and never reached resolveSpawnCommand. It now resolves through it too. If git resolves to a .cmd or .bat wrapper, the driver keeps Node's lookup, because running it through cmd.exe would cut multi-line commit messages at the first newline.

What git's own child processes see is unchanged. On Git 2.55 and portable 2.56, I compared the environment and the resolved sh, ssh, gpg, git-lfs, git-credential-manager, perl and curl under each launch path. They were the same binaries with the same MSYSTEM, HOME and PLINK_PROTOCOL. Two small differences remain:

• The real binary puts %USERPROFILE%\bin ahead of Git's folders instead of after them, which is the order Git Bash uses.
• It doesn't read MSYS= from etc\git-bash.config. None of the installer, portable or MinGit layouts ship that file.

macOS and Linux are untouched, because resolveSpawnCommand returns before any of this off Windows.

Scope and approval

Bug: #11221, the launcher half. This is a performance fix with no change in what git does.

Verification

All on Windows 11, Ryzen 5800X, Git 2.55.0.windows.1, plus portable and MinGit 2.56.0.windows.2.

Per command, through Effect's spawner the way T3 runs git. 200 commands per round, 3 rounds, alternating launcher and real binary:

Command	Launcher p50 / p90	Real p50 / p90	Processes
git config --get (exit 0)	42.6 / 58.4 ms	31.4 / 46.4 ms	3 → 2
git config --get (exit 1)	247 / 321 ms	241 / 314 ms	7 → 6
git status --porcelain=v2	175 / 194 ms	177 / 194 ms	3 → 2

Failing commands barely move because Effect's two taskkills dominate them; #16850 covers that. git status is dominated by git's own work.

Leak. Live kernel token count around 15 alternating batches of 100 launches each (medians):

	Launcher	Real git.exe	Idle
Git 2.55	109	1	3
Git 2.56	105	5	4

Live server. The table at the top comes from the seeded dev server, with GitHub's PR list stubbed to "no PR" so the runs didn't spend API quota. I sampled the image paths of the server's child processes from its job object:

• main started cmd\git.exe and then the real binary for each command;
• this branch started only mingw64\bin\git.exe;
• both ran the same 1,514 git commands per run.

A last 2-minute run on the final code ran 376 git commands through the driver, all on the real binary, with no spawn errors.

Tests.

• packages/shared/src/shell.test.ts: 39 pass, including the new preferGitForWindowsBinary cases.
• apps/server/src/vcs/GitVcsDriverCore.test.ts, run with a desktop-like environment so the real binary is used: 128 pass, including the #!/bin/sh pre-commit and pre-push hook tests. The same 8 fail on unmodified main on this machine: the five ssh error-classification tests, the missing-repository and non-repository cases, and the pathspec-magic filename.

Not checked.

• ARM64 on hardware. I only confirmed the clangarm64 layout from the MinGit ARM64 zip.
• Git for Windows older than 2.26, where the real binary doesn't set up PATH itself. T3 already needs 2.35 or later for ls-files --sparse.
• Git that agents run from their own shells. It still uses whatever their PATH finds.

Model: Claude Opus 5.5. Harness: Claude Code, running inside T3 Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes how all server-side Git operations run on affected Windows installations, replacing the launcher process with version- and environment-sensitive executable selection. Although the implementation is focused and tested, the existing production execution path and process behavior change materially enough for human review.

^{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.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: 5163300f-9675-478e-8fbe-1a788b3ae838

---

---

📥 Commits

Reviewing files that changed from the base of the PR and between ea61922 and 6484eee.

---

---

📒 Files selected for processing (2)

• packages/shared/src/shell.test.ts
• packages/shared/src/shell.ts

---

---

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

---

---

---

📝 Walkthrough

📝 Walkthrough

Walkthrough

Git executable resolution can select an eligible Git for Windows binary. The VCS driver uses the resolved command and assembled environment when spawning Git.

Changes

Git spawn resolution

Layer / File(s)	Summary
Select Git for Windows binary packages/shared/src/shell.ts, packages/shared/src/shell.test.ts	resolveSpawnCommand selects the first existing architecture-specific git.exe for eligible Git for Windows launchers. It includes MSYSTEM in the cache key. Tests cover selection, unchanged launcher cases, and cache separation.
Spawn Git with resolved command apps/server/src/vcs/GitVcsDriverCore.ts	Git spawning resolves the executable using the assembled environment and passes that environment to the child process. It uses "git" when resolution requires a shell wrapper.

Priority: ➖ Normal

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

Change: Bug fix

Sequence Diagram(s)

sequenceDiagram
  participant GitVcsDriverCore
  participant resolveSpawnCommand
  participant GitProcess
  GitVcsDriverCore->>resolveSpawnCommand: Resolve git using the assembled environment
  resolveSpawnCommand-->>GitVcsDriverCore: Return resolved executable
  GitVcsDriverCore->>GitProcess: Spawn selected command with environment

Loading

Suggested reviewers: juliusmarminge

---

---

Merge Risk: ⚪ Minimal · up to 6484e

No PR-introduced issue requiring a fix before merge was established.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 6484e

The change preserves argument-array spawning and does not introduce a new command shell. Remaining uncertainty concerns whether bypassing the Windows launcher preserves hook and credential-helper resolution in all supported environments; cached binary paths can also briefly become stale during Git upgrades.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The execution surface is server Git operations and existing resolver consumers whenever their command selects an eligible launcher. The changed code introduces no explicit elevation mechanism; executable and downstream-helper trust remain relevant to the launching process's authority.

Security Findings and Attack Paths

• observed — The suspected shell-wrapper mismatch does not introduce a new attack path in this VCS caller: both base and head spawn literal git without enabling shell mode when the head resolver selects a shell-required wrapper.

Trust Boundaries and Controls

• inferred — Binary selection remains syntactically anchored beneath the selected launcher's installation root, rather than choosing an unrelated executable location. This does not prove equivalent downstream helper trust: PATH and HOME setup after launcher bypass is delegated to Git for Windows and is not established by the inspected repository implementation.

Hardening Proposals

• proposed — Validate launcher versus direct-binary equivalence for hook, SSH, GPG, and credential-helper selection under controlled PATH, HOME, and MSYSTEM variations. This would resolve the remaining helper-trust uncertainty rather than address a demonstrated vulnerability.

---

Pre-merge checks | 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description check		The description includes the problem, change, scope justification, detailed verification results, limitations, and agent metadata.
Linked Issues check		The description identifies bug #11221 and explains that this PR addresses its launcher-related performance problem.
Out of Scope Changes check		The changes match the stated objective. They update Windows Git command resolution, add focused tests, and leave non-Windows behavior unchanged.
Title check		The title clearly and concisely describes the main change: using Git for Windows' real executable instead of its launcher.

---

✨ 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.}

Dismissing prior approval to re-evaluate 6484eee