Fixing Roo Code Ignoring .rooignore Rules and Reading Files It Shouldn't
A .rooignore file is added specifically to keep the agent away from build output, vendor directories, or sensitive files — and it still shows up in a search result or gets read directly. The rule isn't being silently overridden; it's usually a pattern that doesn't match what the author assumed, or a file placed somewhere Roo Code was never going to look for it.
The Problem
A .rooignore file is added to a project to keep Roo Code away from build artifacts, generated files, large vendor directories, or files containing sensitive configuration. Despite that, a search or file-listing operation still surfaces one of the supposedly excluded paths, or the agent reads a file directly that the ignore file was meant to exclude. Sometimes it works for one tool and not another; sometimes a rule that looks obviously correct simply doesn't seem to apply.
Why It Happens
A subtle pattern-syntax mismatch fails silently
.rooignore uses the same pattern syntax as .gitignore, and small differences in that syntax change what actually matches without producing any error. A pattern missing a leading / to anchor it to the workspace root will instead match that name anywhere in the tree; a pattern intended for a directory but missing its trailing / may not match the way expected; a glob that's slightly more or less specific than intended silently excludes the wrong set of files. None of this throws a warning — the pattern is simply evaluated as written, and a small mismatch between what was written and what was intended goes unnoticed.
The file isn't at the location Roo Code actually looks for it
.rooignore, like .gitignore, is expected at the workspace root. A copy placed in a subdirectory — sometimes intentionally, assuming it would scope rules to that subfolder — simply isn't read the way a root-level file is, and the rules inside it have no effect at all, silently rather than with any error.
Ignore rules reduce discovery going forward, not an absolute block on every path to a file
Different tools within Roo Code interact with .rooignore differently: it primarily governs what appears in search results and directory listings. If the agent (or the user, in an instruction) references an excluded path directly and explicitly, that direct reference can still reach the file, since the ignore rule's job is largely to keep a path from being surfaced during discovery, not to enforce an absolute, unconditional block on every possible way of reaching it.
A rule added after content was already read doesn't retroactively remove it
If a file's content was read into the conversation earlier in a session, adding or correcting a .rooignore rule afterward governs what gets newly read or searched going forward — it doesn't reach back and strip content that's already part of the running conversation's context.
The Fix
1. Confirm .rooignore is actually at the workspace root
ls -la .rooignore
Verify the file exists at the true root of the workspace, not a subdirectory — this is the first thing to check when rules appear to have no effect at all, rather than a partial or unexpected effect.
2. Test suspect patterns explicitly rather than trusting them by inspection
# create a throwaway file matching the intended pattern
touch build/test-exclusion-check.log
# then confirm a search/list operation actually excludes it
A pattern that looks obviously correct when read can still fail to match due to a missing anchor, an unintended trailing slash, or an overly narrow glob — creating a real file that should match and confirming it's actually excluded from search/listing results is a more reliable check than reasoning about the pattern in the abstract.
3. Treat .rooignore as reducing discovery, not as an absolute security boundary
.rooignore is well-suited to keeping generated output, vendor directories, and routine noise out of search results and context. It is not a substitute for actually keeping secrets out of the repository — a credentials file excluded from search can still be reached if directly referenced by path, so the durable protection for genuinely sensitive content is not committing it to the repo at all, with .rooignore as a secondary layer of discovery reduction rather than the primary safeguard.
4. Start a fresh session if sensitive content was already read before the rule was fixed
Correcting a .rooignore pattern or moving it to the correct location only affects what gets read from that point forward. If content that should have been excluded was already loaded into an ongoing conversation before the fix, that content remains in context regardless of the corrected rule — the reliable remedy is starting a new session rather than assuming the fix retroactively addresses what's already there.
Why This Works
Each step addresses a specific way .rooignore's actual behavior can diverge from what was intended without any visible error. Confirming file placement catches the case where the rules never take effect at all; testing patterns against a real file catches syntax mismatches that inspection alone misses; understanding the discovery-vs-block distinction sets the right expectation for what the file actually protects against; and recognizing that rules aren't retroactive prevents assuming a fix has cleaned up content that's already in a running conversation.
Conclusion
.rooignore rules that don't seem to apply are almost never being silently overridden — they're usually a pattern-syntax mismatch, a file placed somewhere other than the workspace root, or a misunderstanding of what the file actually governs (discovery, not an absolute block on every path to a file). Confirm the file's location, test suspect patterns against a real file rather than trusting them by inspection, treat .rooignore as a discovery-reduction tool rather than a substitute for not committing secrets, and start a fresh session if sensitive content was already read before a rule was corrected.
