A developer adds .env.production to .cursorignore and treats it as sealed off from the model. During debugging, the Agent runs a terminal command that prints the file, and a database MCP tool reads it as well. What does this reveal about the guarantee an ignore file gives?

The principle — An ignore file is context hygiene, not an access-control boundary. It keeps files out of the index and out of Agent's own file reads, and it has no authority over processes that run outside Cursor's file access controls.

Why the key is correct — The documentation is explicit that terminal commands and MCP tools run outside those controls, so they may still be able to read ignored files. A shell command that prints a file, or a database tool that returns a row containing it, puts the contents into the conversation — and everything in the conversation is available to the model. The ignore entry was never bypassed; it simply had no jurisdiction over either path.

Why the others are wrong — A restart would change nothing, because the rule was already in force for the things it does govern, and the leak arrived by a route it never claimed to cover. The read-versus-write reading invents a permission model the feature does not have, and printing a file is a read in any case. A broken pattern is a real failure mode, but it produces a different symptom: the file would appear in the index and in search, rather than surfacing only through a command and a tool.

Remember this — Treat a secret as exposed the moment something running in the workspace can print it. Keep credentials out of the repository and in environment variables or a secret store, and use the ignore file for what it is good at: keeping bulk and noise out of context.

Sources — Cursor's Ignore files documentation.