Title: getRipgrepPath() never falls back to system PATH — ripgrep unavailable despite being installed

[JoshuaAdes]

Environment:
gemini --version

→ 0.41.1 (git e1a5449)

rg --version

→ ripgrep 15.1.0 ✓

OS: Windows 11, win32

• Install method: npm install -g @google/gemini-cli
• ripgrep: installed via winget install BurntSushi.ripgrep.MSVC (in system PATH, rg --version works)

Bug:
getRipgrepPath() in bundle/chunk-NET4RIEQ.js only checks two paths relative to its own bundle dir:
vendor/ripgrep/rg-win32-x64.exe
../../vendor/ripgrep/rg-win32-x64.exe
Neither path contains the bundled binary after a standard npm install -g. System PATH is never consulted. Result: "Ripgrep is not available.
Falling back to GrepTool." even when rg is installed and functional.

Repro:
npm install -g @google/gemini-cli
winget install BurntSushi.ripgrep.MSVC
gemini -p "test"

→ "Ripgrep is not available. Falling back to GrepTool."

rg --version

→ ripgrep 15.1.0 ✓

Expected: Fall back to where rg (Windows) / which rg (Unix) when bundled binary not found.

Suggested fix:
async function getRipgrepPath() {
// ... existing candidate paths ...
for (const candidate of candidatePaths) {
if (await fileExists(candidate)) return candidate;
}
// Fallback: check system PATH
try {
const { execFileSync } = require('child_process');
const found = process.platform === 'win32'
? execFileSync('where', ['rg'], { encoding: 'utf8' }).split('\n')[0].trim()
: execFileSync('which', ['rg'], { encoding: 'utf8' }).trim();
if (found && await fileExists(found)) return found;
} catch (_) {}
return null;
}

Workaround: Copy system rg to bundle/vendor/ripgrep/rg-win32-x64.exe inside the Gemini CLI install dir.

[gemini-cli]

This is a bug where the core tool resolution for ripgrep fails to fallback to the system PATH. It is assigned P2 as an inconvenient workaround exists (copying the binary). The CLI version is missing from the issue description; please provide the CLI version (e.g., the output of the /about command like 0.1.5).

Effort Analysis:
The getRipgrepPath function in packages/core/src/tools/ripGrep.ts currently maps the binary resolution to hardcoded bundle paths (vendor/ripgrep) and explicitly returns null if not found. The issue requires a highly localized fix within this single file to conditionally utilize child_process.execFileSync (checking where or which) as a fallback to locate the system rg executable if local bundle resolution fails. As this is a localized, single-file logic adjustment that does not span across packages or touch complex architectural mechanisms, it cleanly maps to the 'effort/small' guidelines.

[JoshuaAdes]

CLI version: 0.41.1 (git commit e1a5449), OS: win32. Apologies - the version in the original report was the ripgrep binary version, not the CLI version.

[R0SEWT]

/assign

[gemini-cli]

👋 @R0SEWT, thanks for your interest in this issue! We're reserving self-assignment for issues that have been marked with the help wanted label. Feel free to check out our list of issues that need attention.