[BUG] Grep honors .gitignore silently — an agent auditing its own repo gets 'No files found' for code that exists, and cannot tell blindness from absence

Summary

The Grep tool honors .gitignore. In a repository with a broad ignore rule, this means an agent asked to audit code cannot see the code, and the failure is silent: Grep returns "No files found," which is indistinguishable from "the file does not exist."

This produced three consecutive multi-agent code reviews that all reported "no such code exists" about a file sitting on disk containing the exact search string.

Reproduction

1. In a repo, add a broad ignore to .gitignore:

``
scripts/*
``

1. Ensure a file exists there containing a distinctive string:

``
scripts/example_writer.py # 74 KB, contains "example_writer"
``

1. Ask Claude Code what creates those files, or run the tool directly:

``
Grep(pattern="example_writer", path="scripts/")
→ No files found
``

1. Read the path directly and the file is there, containing the string.

One review that greps reports "nothing found." The next review that happens to Read a path directly finds the code. Same repo, same minute, opposite conclusions.

Impact

This is not a cosmetic search limitation. It silently inverts the result of an audit.

I spent a substantial amount of usage across three independent review passes (different models, run separately) asking "what code is creating these files?" All three returned empty. The answer was that the responsible scripts lived under a path .gitignore excludes, so every agent-run search skipped them. The reviews were structurally incapable of finding what they were asked to find, and nothing indicated that.

Related: a second exclusion lived in .git/info/exclude — local, uncommitted, unshareable — so a reviewer reading .gitignore to understand what was hidden would not find that rule either. Between .gitignore, .git/info/exclude, local git config, and per-worktree config (extensions.worktreeconfig), the exclusion surface is split across four locations and no single file shows the whole picture. An agent has no reason to audit any of them before trusting its own search.

Why this class of failure matters

A search returning zero results because it was blinded looks exactly like a search returning zero results because nothing is there. There is no signal distinguishing them, so:

• An agent concludes the code doesn't exist and reports that confidently.
• A downstream decision gets made on that conclusion.
• Nobody can tell the difference without independently reading paths.

The tool behaves as documented; the problem is that the failure is unobservable to its caller.

Suggested fixes (any one would help)

1. Report suppression. When Grep skips files due to ignore rules within the searched path, say so: No matches. Note: N files in this path were skipped due to .gitignore / .git/info/exclude. This alone converts a silent false negative into an actionable one.
2. Expose a no-ignore option. Surface ripgrep's --no-ignore / -uu as a parameter so an agent auditing its own repository can search what is actually on disk.
3. Mention the behavior in the tool description, so agents know to check the ignore surface before concluding absence.

Option 1 is the minimum and would have prevented all three wasted reviews.

Environment

• Claude Code 2.1.222 (present in earlier 2.1.x as well)
• Windows 11
• .gitignore in the affected repo is ~1,970 lines with several blanket directory ignores