Built-in tools (Glob, Grep, Explore) ignore user instructions to prefer git-aware commands

[kojiromike]

Problem

Claude Code's built-in tools (Glob, Grep, Task/Explore agents) use find, rg, and similar commands under the hood. The system prompt actively instructs Claude to use these tools instead of shell equivalents. This creates a conflict when users configure CLAUDE.md or memory files to prefer git-aware alternatives like git grep and git ls-files.

Even with explicit instructions like:

- **Prefer `git grep`** over `grep` or `rg` for searching file contents
- **Prefer `git ls-files`** over `find` for listing/finding files
- These commands are faster and automatically respect `.gitignore`

Claude still routes searches through Glob/Grep/Explore, which traverse untracked files, build artifacts, vendored dependencies, etc. The user's instructions are effectively overridden by the system prompt telling Claude to use these built-in tools.

Impact

• Wasted tokens: Results include noise from ignored/untracked files that git grep and git ls-files would exclude automatically.
• Slower searches: Scanning the full filesystem is slower than git's index-based lookups, especially in large repos.
• User instructions ignored: This undermines trust in CLAUDE.md as a way to customize behavior. Users set these preferences for good reasons and expect them to be respected.

Expected behavior

When a user's CLAUDE.md instructs Claude to prefer git grep / git ls-files, Claude should respect that and use Bash with those commands for file search and content search, rather than routing through Glob/Grep/Explore agents whose system prompts override the user's preference.

Also, the built-in tools could be made git-aware: when operating inside a git repo, Glob could use git ls-files patterns and Grep could use git grep under the hood.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] <system-reminder> is instructing claude code to not follow claude.md instructions. #18560
2. CLAUDE.md instructions wrapped in "may or may not be relevant" disclaimer, undermining user directives #22309
3. CLAUDE.md 'Rules' are treated as suggestions, not enforced #19252

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[kojiromike]

Not a duplicate — different mechanism

The three suggested duplicates are all about CLAUDE.md instructions being ignored due to the <system-reminder> wrapper language ("may or may not be relevant"). That's a real problem, but this issue identifies a different mechanism.

#18560 and #22309 are about the contradictory wrapper framing causing Claude to deprioritize CLAUDE.md content entirely. Fixing the wrapper language wouldn't fix this issue — Claude can perfectly understand the user's instructions to prefer git grep/git ls-files and still route searches through Glob/Grep, because the built-in tool descriptions in the system prompt explicitly tell it to use those tools instead of Bash equivalents.

#19252 is about the general "Claude ignores rules when confident" problem. This issue is more specific and structural: it's not that Claude is being lazy or overconfident. The system prompt contains explicit directives like "Use Glob instead of find" and "Use Grep instead of grep/rg" that directly conflict with user instructions to prefer git-aware commands. Even a model that perfectly followed CLAUDE.md would face a conflict between two competing sets of instructions — and the system prompt wins.

The distinct problem here: built-in tool descriptions structurally override user tool preferences. The fix requires either (a) allowing user instructions to take precedence over tool-routing directives, or (b) making the built-in tools git-aware so there's no conflict in the first place.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.