My AI agent overwrote my .env file
Any AI coding tool Last checked 2026-11-03
Your agent read .env for context, then "helpfully" rewrote it — usually while scaffolding a new feature or running a setup script — and replaced your real secrets with placeholder values like your_api_key_here. The app now fails with missing-variable errors because the values in .env are no longer real. Restore from git history or your secrets manager, not from memory.
What you saw
The app that worked five minutes ago now throws Error: Missing required environment variable: DATABASE_URL or process.env.STRIPE_SECRET_KEY is undefined, with no code change that explains it.
Opening .env shows lines like API_KEY=your_api_key_here or DATABASE_URL=postgres://user:password@localhost:5432/dbname — generic placeholder text where real values used to be.
It usually follows a request like "set up the .env for this feature," "add the Stripe keys to the environment config," or a scaffolding/init script the agent ran on your behalf.
What it actually means
The agent did not leak or steal your secrets — it overwrote the file it was supposed to only read. This happens two ways:
- Template generation. You asked it to add new config (a new API integration, a new service). The agent generated a fresh
.env from a template or from an example in the repo (.env.example) and wrote the whole file, not just the new lines — your existing real values were never in that template, so they vanish. - Setup/init tooling. A scaffolding command (
create-next-app, a database CLI, a package installer) ran as part of the agent's task and regenerated .env as a side effect of initializing a new project structure, overwriting the one you already had.
Either way, the agent's working context did not include your actual secret values — it cannot read them to "preserve" them, because .env is usually gitignored and the agent only sees what you show it, or it skimmed the file without treating every line as irreplaceable.
The fix lives in git history, your password manager, or your hosting provider's dashboard — never in the agent's memory of the conversation. It will not remember your real DATABASE_URL; it will generate a plausible-looking fake one if you ask it to "put it back."
The fix
Do not ask the agent to restore the file. It cannot recall values it never had in context, and it will confidently fill the gaps with invented or template values that look real but are not.
Check git first — if .env was ever committed (it should not be, but check), you can recover the last good version:
git log --all --full-history -- .env
git show <commit>:.env > .env
If .env is gitignored (the normal, correct setup) and was never committed, git cannot help. Recover secrets from their source of truth instead:
# Database URL: your hosting provider's dashboard (Vercel, Railway, Render, Supabase)
# Stripe/API keys: the provider's dashboard → API keys section (you can rotate, which is safer anyway)
# Anything stored in a password manager or team secrets tool: pull it from there
Rotate any key that was exposed to the agent's context or to a rewritten template before you restore it. If the old key is still valid, leaking it into chat history or a committed template is a real risk, not a theoretical one.
Once restored, confirm the app actually reads the new file (some dev servers cache environment variables and need a full restart, not a hot reload):
# kill and restart the dev server/process completely
# for Next.js / Node: ctrl-C then re-run `npm run dev`
How to stop it happening again
Keep .env out of every path an agent can regenerate. If you have a .env.example with placeholder keys for onboarding, make sure nothing in your tooling treats it as a template to copy over the real file.
Add an explicit rule to your agent's instructions file (CLAUDE.md, .cursor/rules/, AGENTS.md): "Never write to .env or any file matching .env.*. Propose changes as a diff for me to apply by hand."
Back .env up somewhere the agent cannot touch: a password manager, your hosting provider (which already has the production values), or an encrypted note. Git history only helps for files git actually tracked, which .env usually is not.
Before running any scaffolding or setup command through an agent (create-*, database init CLIs, framework generators), check whether that command writes to .env by default, and if so, run it in an empty directory first or review its diff before letting it touch your real project.
Commit .env.example with placeholder values and keep it current — it gives the agent a sanctioned template to reference instead of guessing at your real file's shape.
Related questions
Why didn't the agent just leave .env alone if it didn't need to change it?
Because many scaffolding tools and "add this integration" workflows write environment config as a standard step, the same way they'd create a config file. The agent (or the tool it invoked) treated .env as output to generate, not as a protected file to preserve.
Is this the same as an agent leaking my .env contents to a model provider?
No — that is a privacy/security issue (the agent reads and transmits your secrets as context). This is a data-loss issue: the agent wrote new content over the file. Both are reasons to keep real secrets out of what you hand an agent, but the fixes are different.
I use Docker / a secrets manager, not a local .env — am I safe from this?
Mostly yes for production, since the agent typically only has filesystem access to your local repo. But local development .env files are exactly where this happens, so the same gitignore-and-backup discipline still applies there.