If you use an AI coding assistant, it reads your project to answer questions about it. Your project probably contains a .env file with a live database password in it. Those two facts sit uncomfortably together, and most people have never checked what their tool actually does.
The short version: the major tools exclude .env by default, but the exclusion is a default and defaults can be changed, overridden by a prompt, or bypassed by a terminal command the assistant runs. Treat exclusion as a convenience, not a security control.
What is actually at risk
Three separate things, often confused.
Indexing. Many assistants build a searchable index of your codebase, which can mean file contents leave your machine and are stored by the vendor. This is the one people worry about most.
Context. When you ask a question, the tool sends relevant file contents to the model. Even without indexing, a file can be included in a single request.
Agent actions. Agentic tools run commands. cat .env is a command. An assistant debugging a connection error may read the file itself, and no ignore list stops a shell command the tool decided to run.
The third is the one people forget, and it is the one ignore files do not cover.
What each tool does by default
Behaviour changes between releases, so check your version rather than trusting this or any other article.
Cursor ignores .env by default and supports .cursorignore for additional exclusions. Files listed there are excluded from indexing and from being added to context. Cursor's own documentation notes the exclusion is best-effort rather than a hard guarantee, particularly where an agent runs terminal commands.
GitHub Copilot excludes files matching common secret patterns from its context, and organisations on Copilot Business and Enterprise can configure content exclusions centrally at repository or organisation level, which is enforced server side. On individual plans you have less control.
Claude Code respects .gitignore and supports its own ignore configuration. Because it is agentic and runs shell commands, the same caveat applies: an ignore rule prevents a file being read as context, not a command being run.
Windsurf, Zed, Continue and the rest each have their own mechanism, usually an ignore file. Read your tool's docs; do not assume.
How to check what yours is doing
Do not take the marketing copy for it.
- Ask it directly. In your assistant, ask "what is in my .env file." If it answers with real values, you have your answer immediately.
- Check the ignore file exists.
.cursorignore,.aiignore, whatever your tool uses. If you have never created one, you are relying entirely on the default. - Check the privacy setting. Most tools have a mode that disables sending code to the vendor. Cursor calls it Privacy Mode. It is usually off by default.
- Check what your terminal history shows. If the assistant has run
cat .envorprintenvwhile helping you debug, that output was in the conversation.
Reducing the exposure
Add an ignore file, even though the default covers you. Belt and braces, and it documents the intent for whoever joins next:
.env
.env.*
!.env.example
*.pem
*.key
secrets/
credentials.json
Turn on privacy mode if your tool has one and your work is sensitive.
Do not keep production credentials on your development machine. This is the actual fix. If your local .env contains test keys pointing at a test database, an accidental exposure costs you a rotation and nothing else. If it contains a live Stripe key, it costs you rather more.
Use test credentials locally. Stripe test keys, a local database, a sandbox account. The strongest control is not having the dangerous value present.
Rotate if you suspect exposure. Cheap, fast, and removes the uncertainty.
Why ignore files are not a security boundary
An ignore file is a request to the tool. It is not a permission model. Four ways it fails:
- Agent shell commands. The assistant runs
cat .envwhile debugging and the contents are in the conversation regardless of the ignore rule. - Prompt override. You paste the file into chat yourself because you are debugging an env problem. People do this constantly.
- Indirect reads. A log file, a crash dump or a test fixture contains the same value, and that file is not excluded.
- Configuration drift. Someone clones the repo without the ignore file, or the tool updates and the format changes.
None of these are hypothetical. They are the normal way this happens.
The structural answer
The reliable fix is not having secrets sit in a file on a machine running an AI assistant.
That is what secrets management does: values live in a central store, and your application receives them at run time rather than reading a file. With Krypt, which we build, krypt run -- npm start injects the secrets into the process and never writes them to disk, so there is no .env for anything to read. Doppler and Infisical do the same thing with their own CLIs, and this comparison covers the options.
Being honest about the limit: the process still has the values in its environment, and an agent running printenv inside that process would see them. What you remove is the file sitting there permanently, readable by anything with filesystem access. That is a meaningful reduction, not a guarantee.
If you are a solo developer with test credentials, this is not worth restructuring for. If your local environment can touch production, it is.
FAQ
Does Cursor read my .env file? It excludes .env from indexing and context by default and supports .cursorignore for more. The exclusion does not cover terminal commands an agent runs, and you can still paste the contents in yourself.
Does GitHub Copilot send my secrets to GitHub? Copilot filters common secret patterns from context. Business and Enterprise plans support server-side content exclusions; individual plans offer less control.
Is a .cursorignore file enough? It reduces the risk, it does not eliminate it. It stops passive reading, not agent shell commands or you pasting the file into chat.
Should I stop using AI coding tools? No. Stop keeping production credentials in files on your development machine. That is the risk, and it existed before AI assistants did.
What if a secret was already exposed? Rotate it. It is quick, and it converts an unknown into a closed issue.