Preventing agent from using certain files or directories

Support Help
,
1

Hello,

I’m new to Cursor and noticed that the agent made a change based on a pattern elsewhere in my codebase that I didn’t realize it would use (this is a relatively large project). Please, how can I prevent the agent from considering certain files or directories as context while still allowing me to manually access and edit them?

Thanks!!

5

Hey, and welcome to Cursor.

What you need is a .cursorignore file in your project root. The syntax is the same as .gitignore. Just list the files or folders the agent should skip, for example:

legacy/
docs/old-designs/
src/experiments/**
*.snap

Anything matching these patterns is hidden only from AI features. The agent’s file search and file reads, Cursor Tab, and Inline Edit won’t look there, and those paths also won’t show up in @-mentions. The editor itself is not affected at all, you can still open, edit, and save those files as usual. Files from .gitignore are already excluded from the agent search by default, so in .cursorignore you only need to list what is actually tracked in git.

A couple notes:

  • Commands the agent runs in the terminal (for example cat somefile) can still see these files, so this is more about context control, not a hard security barrier.
  • If you enable Hierarchical Cursor Ignore in Cursor Settings (not VS Code settings) > Indexing > Ignore Files, Cursor will also pick up .cursorignore files from parent folders.

If your goal is not to hide a folder completely, but to stop it from copying patterns from folder X, a project rule works well alongside this. Go to Cursor Settings (not VS Code settings) > Rules, and add a project rule like “Do not use code under legacy/ as a reference for new code”. This guides the agent without blocking the files.

Full syntax docs are here: Ignore File | Cursor Docs

Let me know if anything doesn’t work the way you expect.

6

Perfect! Thank you!!

7

The .cursorignore approach solves the immediate problem, but I think there’s a deeper issue here: it’s not only which files the agent can see, but which files it treats as evidence for a change.

On a large codebase, it may help to distinguish three categories:

  1. Files the agent is allowed to inspect for context.
  2. Files that are authoritative evidence for current behavior — for example, code that actually ships and current documentation.
  3. Stale, archived, generated, or historical files that may provide context but shouldn’t be treated as current truth.

That seems especially relevant to the problem you described: the agent found a pattern elsewhere in the repo and used it to justify a change you weren’t expecting.

Before accepting a non-trivial change, you could ask the agent to list the specific files and code locations it used as evidence. If the reasoning depends on stale or unrelated code, you can catch that before allowing the edit.

So the boundary becomes not only “what is the agent allowed to read?” but also “what is the agent allowed to trust?”

8

Good point, @dan_liao. Separating what the agent is allowed to read from what the agent can trust as a current source is a really useful framework on a large codebase.

Some of this can already be set up today:

  • Project rules for meaning-based boundaries. Besides .cursorignore, you can add a rule like: code under legacy/ and generated files shouldn’t be treated as the reference for new code, use them only as background context. This matches your category 3: files are visible, but not authoritative.
  • Plan mode before non-trivial changes. The agent first shares a plan and what it relies on, so you can see the approach before any edits: Plan Mode | Cursor Docs
  • Ask the agent to quote evidence directly in the prompt, like: list the exact files and sections you’re relying on. That’s exactly the pattern you described, and it works today.
  • Agent review to review the diff before accepting it: Agent Review | Cursor Docs

I’ll pass the idea of native trust levels (authoritative / stale / historical) as a separate concept to the team as feedback. It’s a really interesting direction.