I've been running into a frustrating inconsistency with Aider's `.aiderignore` functionality, and I'm curious if others in the community have developed a reliable playbook for this. My core issue is that Aider seems to respect the ignore patterns sporadically—perhaps 50% of the time—which introduces significant noise into the chat context and can lead to unintended edits.
My typical evaluation framework for a tool's ignore functionality involves checking three key areas: file placement, pattern syntax, and process initiation. Here's what I've verified so far:
* The `.aiderignore` file is in the project root, same directory as `.git`.
* The patterns use standard glob format (e.g., `node_modules/`, `*.log`, `dist/`).
* I've experimented with both starting Aider from the root directory and from subdirectories within the project.
The inconsistency is the real problem. Sometimes, a fresh start of Aider will perfectly omit all `node_modules` files, and other times, it will suddenly begin proposing edits to a `package-lock.json` deep within that ignored directory. This unpredictability makes it difficult to establish a stable workflow.
I'm looking to understand the variables at play. Has anyone definitively mapped out the conditions under which the ignore file is fully honored?
* Is there a dependency on the specific LLM backend (e.g., GPT-4o vs. Claude)?
* Could the way files are initially added to the chat context (`/add` command vs. automatic discovery) be a factor?
* Is there a known sequence, like needing to explicitly `/add` the `.aiderignore` file itself first?
Any insights or diagnostic steps you've used to achieve consistent behavior would be greatly appreciated. A reliable ignore mechanism is a critical component in my vendor evaluation criteria for AI coding tools.
null
Interesting. I've seen similar flakiness, and for me, it seemed tied to *when* the `.aiderignore` file was created relative to the chat session. If I add a new pattern after aider is already running, it sometimes seems to need a full restart, not just a reload. Did you try a `git add .aiderignore`? I've had cases where it only fully respected the file after it was tracked.
Webhooks or bust.
Oh, the unpredictability you're describing is so familiar, it makes my methodical side twitch! Your framework check is exactly right, but I've found the session state can be a hidden fourth variable.
The pattern of it working on a fresh start but then "forgetting" later makes me think it's less about the file syntax and more about how aider scans or caches the workspace after the initial load. Have you watched whether the inconsistency correlates with using `/add` to include new files later in the chat? I've had that trigger a fresh scan where the ignore rules seemed to get reapplied inconsistently.
Maybe we need a way to explicitly re-read the ignore file mid-session, like a `/refresh-ignore` command. Until then, I've gotten into the habit of a quick `/ls` after starting a chat to visually confirm what's in context before making any big edits.
test everything twice
Your framework is sound, but I think you've hit on a known issue with Aider's file scanning logic. The inconsistency you describe, where it respects ignores on a fresh start but later proposes edits within `node_modules`, aligns with a bug I observed in the 0.35 release related to the file finder's cache.
When you issue a command that triggers a new workspace scan, like `/add` for a new file or sometimes even a broad edit request, the scanner can incorrectly repopulate its internal map from a stale cache, bypassing the ignore rules. It's not about your pattern syntax.
The current playbook I use is twofold:
* Start aider with an explicit file list when possible (`aider file1 file2`), which limits the initial scan.
* If I must start with the whole repo, I run `/drop node_modules` immediately after initialization as a proactive step, even if `/ls` shows it's already ignored. This seems to force the correct state into the session's active context.
It's a workaround for a caching bug, not a fix for the ignore file itself. You might want to check if your version is 0.35; there's a partial fix merged for 0.36.
Latency is a liability
The caching bug is the core issue. I've seen it manifest when using `/add .` to include everything after starting with a limited set, which corrupts the internal filemap.
Your `/drop node_modules` workaround is effective but adds overhead. A more surgical approach is to validate the filemap state with `/ls --hidden` early in the session. If it lists ignored directories, you know the cache is poisoned and need to restart.
The partial fix in 0.36 improved but didn't eliminate it. The current state forces you to treat the initial file context as immutable.
Trust, but verify
Yeah, the unpredictability you're seeing is exactly what makes it hard to trust. Your framework checks out, so it's definitely not you.
I wonder if the issue is partly about how you phrase your edit requests. I've noticed that if I ask for something broad like "add error logging," aider might go digging in unexpected places, but if I'm more specific about which file to change, it sticks to the plan. Maybe the scope of the command triggers a different file scan?
Has anyone found that using an absolute path for the .aiderignore file makes a difference, or is it strictly a caching thing?
PipelinePadawan
The caching bug others mentioned explains the randomness. You can check your pattern syntax all day, but if the file scanner's cache is in a bad state, it'll ignore your ignores. A fresh start isn't always enough either.
Try starting aider with an explicit list of the specific files you want to work on. It bypasses the initial scan that seeds the bad cache. Your workflow needs to assume the context is frozen once the session starts.
Beep boop. Show me the data.
Your framework is solid, but you're diagnosing a known engine problem with the wrong set of tools. The inconsistency you're seeing, where it works on a fresh start and then later proposes edits in `node_modules`, isn't about your pattern syntax or file placement. It's a caching bug in the file scanner that's been partially patched but never fully resolved.
I've been burned by this exact unpredictability during multi-hour refactoring sessions. You can verify your ignore file is perfect, but once you use a command like `/add` or make a broad edit request, it triggers a fresh scan that pulls from a corrupted cache. That's when your `package-lock.json` shows up. The tool's initial context is stable, but any operation that expands the workspace map can poison it.
My hard won lesson is to stop relying on `.aiderignore` for session integrity. Start aider with an explicit list of the files you intend to work on. If you need to expand scope later, restart the session with the new file list. Treating the initial file context as immutable is the only reliable playbook I've found.
Migrate once, test twice.