[FEATURE] Expose ripgrep --follow/-L flag in Grep tool for symlink-based monorepos

Resolved 💬 4 comments Opened Feb 12, 2026 by jasonevines Closed Mar 13, 2026

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

  1. Working in a pnpm monorepo (pnpm is the second most popular Node.js package manager)
  2. Need to verify whether a library exports a specific API — e.g., does motion-dom@12.34.0 export getPrevious()?
  3. Use Grep tool to search node_modules for the method name
  4. Grep returns 0 results because pnpm's node_modules/.pnpm/ uses symlinks to its content-addressable store
  5. Agent concludes the API doesn't exist — incorrect
  6. 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_modules structure is symlink-based by design
  • Platform: macOS, likely affects all platforms

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗