How to stop your coding agent from reading your .env secrets A developer created Klavex, a CLI tool that eliminates plaintext `.env` files by storing secrets in an encrypted vault and injecting them only into child processes. The tool prevents coding agents like Cursor and Claude Code from reading sensitive credentials during file scans, as secrets never exist on disk. Klavex also supports read-only tokens for CI runners and agents, with per-environment scoping and audit logging. Open Cursor, Claude Code, or any MCP-enabled agent in your project and ask it to "fix the failing test." To do that, it reads files. Lots of them. And nothing stops it from reading this one: .env It doesn't matter that .env is in your .gitignore . .gitignore keeps it out of git — it does nothing about a read file '.env' tool call dropping STRIPE SECRET KEY=sk live ... straight into a model's context window. The same file that boots your dev server is sitting in plaintext, on disk, readable by every agent you've invited into your editor. I stared at that for a while and realized the fix isn't "scope the agent down." The fix is: don't have a plaintext secrets file at all. Instead of a .env , you wrap your command: klavex init pick your project + environment once klavex run -- npm start that's it — no flags after this The CLI pulls that environment's variables from an encrypted vault and injects them into the child process only . Your shell never sees them. Nothing is written to disk. So when the agent goes looking: bash $ cat .env cat: .env: No such file or directory There's nothing to read, because the keys only ever existed inside the npm start process. That's the whole pitch in one screenshot. It also quietly fixes the boring team problems: no more "ping six people on Slack for the right keys," no more stale .env after someone rotates a credential — rotate it once, every machine picks it up on the next klavex run . pip install klavex Python 3.10+, macOS/Linux/WSL klavex login opens the browser once, token goes in your OS keychain klavex init klavex run -- npm start That's the entire surface area. I deliberately kept it small — most secrets tools turn into a platform you have to administer. This is three commands. "No .env " handles accidental leakage. But sometimes you genuinely want an agent or a CI runner to use real secrets. For that you mint it its own token, scoped to exactly the environments you pick: In the dashboard: New agent → name it → tick the environments it may read → copy the token shown once . On the agent / CI machine — no browser, no interactive login: export KLAVEX TOKEN=kx agent xxxxxxxx klavex run -e env dev abc123 -- npm test That token is read-only it can read its scoped secrets, but can't create, change, or delete anything and the backend refuses to decrypt any environment it wasn't granted. Grant it dev , and a request for prod comes back 403 . Every fetch lands in an audit log, and revoking the token kills it everywhere. Let me be honest about the boundary, since this is a security tool and overclaiming is how you lose a dev audience: Klavex is not a sandbox. Anything that can execute arbitrary commands as you can still reach the secrets at runtime — it can read /proc/