A .env file holds all your secrets in one place, so committing it exposes every one of them at once. If Cursor added and committed a .env, treat every value in it as compromised. Rotate all of them, remove the file from git history, and make sure .env is gitignored and excluded from Cursor's indexing so it does not happen again.
Why it's a problem
A committed .env is a single file with your database URL, API keys, and signing secrets together. In a public repo it is a prime scraper target, and even in a private repo it is exposed to every collaborator, fork, and CI log. One committed .env can compromise your entire backend at once.
How to fix it, in order
- 1Rotate every secret in the file. Regenerate each key, token, and database credential the .env contained. All of them should be considered exposed.
- 2Remove .env from git history. Purge it with git filter-repo --path .env --invert-paths or BFG, then force-push. Rotation in step one is what actually protects you.
- 3Gitignore it, then confirm. Add .env to .gitignore and verify git status no longer tracks it.
- 4Exclude it from Cursor. Add .env to a .cursorignore so Cursor never indexes it into a prompt.
Why Cursor does this
When a .env is not already in .gitignore, a broad staging action like git add . sweeps it in, and Cursor can run exactly that while completing a task. Cursor also indexes workspace files, so a .env not in .cursorignore can be read into prompts as a separate exposure.
Stop it happening again
Add .env to .gitignore before you create it, keep a committed .env.example with empty values instead, add .env to .cursorignore, and install a gitleaks pre-commit hook so a committed secret file is blocked.
The quick fix
- Rotate every secret the .env contained.
- Purge .env from git history and force-push.
- Add .env to .gitignore and confirm it is untracked.
- Add .env to .cursorignore and install a gitleaks pre-commit hook.