[BUG] Native Windows: startup waits ~4.5 s on three embedded-ripgrep calls that each re-launch claude.exe; agent-view sessions take ~10 s to open (USE_BUILTIN_RIPGREP=0 halves it)

Preflight Checklist

• [x] Searched existing issues: #10979 and #66395 cover ripgrep at startup, neither the per-call re-launch cost on the native Windows install
• [x] Reproduced on the latest version (2.1.263)

What's Wrong?

On the native Windows install, the embedded ripgrep is invoked by launching claude.exe again with rg as the program name. A bare launch of the binary takes about 1.6 s on this machine (claude --version alone: 1.6 s, twice). Startup makes three of these calls in series before the first API request and waits on them:

| time after launch | child process (sampled with Win32_Process on the parent pid every 150 ms) |
|---|---|
| 1.0 s | claude.exe as rg --version |
| 2.8 s | claude.exe as rg --no-config --files --hidden --no-ignore --max-depth 4 --glob .orphaned_at C:\Users\<user>\.claude\plugins\cache |
| 4.3 s | claude.exe as rg --no-config --files --hidden "<project dir>" |

In a --debug-file log this is a silent 4.3–4.7 s gap right after Initialized versioned plugins system with 0 plugins, while [STARTUP] setup() itself reports about 200 ms.

Timings for the same headless call (-p "Reply with the single word ok" --model claude-haiku-4-5-20251001 --setting-sources "" --strict-mcp-config --no-session-persistence --tools "" --debug-file):

| | embedded rg | USE_BUILTIN_RIPGREP=0 (system rg 15.2.0 on PATH) |
|---|---|---|
| wall time of the call | 9.4 s | 4.7 s |
| startup to first [API REQUEST] | 5.7 s | 1.3 s |
| Ripgrep first use test | mode=embedded | mode=system |

The user-visible effect is that sessions opened from claude agents take about 10 s to become ready. Jobs created from the agent view on 2.1.263 took 8.8–9.1 s from state.json createdAt to the first transcript record, against 1.9–3.9 s for this machine's jobs from June–August 2026 (versions 2.1.178–2.1.222). With USE_BUILTIN_RIPGREP=0 in the settings env block, a new background session took 4.8 s.

2.1.260, 2.1.261 and 2.1.263 all behave the same. The network is not a factor: curl to api.anthropic.com completes in 40 ms and the API request's first byte arrives in about 700 ms.

What Should Happen?

Startup should not pay a full runtime boot per ripgrep call. Any of these would do: keep one rg child alive for the session, move the plugin-cache sweep and the rg --version probe off the startup path, or ship a small rg.exe next to the binary on Windows instead of re-executing claude.exe.

Error Messages/Logs

12:45:36.415Z [DEBUG] Initialized versioned plugins system with 0 plugins
12:45:40.891Z [DEBUG] [servedCatalog] off (flag)
...
12:45:41.186Z [DEBUG] Ripgrep first use test: PASSED (mode=embedded, path=C:\Users\<user>\.local\bin\claude.exe)

Steps to Reproduce

1. Native Windows install, USE_BUILTIN_RIPGREP unset.
2. Run the headless call above with --debug-file x.log.
3. Note the gap after Initialized versioned plugins system and the time to [API REQUEST].
4. Repeat with USE_BUILTIN_RIPGREP=0 and rg on PATH.

Claude Model

Not model-related (Haiku 4.5 used for the timing).

Is this a regression?

Yes, by the job records above: 2–4 s to first transcript record on versions up to 2.1.222, 9 s on 2.1.260 and later. No binaries in between are cached here to narrow it down.

Last Working Version

2.1.222 (from job records, not a controlled comparison)

Claude Code Version

2.1.263 (same on 2.1.260 and 2.1.261)

Platform

Native Windows install (~/.local/bin/claude.exe, 218 MB)

Operating System

Windows 11 Enterprise 10.0.26100

Terminal/Shell

Git Bash and PowerShell 7; also the agent view (claude agents)