In a repository whose .gitignore already excludes node_modules/, dist/ and the build output, a developer copies all of those patterns into .cursorignore as well, and separately cannot get Agent to find a generated file that git ignores. What explains both observations?

The principle — Cursor's exclusions start from git. It automatically respects your .gitignore patterns, and files ignored by git are ignored by Cursor's indexing, so .cursorignore exists for additional exclusions beyond that baseline.

Why the key is correct — Copying node_modules/, dist/ and build output into .cursorignore restates rules already in force, so the copy has no measurable effect. The same rule produces the second symptom: a generated file excluded by git is outside the index, so Agent cannot reach it through search. That is the default working as designed, not a defect. If such a file genuinely belongs in a conversation, attach it directly with an @ mention rather than waiting for search to surface it.

Why the others are wrong — Believing the index covers the whole working tree is the belief this behaviour contradicts; were it true, the duplicated patterns would have been the only thing keeping those folders out, and removing them would change the index. The override reading fails because .cursorignore adds exclusions and offers no way to re-include something git has already ignored, so the duplicates cannot have restored anything. And splitting the behaviour by whether a directory is tracked invents a distinction that does not exist; git's patterns apply across the repository and Cursor honours them the same way.

Remember this — Reserve .cursorignore for what git keeps but Cursor should skip: committed fixtures, vendored bundles, large data files, generated snapshots. Duplicating .gitignore into it is effort with no effect, and an unexplained gap in what Agent can see is usually a .gitignore entry quietly doing its job.

Sources — Cursor's Ignore files documentation.