The ripgrep tool should prefer the system ripgrep, when possible.

[albertosantini]

What happened?

ripgrep package is downloaded, even if it is already downloaded (and in the path).

What did you expect to happen?

If ripgrep is already downloaded, we may avoid downloading again. Furthermore, if ripgrep is in the PATH, we may avoid downloading at all.

Client information

Client Information

Run gemini to enter the interactive CLI, then run the /about command.

> /about

╭──────────────────────────────────────────────────╮
│                                                  │
│ About Gemini CLI                                 │
│                                                  │
│ CLI Version      0.9.0                           │
│ Git Commit       a93d92a3                        │
│ Model            gemini-2.5-pro                  │
│ Sandbox          no sandbox                      │
│ OS               win32                           │
│ Auth Method      OAuth                           │
│                                                  │
╰──────────────────────────────────────────────────╯

Login information

No response

Anything else we need to know?

No response

[albertosantini]

See https://github.com/google-gemini/gemini-cli/blob/dd42893df77be502826e1c575b9d51a5bdca3b4f/packages/core/src/tools/ripGrep.ts#L27-L37

if (await fileExists(getRgPath())) { In Windows this always returns false because getRgPath is looking for rg and not rg.exe. return path.join(Storage.getGlobalBinDir(), 'rg');

At the moment vscode-ripgrep is always downloaded, slowing down startup time, then it is unzipped and the executable moved to .gemini/tmp/bin.

I suggest one fix and one change:

• improving getRgPath for Windows environment
• changing the logic, if ripgrep executable is in the PATH, no download.

What do you think about it?

Edit: Anyway it is downloaded an old version of ripgrep 13.x. Need to update to 14.x

[cornmander]

Thanks, those are both great ideas. I will file feature requests and get these prioritized.

[cornmander]

Re-marking this as an enhancement since the bug part should be fixed.

[joshualitt]

Disowning this for now, until https://github.com/google-gemini/gemini-cli/issues/12099 is fixed. I have a PR to prefer ripgrep from the system path(https://github.com/google-gemini/gemini-cli/pull/11847), but it makes sense to pull in checksum verification logic into the same CL to ensure the integrity of the ripgrep binary before use, and this will be painful without addressing #12099 first.

[guidedways]

@joshualitt @cornmander any update on prioritizing this?

[albertosantini]

• The fix is in production
• For the change request see https://github.com/google-gemini/gemini-cli/pull/11847 as listed above

[guidedways]

I probably misunderstood - Gemini is still using Grep instead of rg in the current release.

[joshualitt]

@guidedways , this is on our radar. It's actually a bit more complicated then we'd have liked due to the need to do checksum verification, and to do that we need to internalize get-ripgrep. Hopefully someone will have cycles soon.