[FEATURE] Expose ripgrep --follow/-L flag in Grep tool for symlink-based monorepos
Problem Statement
The Grep tool wraps ripgrep but does not expose its --follow/-L flag. ripgrep skips symbolic links by default, which causes silent false negatives when searching directories that use symlinks.
The most common case is pnpm monorepos, where node_modules/.pnpm/ is entirely symlink-based. Searching package contents via the Grep tool returns zero results for content that provably exists:
Grep pattern: "getPrevious" path: "node_modules"
→ 0 results (false negative — content exists behind symlinks)
The same search via Bash with ripgrep's -L flag succeeds:
rg -L "getPrevious" node_modules/
→ finds matches in motion-dom package
Proposed Solution
Add an optional follow_symlinks boolean parameter to the Grep tool that maps to ripgrep's --follow/-L flag:
{
"follow_symlinks": {
"description": "Follow symbolic links (maps to ripgrep --follow/-L). Default: false.",
"type": "boolean"
}
}
Alternatively, defaulting to --follow would match the behavior of grep -r (which follows symlinks by default) and resolve this class of false negatives without requiring callers to opt in.
Alternative Solutions
The current workaround is to use the Bash tool with rg -L or grep -r (which follows symlinks by default). This works but requires Bash access, which not all agent configurations permit — and it bypasses the Grep tool's structured interface.
Use Case Example
- Working in a pnpm monorepo (pnpm is the second most popular Node.js package manager)
- Need to verify whether a library exports a specific API — e.g., does
motion-dom@12.34.0exportgetPrevious()? - Use Grep tool to search
node_modulesfor the method name - Grep returns 0 results because pnpm's
node_modules/.pnpm/uses symlinks to its content-addressable store - Agent concludes the API doesn't exist — incorrect
- With
follow_symlinks: true, the search would find the matches and avoid the false conclusion
This caused a real false negative: an AI agent concluded scrollY.getPrevious() was absent from Motion 12.34.0 during an implementation task. The API is @public and present in both runtime and type definitions.
Additional Context
- Related: #16507 (Glob tool does not follow symbolic links) — same root cause, different tool
- Affects any symlink-heavy project structure, but pnpm monorepos are the most widespread case
- pnpm's entire
node_modulesstructure is symlink-based by design - Platform: macOS, likely affects all platforms
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗