Ripgrep PATH fallback removed, breaking SearchText tool for npm/nvm installations

[wesamahakem]

Description

A recent architectural shift to prioritize "SEA" (Single Executable Application) bundling has introduced a performance regression for users on non-SEA distributions (e.g., standard npm install -g, or installations via Node version managers).

Specifically, PR #25342 (pushed April 13, 2026) refactored packages/core/src/tools/ripGrep.ts to use a strict internal discovery logic. This refactor removed the fallback that previously checked the system PATH for rg or rg.exe.

While the CLI correctly falls back to the TypeScript-based GrepTool implementation, this results in a significant performance degradation for searches in large codebases. Users who have ripgrep installed system-wide (via WinGet, Homebrew, etc.) are currently unable to leverage it because the CLI strictly searches only for architecture-specific filenames (like rg-win32-x64.exe) within its own relative vendor directories.

Reproduction

1. Install ripgrep globally on your system and ensure it is in your PATH.
2. Install Gemini CLI via standard npm or a node version manager.
3. Observe that the CLI fails to discover the system rg and falls back to GrepTool, even if use_ripgrep: true is set in configuration.

Proposed Solution

We should re-introduce a system PATH discovery step as a final fallback (Tier 3) in getRipgrepPath().

By prioritizing the bundled binaries but allowing the system PATH as a last resort, we maintain the offline/security guarantees for the SEA builds while ensuring that other distribution channels remain performant and can leverage the user's existing tools.

If a maintainer can approve this direction, I would be happy to submit a PR implementing this low-priority fallback.

[gemini-cli]

There is a problem with the Gemini CLI issue triaging. Please check the action logs for details.

[gemini-cli]

A significant performance regression where the CLI no longer falls back to the system PATH for ripgrep.

[roccomao]

I encountered the exact same issue : Ripgrep tool fails to fallback to system PATH when bundled binary is missing. I searched and found this thread just before creating a new issue. Other related issue : #26541 .

I try to copy the rg.exe to %APPDATA%/npm/node_modules/@google/gemini-cli/bundle/vendor/ripgrep/rg-win32-x64.exe manually, The warning Ripgrep is not available. Falling back to GrepTool. disappeared. I asked the Gemini-CLI, and this is his suggestion for revision :

--- a/packages/core/src/tools/ripGrep.ts
+++ b/packages/core/src/tools/ripGrep.ts
@@ -30,7 +30,7 @@
   COMMON_DIRECTORY_EXCLUDES,
 } from '../utils/ignorePatterns.js';
 import { FileDiscoveryService } from '../services/fileDiscoveryService.js';
-import { execStreaming } from '../utils/shell-utils.js';
+import { execStreaming, resolveExecutable } from '../utils/shell-utils.js';
 import {
   DEFAULT_TOTAL_MAX_MATCHES,
   DEFAULT_SEARCH_TIMEOUT_MS,
@@ -58,13 +58,19 @@
   for (const candidate of candidatePaths) {
     if (await fileExists(candidate)) {
       return candidate;
     }
   }

+  // 3. Fallback to system PATH
+  const systemRg = await resolveExecutable('rg');
+  if (systemRg) {
+    return systemRg;
+  }
+
   return null;
 }

 /**
- * Checks if `rg` exists in the bundled vendor directory.
+ * Checks if `rg` is available (either bundled or in the system PATH).
  */
 export async function canUseRipgrep(): Promise<boolean> {