.env file risks

The twelve-factor pattern of storing config in environment variables is sound for production platforms. The local convention of a plaintext .env file next to your code is convenient — and that convenience is exactly why it breaks down once AI agents, formatters, test runners, and MCP tools all load the same directory tree.

Plaintext on disk

A .env file is readable by any process running as your user, any backup tool that includes your home folder, and any sync client that mirrors the project to another machine. Gitignore only helps until someone force-adds, copies to .env.local, or commits an example file with real values. Encryption at rest for the whole disk does not stop malware or a stray cat .env in an agent log.

Inheritance in every child process

Developers often export $(cat .env | xargs) or use a tool that loads dotenv into the shell. Every subprocess — tests, dev servers, one-off scripts — inherits the full set of secrets. Agents amplify this: they spawn many short-lived commands, any of which can print environment debugging. Scoped allowlists and injecting only required names at launch shrink what appears in that inherited block.

Accidental sharing

Screen shares, pair programming recordings, crash dumps, and support bundles routinely include cwd files. Models asked to "fix my config" may read and repeat .env contents. Treat dotenv files like private keys on paper: keep them out of repositories, tickets, and chat. Use .env.example with dummy placeholders only.

Drift between machines

Without a vault, each laptop accumulates slightly different env files. Rotation on one machine leaves stale keys elsewhere. A single encrypted vault with named secrets and explicit latchkey run entry points makes updates repeatable: change the value once locally, restart dependent processes, delete old exports.

A practical local pattern

1. Delete real secrets from tracked and untracked dotenv files when possible.
2. Store values in an encrypted vault; add with LATCHKEY_VALUE=… latchkey add NAME.
3. Declare allowed names per repo in .latchkey.toml so agents only receive what that project needs.
4. Start dev and agent commands through latchkey run -- your-command instead of a globally exported env.
5. Run an offline scan (latchkey scan) before pushing if you are unsure history is clean.

Production is different

Hosted platforms inject env vars at deploy time; you still should not copy production secrets into local dotenv for convenience. Use separate keys per environment, rotate when people leave the team, and keep production values in the platform's secret store — not in a developer's Downloads folder.

More on agent-specific risk: Keys and AI agents. Questions: Yusuf@yusuf-choudhury.com.