Session creation times out at 5 minutes: bundled git carries a multi-second per-execution penalty bound to specific file instances (Windows)

Start by tracing the app's bundled Git invocation during session creation, especially the "Preparing worktree" path and the readiness timeout. Use the reported git --version timings and the post-remediation session event log as verification points; done means affected Windows installations either avoid the multi-second penalty or report the responsible Git step clearly instead of only timing out.

Short summary

Session creation hangs at "Preparing worktree" and fails with "session did not become ready within 5 minutes", because every invocation of the app's bundled git costs 1-8 seconds instead of ~40 ms.

Affected version or release

App copilot-desktop-gh-2.98.0, CLI 0.0.395 (commit 4b4fe6e), bundled git 2.53.0.windows.4 at %LOCALAPPDATA%\github-copilot-git-2.53.0-4. Windows 11, 16 logical CPUs, 55.7 GiB RAM.

Installation context

Local install for a single user. Project is a worktree-backed repository project (NSTA1/Orleans.Lattice) with 12 active worktrees under C:\dev\copilot-worktrees\lattice. The failure is in the app's local git usage and is not specific to the repository.

What happened?

New sessions stopped becoming ready. They sat at "Preparing worktree" and eventually failed with:

session did not become ready within 5 minutes

The cause is not worktrees, repository size, or the readiness budget itself. It is that a per-execution penalty of 1-8 seconds is attached to specific executable file instances inside the app's bundled git install.

The penalty is bound to the file instance (its NTFS file identity), not to the bytes, the path, the filename, the directory, or the program. A byte-identical copy of the same file, in the same directory, under a different name, runs 34-190x faster.

Because the app invokes this git for every step of session creation (worktree add, status, rev-parse, for-each-ref, ...), the penalty is paid per invocation and accumulates until the 5-minute readiness budget is exhausted.

Budget arithmetic: at the measured pre-fix cost of the PATH shim (~5,900 ms median), roughly 51 git invocations exhaust the 300-second budget. Session creation comfortably exceeds that. After remediation the same budget admits ~3,125 invocations.

The decisive experiment

Same directory, same bytes, different file instance:

file	median launch
mingw64\bin\git.exe (original instance)	1,477 ms
byte-identical copy beside it, different name	44 ms
cmd\git.exe (original instance)	6,666 ms
byte-identical copy beside it, different name	35 ms

Affected files

Five file instances in the bundled tree carried the penalty. git-lfs.exe matters because the bundled etc\gitconfig sets filter.lfs.required = true, so git spawns it during every checkout; git-credential-manager.exe is spawned for network operations.

file	before	after refresh
cmd\git.exe (the PATH entry)	6,346-8,482 ms	85 ms
mingw64\bin\git.exe	1,391-1,502 ms	48 ms
mingw64\bin\git-credential-manager.exe	3,231 ms	425 ms
mingw64\libexec\git-core\git-lfs.exe	975 ms	403 ms
mingw64\bin\git-remote-https.exe	317 ms	52 ms

What was ruled out

Each of the following was individually disconfirmed by controlled measurement.

hypothesis	disconfirming evidence
Worktree count / contention	Penalty reproduces with git --version, outside any repository
Repository or .git size, ref count	Same; .git is only 184 MB
Disk space	675 GiB free of 1,905 GiB
Disk I/O	Disk queue 0, 60% idle during a slow burst
System-wide slow process launch	hostname.exe 74 ms, curl 113 ms, dotnet 536 ms in the same window
Git's own runtime	GIT_TRACE_PERFORMANCE=1 reports 0.000168 s; GIT_TRACE=2 spans 6 ms
Git version (2.53 vs 2.55)	System git 2.55 = 35-47 ms; bundled 2.53 relocated = 40 ms
The binary itself	Byte-identical copy is fast (decisive experiment above)
The directory	sed.exe (63 ms) and awk.exe (172 ms) in the same folder are fast
%LOCALAPPDATA% location	Full tree copied to %LOCALAPPDATA%\zzt1 = 82-91 ms
Folder name shape	Copy named github-copilot-git-9.99.9-9 in the same parent = 85 ms
Mark-of-the-Web	0 of 385 files carry a Zone.Identifier stream
Authenticode trust	Both gits validly signed by the same publisher (CN=Johannes Schindelin)
Microsoft Defender	20x system git = 920 ms vs 20x bundled = 118,114 ms, with MsMpEng CPU delta 0.00 s in both
MsSense / SenseIR / GlobalSecureAccess	CPU delta 0.00 s for all during a slow burst
AppLocker	No rule collections configured
Reparse point / alternate data stream on the folder	None present
core.fsmonitor	The app already sets core.fsmonitor= (empty) via GIT_CONFIG_KEY_2 on every invocation
fsmonitor daemons	All 14 killed individually by PID; shim only 6,286 -> 5,424 ms
Concurrent git process count	33 paired interleaved samples: 1,005 ms in-place vs 42 ms relocated; 913 ms even at lowest concurrency

Mechanism (not proven)

The evidence is consistent with a kernel minifilter or endpoint-security per-file verdict cache keyed to NTFS file identity, whose blocking check is not billed to any user-mode process: git's own execution spans 6 ms, wall time is seconds, and no security service accrues measurable CPU. Refreshing file identity appears to invalidate the cached entry.

This could not be confirmed without administrative tooling (Get-MpPreference returns "N/A: Must be an administrator"). The mechanism is an assumption; everything above it is measurement.

One residual is unexplained: cmd\git.exe (the 47 KB shim) cost ~6,666 ms while the real 4.3 MB binary it launches cost ~1,477 ms, which is more than a simple double launch predicts.

Steps to reproduce

The trigger condition is environmental, so this reproduces only on an affected machine. To detect and confirm it:

1. Measure the bundled git: time %LOCALAPPDATA%\github-copilot-git-<ver>\cmd\git.exe --version over several runs. On an affected machine the median is seconds.
2. Confirm it is the file instance, not the program: copy that file to a new name in the same directory and time the copy. It runs in tens of milliseconds.
3. Confirm it is not the directory: time usr\bin\sed.exe --version in the same tree. It is fast.
4. Create a new session in the app and observe it hang at "Preparing worktree" and fail at 5 minutes.

Remediation that resolves it (reversible, byte-identical), applied to each affected file:

$ts = Get-Date -Format "yyyyMMdd-HHmmss"
Copy-Item $p "$p.new" -Force
Rename-Item $p "$(Split-Path $p -Leaf).old-$ts"
Rename-Item "$p.new" (Split-Path $p -Leaf)

Windows permits renaming a mapped image, so this works on a running executable. SHA256 was verified identical before and after for all five files.

Expected behavior

Session creation should complete in seconds. Where it cannot, the app should attribute the failure to the step and cost responsible rather than reporting only "session did not become ready within 5 minutes".

Additional context

Measured effect of remediation

operation	before	after
git --version via PATH shim	6,346-8,482 ms	85 ms
mingw64\bin\git.exe --version	1,391-1,502 ms	48 ms
git rev-parse HEAD	7,892 ms	63 ms
git worktree list	10,778 ms	96 ms
git status --porcelain (warm)	2,755 ms	93 ms
git worktree add (end to end)	21,092 ms	7,223 ms
first git status in a new worktree	25,904 ms	6,683 ms
second git status in a new worktree	7,523 ms	203 ms
session created and agent replied	failed at 300 s	109 s (6 s turn latency)

End-to-end verification after remediation: a new session was created and given a trivial prompt. Its event log shows session.start at 11:28:07Z, kickoff delivered at 11:28:32Z, and assistant.message with the expected reply at 11:28:38Z.

Suggested improvements

1. Detect the condition. The app already knows how long its git invocations take. A git --version taking seconds is a reliable, cheap startup signal and is far more actionable to surface than a 5-minute timeout.
2. Prefer, or fall back to, a system git. A standard Git for Windows 2.55.0 at C:\Program Files\Git measured 35-47 ms throughout, on the same machine, in the same windows in which the bundled git took seconds.
3. Make the readiness failure diagnosable. The current message names a symptom with no attribution. Reporting which step exceeded the budget, and the per-invocation git cost, would have reduced this from a multi-hour diagnosis to a minutes-long one.
4. Consider refreshing file identity on install and update using the cheap, byte-preserving copy/rename above, so an inherited per-file verdict does not persist across app updates.

Notes for anyone reproducing this

Two test-method corrections, recorded because either would invalidate a reproduction attempt:

1. Copying only mingw64\bin\* is not a valid relocation test. Git cannot find its install root (etc/gitconfig, libexec) and does less work, producing a falsely fast result. The whole 385-file tree must be copied.
2. git-askpass.exe treats its first argument as a prompt string. Sweeping --version across every .exe in a Git for Windows tree opens a modal GUI dialog and blocks. Exclude askpass, wish, gitk, and git-gui.

Environment detail

• Bundled git is a stripped build: no bash.exe, no curl.exe; libexec holds 17 files where a full install has 100+.
• Two bundled git trees are present side by side: github-copilot-git-2.53.0-3 and github-copilot-git-2.53.0-4.
• The app injects on every git call: GIT_CONFIG_COUNT=3 setting safe.bareRepository=explicit, credential.interactive=never, and core.fsmonitor= (empty), plus GIT_OPTIONAL_LOCKS=0, GIT_TERMINAL_PROMPT=0, and a copilot credential helper.
• Main checkout: 250,922 files / 41.6 GiB on disk, 8,920 tracked, .git 184 MB, 9,401 packed refs plus 572 loose refs, 12 worktrees.