What an AI Assistant Ignore File Actually Excludes
Ignore Files Are a Context Boundary Not a Security Control
An ignore file keeps a path out of the assistant context window. It does not keep the secret out of your repository.
That distinction decides how much you should trust it. GitHub scopes content exclusion to admins and org owners, and gives it up to 30 minutes to reach an editor that is already running. GitHub also states that it does not apply to the Edit and Agent modes of Copilot Chat, or to Copilot CLI. Cursor scopes .cursorignore to Agent, Tab, Inline Edit and @ mentions, and documents that terminal and MCP server tools cannot be blocked by it.
So use the ignore file to cut noise and reduce casual exposure. If a credential has already been read, rotate it.
What Copilot Content Exclusion Actually Turns Off
- ● Set by repo admins and org owners, not by you
- ● Up to 30 minutes to reach a loaded editor
- ● No coverage in Edit mode, Agent mode, or the CLI
Content exclusion is a server side setting rather than a file you commit. Repository administrators, organization owners, and enterprise owners configure it, which means an individual developer usually cannot add a path alone.
When a path is excluded, GitHub stops four things. Copilot no longer offers inline suggestions inside that file, no longer uses its content to inform suggestions in other files, no longer references it in Chat answers, and no longer reviews it during code review.
Coverage varies by editor, and that surprises people who assume one setting protects every surface. Visual Studio, Visual Studio Code and JetBrains IDEs honour exclusions for both inline suggestions and Chat.
Vim, Neovim, Xcode and Eclipse honour it for inline suggestions only. The GitHub website and mobile app honour it for Chat only.
Two structural gaps matter more than the editor list. Symlinks are not covered, and neither are repositories on a remote filesystem, so a linked path can walk straight around a rule that looks correct in the settings page.
How .cursorignore Draws Its Line
Cursor takes the opposite approach and puts the rules in a file at the root of the project. The syntax is gitignore syntax, so the patterns you already know carry over.
What it governs is code reachable by the Agent, by Tab completion, by Inline Edit, and by @ mention references. That covers the paths most developers actually use to pull a file into a prompt.
The documented exception is the one worth writing on a sticky note. Terminal commands and MCP server tools invoked by the agent cannot be blocked by .cursorignore, so an agent that runs a shell command reads whatever the shell can read.
There is also a pattern trap. Negation has limited reach, and you cannot re-include a file when its parent directory was excluded with a star pattern.
The fix is to exclude the nested directories you actually mean rather than the whole parent. It is more typing and far fewer surprises.
The Two Mechanisms Side by Side
The mechanisms look similar from a distance and behave differently in the places that matter.
| Question | Copilot content exclusion | Cursor .cursorignore |
|---|---|---|
| Where the rule lives | Repository, organization or enterprise settings | A file at the project root |
| Who can change it | Repo admins, org owners, enterprise owners | Anyone who can commit to the repo |
| Time to take effect | Up to 30 minutes in an editor already running | On the next read by the agent or editor |
| Agent surfaces covered | Not covered in Edit mode, Agent mode or Copilot CLI | Agent covered, but not its terminal or MCP tools |
| Known blind spots | Symlinks, remote filesystem repositories, indirect type data | Terminal, MCP tools, negation under a star pattern |
| Syntax | Path lines per repository reference | Standard gitignore patterns |
Read the table as two answers to one question. Copilot centralises the decision so an organisation can enforce it, and Cursor decentralises it so a developer can move fast.
Neither model is stronger on paper. The one that works for you is the one whose owner is the person who actually notices when a sensitive directory appears.
Patterns That Do What You Think They Do
Most failed exclusions are pattern bugs rather than product limitations. These are the shapes that behave predictably.
# .cursorignore - exclude the directories you mean, not the parent
infra/secrets/
config/production/
**/*.pem
**/*.key
.env
.env.*
# fixture data is noise in context, not a secret
tests/fixtures/large/
Notice what is not there. There is no star at the top of the file followed by a list of exceptions, because negation cannot rescue a file whose parent was excluded that way.
For Copilot, the path list lives in the repository settings under Copilot and then Content exclusion. A leading star matches a file anywhere, and a repository reference followed by indented paths scopes rules to one repository.
Write one pattern per line in both systems. A single line holding several patterns is the most common reason a rule silently matches nothing.
A Starting File You Can Copy
Ignore files use the same glob syntax as .gitignore, which is why the mistakes are the same ones. A leading slash anchors to the project root, a trailing slash means directory, and a later negation can re-include something an earlier rule excluded.
# Secrets and credentials
.env
.env.*
**/secrets/
*.pem
*.key
# Vendor data and generated output that only wastes context
node_modules/
dist/
build/
coverage/
*.min.js
# Large fixtures the assistant does not need to read
**/__fixtures__/**
**/*.snap
# Re-include one example so the assistant still learns the shape
!.env.example
The last line matters more than it looks. Excluding every .env* file and then re-including .env.example gives the assistant the variable names without the values, which is usually what you actually wanted.
The Leaks That Survive an Ignore Rule
- ● Terminal and MCP tools read the file anyway
- ● Type hints and build config leak shape
- ● Git history keeps every committed version
The first leak is the one both vendors document. A terminal command or an MCP tool run by an agent reads files through the operating system, and the ignore layer never sees the request.
The second leak is semantic rather than textual. GitHub states that Copilot may still use information from an excluded file when the editor supplies it indirectly, including type information, hover definitions and build configuration.
That means the shape of your code escapes even when the text does not. A function signature imported from an excluded module can appear in a suggestion because the language server, not the file, provided it.
The third leak is history. Excluding a file today does nothing about the version you committed last spring, and an assistant reading the repository can reach it through ordinary git commands.
The fourth leak is the copy. Secrets duplicated into a README, a docker compose file or a test fixture live outside the path you excluded.
None of this makes exclusion pointless. It makes exclusion a filter on attention rather than a wall, which is exactly how you should size your trust in it.
Which Exclusion Setup Fits Your Repository
- ● Solo repo - .cursorignore plus a secret manager
- ● Org repo - admin exclusions on shared paths
- ● Regulated code - assume exclusion is best effort
Solo developer on a private repo: Put .cursorignore in the project and pair it with a secret manager or environment variables. You control the file directly, and the pattern list doubles as documentation for future you.
Small team using Copilot in one org: Ask an org owner to set content exclusion once at the organization level rather than per repository. Allow 30 minutes before testing, and restart editors that were open when the rule landed.
Team running agents that execute commands: Assume the ignore file gives no protection here. Both vendors say the terminal path is outside the boundary, so keep production credentials out of the working tree entirely.
Repository with a large monorepo context problem: Use exclusions for signal rather than secrecy. Dropping generated code, vendored dependencies and large fixtures usually improves suggestion quality more than any prompt tweak.
Regulated or audited codebase: Treat exclusion as best effort and document it that way. The indirect type information caveat means you cannot promise an auditor that an excluded file never influenced output.
Three Mistakes That Make an Ignore File Useless
The first mistake is treating exclusion as remediation. If an assistant has already read a key, the correct response is to rotate the key, not to add a line to a file.
The second mistake is testing in the wrong window. A Copilot rule can take half an hour to reach an editor that was already open, so a developer who tests immediately concludes the rule failed and removes it.
The third mistake is excluding the parent and expecting the exceptions to work. A star pattern on a directory closes the door on everything beneath it, and the negation line you added afterwards does nothing.
There is a quieter fourth. Excluding your rules or configuration files starves the assistant of the context that makes it follow your conventions. That is the opposite failure to the one our guide on setting coding standards an assistant will follow describes.
Treat the Ignore File as the First Layer
An ignore file is worth writing on day one of a project. It costs a few minutes, it cuts irrelevant context, and it removes the easiest accidental exposures.
What it cannot do is make a promise about an agent with shell access, about type information the editor volunteers, or about anything already in your history. Those need different tools.
So layer it. Keep credentials outside the repository, scope the exclusions to real directories, verify after the propagation window, and rotate anything you suspect was read. Our notes on what assistants see in your repository and on assistant data privacy cover the surrounding decisions, and the generated code security checklist covers what to check after the code is written.
FAQ
Does an ignore file remove a secret from my repository?
No. It stops the file from being sent as context for suggestions and chat, but the file still sits in your working tree and your git history. Anything already committed stays committed.
How long does a Copilot content exclusion take to apply?
GitHub documents a delay of up to 30 minutes before a new exclusion takes effect in editors that already have the settings loaded. Restarting the editor is the fastest way to be sure the new rule is live.
Do Copilot exclusions apply to agent mode?
GitHub states that content exclusion is not supported in the Edit and Agent modes of Copilot Chat, and not supported in Copilot CLI. Those surfaces can still read an excluded path.
Can a Cursor agent still read a file listed in .cursorignore?
Cursor documents that terminal commands and MCP server tools run by the agent cannot be blocked by .cursorignore. A shell command that cats the file still returns its contents to the agent.
If I exclude a file, is its content definitely invisible to the assistant?
Not reliably. GitHub notes that Copilot may still use semantic information from an excluded file when the editor supplies it indirectly, such as type definitions and build configuration.
Sources
- Model Context Protocol — checked 2026-09-07
- GitHub Copilot documentation — checked 2026-09-07
- Cursor documentation — checked 2026-09-07
Some links may be affiliate links. We may earn a commission at no extra cost to you.
This article was written with AI assistance. It is researched and fact-checked, not based on personal hands-on testing unless explicitly stated.
Comments
Post a Comment