Your AI Tool's Ignore File Is a Request, Not a Lock

Adding your journal folder to an AI tool's ignore file does not make it unreadable. As documented on 2026-10-10, each vendor scopes its exclusion to some of its own read paths and names the rest in its own docs — Cursor's terminal¹, Claude Code's indirect reads², Copilot's agent mode³. Keep truly private notes outside the folder.

Cursor says it plainly. Its ignore-file page lists what .cursorignore blocks — code accessible by Agent, Tab and Inline Edit, and code reached through @-mentions — then adds: "The terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore."¹ The same page carries the vendor's own security caveat: "While Cursor blocks ignored files, complete protection isn't guaranteed due to LLM unpredictability."¹

None of this is a scandal — it is scope, written down.

The files descend from a format with a different job. "A gitignore file specifies intentionally untracked files that Git should ignore."⁴ The AI tools borrowed that syntax for a new question — what should the model see? — and Aider answers it most directly, describing its file as a way to ignore "parts of the repo that aren't relevant to your task."⁵ Relevance is a fine thing to filter for — it is not the same thing as access.

What follows reads six knobs from five vendors and quotes each page for what it covers and what it says it does not. No tool is ranked. Docs change — treat every line as documented on 2026-10-10, and check the page for your version. This is not legal or security-compliance advice.

What does an AI tool's ignore file actually do?

An AI tool's ignore file tells that one tool which paths to leave out of the context it builds — file pickers, autocomplete, indexing, @-mentions. It borrows gitignore syntax, not a guarantee. Each vendor lists which of its own features honour the file — and no vendor page reviewed here claims that list covers every read path.

The family resemblance is deliberate. Cursor asks for ".gitignore syntax"¹. Claude Code says "Read and Edit rules both use gitignore pattern syntax"². Gemini CLI says its file, "for the most part," follows the conventions of .gitignore files⁶. Aider says its file "conforms to .gitignore syntax and conventions."⁵ The pattern rules themselves — negation, trailing slashes, which file wins — are covered in a .gitignore for your notes, so they are not repeated here.

Six knobs, six file names, one borrowed syntax.

This is also a different layer from an instruction file. An AGENTS.md asks the model to behave; an ignore file asks the tool to filter before the model is involved. The instruction-file problem is its own post. The gap below is not the model disobeying. It is which of the tool's own read paths the filter was built into.

Cursor: what does .cursorignore cover?

As documented on 2026-10-10, .cursorignore blocks listed files from code accessible by Agent, Tab and Inline Edit, and from @-mention references. The same page says the Agent's terminal and MCP server tools cannot block access to those files. A command the agent runs in a shell sits outside the filter by design, and the vendor says so.

Cursor also stacks three lists. It "automatically ignores files in .gitignore and the default ignore list," on top of .cursorignore, and offers a global list for all projects that is "empty by default."¹ A folder already in your vault's .gitignore is therefore skipped by Cursor's covered features — no second entry needed.

The most-cited story about this file is older and narrower. A Hacker News submission titled "Cursor uploads .env file with secrets despite .gitignore and .cursorignore" was posted on 2025-03-11 and stood at 46 points on 2026-10-10⁷.

Two days after it was posted, a Cursor staff member answered on the vendor's forum: "there was a bug that caused Cursor Tab to show suggestions that could contain sensitive data, if you've recently edited an ignored file (added to .cursorignore). This has been fixed in version v0.47 which is currently rolling out."⁸

That was a bug in a covered path, and the vendor reported it fixed.

The terminal and MCP scope is different — not a bug, but the documented edge of the feature, stated on the page. If an agent can run commands in a terminal, the ignore file is not what stands between it and your journal.

Claude Code: why does a Read deny rule miss some reads?

Claude Code has no ignore file; it uses Read(...) deny rules in its settings, in gitignore pattern syntax. As documented on 2026-10-10, they cover built-in file tools, recognized Bash commands such as cat and tail, and redirect targets — but not grep -r pattern . run from the folder, or a script that opens files itself.

The vendor's sentence is worth reading whole:

"Read and Edit deny rules apply to Claude's built-in file tools, to file commands Claude Code recognizes in Bash, such as cat, head, tail, sed, and tee, and to the targets of Bash redirections such as > file and < file. They don't apply to a command that reads files without naming them, such as grep -r pattern . run from the directory that holds the file, or to arbitrary subprocesses that read or write files indirectly, like a Python or Node script that opens files itself."²

Coverage of the rest is graded — not absolute. "Claude makes a best-effort attempt to apply Read rules to all built-in tools that read files like Grep and Glob, to @file mentions in your prompts, and to the selection and open-file context that a connected IDE shares with Claude."²

Best-effort is a promise of intent, not of coverage.

One piece of folklore ends here — the .claudeignore file. "If your project has a .claudeignore file, it has no effect, so move its entries into Read deny rules."²

The page then points past itself: "For OS-level enforcement that blocks all processes from accessing a path, enable the sandbox."² That pointer is honest — and it leads to the next surprise.

Is the Claude Code sandbox a lock?

Only once it is configured for your folder. As documented on 2026-10-10, the sandbox is off by default, and when on, its default read behaviour is "read access to the entire computer, except certain denied directories."⁹ It governs shell commands and the processes they start; the built-in Read tool follows permission rules instead. A private folder needs both denials.

The sandbox page draws the line itself. "A denyRead entry doesn't stop the Read tool," and other processes Claude Code starts — "command hooks, local MCP servers … run with your full access."⁹ Inside the boundary, the enforcement is real: while the sandbox is on, "the shell commands Claude runs start inside its boundary, and so do the processes they start."⁹

So the two mechanisms cover each other's gaps. The Read deny rule stops the built-in tool. The sandbox denyRead stops a grep -r or a Python script launched from the shell. Neither alone covers both.

A minimal shape, for a journal kept at ~/notes/journal, goes in a settings file such as ~/.claude/settings.json:

{
  "permissions": {
    "deny": ["Read(~/notes/journal/**)"]
  },
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/notes/journal"]
    }
  }
}

Two details matter. The path syntax differs between the layers: in Read rules //path is absolute and /path is relative to the settings source, while sandbox paths treat /path as absolute; ~/ means your home directory in both²⁹. And local MCP servers and hooks still run outside the sandbox, per the same page⁹. Check both pages for your version before you rely on this.

GitHub Copilot: where does content exclusion apply?

As documented on 2026-10-10, Copilot's content exclusion is an admin setting for organizations on Copilot Business or Copilot Enterprise. When on, excluded files lose inline suggestions and stop informing Copilot's responses. The page also says exclusion is not supported in Edit and Agent modes of Copilot Chat in Visual Studio Code and other editors.

The page opens with its audience: "Who can use this feature? Organizations with a Copilot Business or Copilot Enterprise plan."³ It names who sets it — "Repository administrators, organization owners, and enterprise owners" — and what it does: excluded content "will not inform Copilot's responses," and affected files "will not be reviewed in a Copilot code review."³

Then come the edges, each in the vendor's words. "Content exclusion is currently not supported in Edit and Agent modes of Copilot Chat in Visual Studio Code and other editors."³ And: "Currently, content exclusions do not apply to symbolic links (symlinks) and repositories located on remote filesystems."³ If a notes folder reaches a repository through a symlink — or the repository sits on a network share — that sentence may apply to you.

The limitations section adds one more: "It's possible that Copilot may use semantic information from an excluded file if the information is provided by the IDE indirectly. Examples of such content include type information and hover-over definitions for symbols used in code, as well as general project properties such as build configuration information."³

The page's per-editor availability table uses icons — read it rendered, for your own editor, rather than trusting a summary.

Gemini CLI, Gemini Code Assist and Aider: three more files

Gemini CLI reads .geminiignore, Gemini Code Assist reads .aiexclude by default, and Aider reads .aiderignore from the git root. Each borrows gitignore conventions. Gemini CLI applies its file only to tools that support it; Aider frames its file as relevance, not privacy. As documented on 2026-10-10, a note excluded from one is not excluded from the others.

Gemini CLI's doc is short and candid. "Adding paths to your .geminiignore file will exclude them from tools that support this feature, although they will still be visible to other services (such as Git)."⁶ Its worked example is the @ command for sharing files. Edits are not live either: "To apply the changes, you must restart your Gemini CLI session."⁶

Gemini Code Assist is a separate product with a separate file. "By default, context exclusion is set to use .aiexclude," and its page notes: "For code customization only the .aiexclude file is used."¹⁰

Two Google products, two filenames.

Aider's file sits at a fixed default — ".aiderignore in git root"¹¹ — and its FAQ describes the purpose without a privacy claim: "You can also create a .aiderignore file to tell aider to ignore parts of the repo that aren't relevant to your task. This file conforms to .gitignore syntax and conventions."⁵ That framing matches what an ignore file is — a relevance tool.

The audit, side by side

One knob, six names. The table quotes what each vendor's page said on 2026-10-10 it covers, and what the same page says it does not. It is a scope map, not a leaderboard. A longer right-hand column means a more candid page as often as a narrower feature, so read it as a list of paths to check.

The Claude Code permission layer and its sandbox are listed as two rows because they are two mechanisms with two gap lists. Counting them as one tool, the table covers five vendors and six products.

Read the right-hand column first.

The reverse surprise: what Cursor hides by default

Cursor's default ignore list hides files you may want it to read. As documented on 2026-10-10, it applies on top of .gitignore and .cursorignore and prints 122 entries, 118 of them unique, including *.pdf, *.csv, *.xlsx, *.png and .env*. *.md is not on it, so Markdown notes stay in context while attached PDFs and scans do not.

The list is introduced with one line — "These files are ignored in addition to files in your .gitignore and .cursorignore"¹ — and the count is our own tally of the printed entries on that date. It runs from lockfiles and version-control folders to media and office formats: *.doc, *.jpg, *.svg, *.webp, *.mp3, *.mp4.

For code, the default is sensible. For a notes folder, it inverts the usual worry.

A lab result scanned to PDF is hidden from Cursor's covered features; the Markdown note summarizing it is not.

The page gives the override: "Override with ! prefix in .cursorignore."¹ A line such as !research/*.pdf brings a folder of papers back. The reverse takes a line of your own: a private Markdown note gets nothing from the default list.

Why "which tool blocks the most" is the wrong question

A comparison invites a winner, and this one should not have one. Every vendor documents a different edge, in different words, for a different design. The useful question is narrower: which path would a private note travel, and does this tool's doc name that path as covered? If it does not, the ignore file is not the control.

A ranking would also reward the wrong thing — silence. Cursor, Anthropic, GitHub and Google each publish their gaps in plain sentences. A tool whose page said less would look stronger in a league table and be harder to reason about in practice.

An earlier post here, on deciding what not to feed the AI, listed "folder excludes in your tooling" among the controls that do the enforcing, beneath a written policy that only records your decision. That holds, with a scope note this audit adds. A folder exclude enforces on the paths its vendor names — and only those.

It is partial enforcement, which is still more than none.

Who should rely on an ignore file, and who should not

Rely on an ignore file to keep noise, build output and bulky attachments out of an AI tool's context — that is the job its vendors describe. Do not rely on it alone for a journal, health notes, client files, or anything you would not paste into a chat window. Those need a boundary the tool cannot step around.

An ignore file is enough when:

• The goal is relevance — fewer stale drafts, archives and exports in suggestions. Cursor lists "Performance" beside "Security" as a reason for the file¹.
• The excluded material would be harmless if a terminal command or a script read it anyway.
• You use one tool, and you have read its coverage list for the features you actually use.

An ignore file is not enough when:

• The folder holds a journal, therapy notes, health records, or client files.
• The agent can run shell commands or MCP servers — the paths Cursor's and Claude Code's pages name as outside the filter¹².
• You switch between tools. Each reads its own file, and a note listed in .cursorignore is not listed anywhere else.
• Your Copilot seat is not an organization Business or Enterprise seat, or you work in Edit or Agent mode³.

What actually keeps a private note out?

Three layers, weakest to strongest. An ignore file or deny rule filters what a tool's named features see. A smaller root keeps the note out of the tool's view entirely. OS-level enforcement — or a folder the tool's process cannot open — stops the reads the first two miss. A journal deserves at least the second.

1. The ignore file or deny rule. A relevance filter with documented holes. Keep it — it cuts noise and covers the paths its vendor names.
2. A smaller root. Launch the tool from the folder it needs, not from the vault that holds the journal. Shape the folder you hand your AI covers the knobs, and is honest about its own limit: "A small root is hygiene, not security."
3. OS-level enforcement. In Claude Code, that means the sandbox with denyRead on the path and a Read deny rule, because the sandbox reads "the entire computer" by default and does not stop the Read tool⁹.

The strongest option needs no setting at all — a private note that does not live inside any folder you hand an AI tool cannot be read through that tool. The same logic already applies to secrets in notes an AI reads: move the thing, not the filter.

Short version — filter for relevance, root for hygiene, and keep the private folder somewhere else.

Frequently asked questions

Does .cursorignore stop the agent reading a file?

Partly. As documented on 2026-10-10, .cursorignore blocks listed files from code accessible by Agent, Tab and Inline Edit, and from @-mention references. Cursor's page also states that the terminal and MCP server tools used by Agent cannot block access to those files, and that complete protection isn't guaranteed due to LLM unpredictability.

Did Cursor upload .env files despite .gitignore and .cursorignore?

A 2025 Hacker News thread used that title. Two days later a Cursor staff member wrote on the vendor's forum that a bug let Cursor Tab show suggestions that could contain sensitive data after editing an ignored file, fixed in version v0.47. That was a bug in a covered path; the terminal and MCP scope is a separate, documented limit.

Does Claude Code's sandbox denyRead stop the Read tool?

No. The Claude Code sandboxing page states that a denyRead entry doesn't stop the Read tool, which follows permission rules instead. To keep a folder out of both the built-in tool and shell commands, add a Read deny rule in permissions and a sandbox filesystem.denyRead entry for the same path, then check the page for your version.

Does Claude Code respect a .claudeignore file?

No. Claude Code's permissions page states that a .claudeignore file in your project has no effect, and tells you to move its entries into Read deny rules. Those rules use gitignore pattern syntax. They cover built-in file tools and recognized Bash file commands, but not a grep -r run from the folder or a script that opens files itself.

Does Copilot content exclusion work in agent mode?

No, as documented on 2026-10-10. GitHub's page states that content exclusion is currently not supported in Edit and Agent modes of Copilot Chat in Visual Studio Code and other editors. The feature itself is for organizations on Copilot Business or Copilot Enterprise, and is set by repository, organization or enterprise administrators.

Does .geminiignore apply to every Gemini CLI tool?

The doc does not say so. Gemini CLI's page says paths in .geminiignore are excluded from tools that support this feature, while staying visible to other services such as Git, and gives the @ file-sharing command as an example. Changes need a session restart. Gemini Code Assist is a separate product that reads .aiexclude instead.

If I add my journal folder to the AI tool's ignore file, can the AI still read it?

Possibly, through paths the file does not cover. Each vendor's own page names reads outside its filter, such as terminal commands, scripts, MCP servers or agent modes. For a journal, keep the folder outside the directory you hand the tool, or add OS-level enforcement such as a configured sandbox, and treat the ignore file as relevance only.

A request and a lock

An ignore file is worth keeping. It trims noise and keeps listed files out of the features its vendor names. What it cannot do is promise that every process the tool starts will look away — and on 2026-10-10, not one vendor page reviewed here makes that promise.

An ignore file is a request that a tool's named features agree to honour. A lock is a folder the tool was never handed.

mnmnote.com keeps your notes as open Markdown on your own device, so where a private note lives is a decision you make, not a setting you hope a tool honours.