fix(core): fall back when ripgrep execution fails

[he-yufeng]

Summary

• Fall back to the legacy GrepTool when the registered ripgrep tool hits execution-environment failures, including missing rg and exit 64.
• Keep the fallback conservative so ripgrep-only options such as fixed strings, explicit context, and no_ignore still fail instead of changing semantics silently.
• Let the legacy grep path search an explicit file path, so file-scoped SearchText calls can still fall back through git grep, system grep, or the JS scanner.

Fixes #27503.

Test plan

• npm run test --workspace @google/gemini-cli-core -- src/tools/grep.test.ts src/tools/ripGrep.test.ts
• npm run typecheck --workspace @google/gemini-cli-core
• npx eslint packages/core/src/tools/grep.ts packages/core/src/tools/grep.test.ts packages/core/src/tools/ripGrep.ts packages/core/src/tools/ripGrep.test.ts --max-warnings 0

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request improves the robustness of the search functionality by introducing a graceful fallback mechanism for the ripgrep tool. When ripgrep fails due to environmental issues, the system now automatically switches to the legacy GrepTool to ensure search operations can still complete. The changes also include necessary updates to support file-specific searches within the legacy grep path, ensuring that users receive consistent results even when the primary search tool is unavailable.

Highlights

• Ripgrep Fallback Mechanism: Implemented a fallback to the legacy GrepTool when ripgrep encounters execution-environment failures, such as missing binaries or specific exit codes (e.g., 64, 126, 127).
• Conservative Fallback Logic: Ensured the fallback is conservative by restricting it to standard searches, preventing silent semantic changes for ripgrep-specific features like fixed strings or explicit context.
• File-Scoped Search Support: Updated the legacy grep path to support searching explicit file paths, enabling consistent fallback behavior for file-scoped search requests.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

🛑 Action Required: Evaluation Approval

Steering changes have been detected in this PR. To prevent regressions, a maintainer must approve the evaluation run before this PR can be merged.

Maintainers:

1. Go to the Workflow Run Summary.
2. Click the yellow 'Review deployments' button.
3. Select the 'eval-gate' environment and click 'Approve'.

Once approved, the evaluation results will be posted here automatically.

[gemini-code-assist]

Code Review

This pull request enhances the GrepTool to support searching explicit file paths in addition to directories, and introduces a fallback mechanism in RipGrepTool to use GrepTool when ripgrep is unavailable or fails. Feedback on the changes suggests optimizing GrepTool by reusing the fs.Stats object from the validation step to avoid a redundant filesystem stat call when determining search targets.

[gemini-code-assist]

There is a redundant fsPromises.stat call here. The file stats for searchDirAbs were already fetched and validated in the block above (around line 166). Calling stat again on the same path introduces unnecessary filesystem I/O, which can degrade performance in large workspaces or slow filesystems.

To avoid this, you can declare let stats: fs.Stats | null = null; at the top of the execute method (around line 147), assign the result of fsPromises.stat(searchDirAbs) to it in the validation block (around line 166) instead of using a local const stats, and then reuse it here.

        searchTargets = stats && stats.isFile()
          ? [{ directory: path.dirname(searchDirAbs), filePath: searchDirAbs }]
          : [{ directory: searchDirAbs }];

[he-yufeng]

Done in 26c214d. The validation stat result is now reused when constructing file-scoped grep targets, so the fallback path no longer stats the same path twice.