Stop AI coding agents from reading your .env secrets

I was working in Claude Code when it opened my .env to "understand the configuration" — and then, helpfully, suggested I rotate the keys, since they were now exposed. The thing that exposed them was the agent reading them.

That's the moment the problem clicked. So here's what's actually wrong with .env in an agent-heavy workflow, and the approach I landed on.

The problem: your .env is an agent buffet

The same .env file that lets your dev server boot also feeds every tool in your editor. Cursor, Claude Code, Copilot, and any MCP server you've wired up can cat it whenever they want. There's no permission boundary — if it's on disk and your editor can read your project, the agent can read your keys.

Two things make this worse than the old "don't commit your .env" advice:

• You can't scope an agent down. It's all-or-nothing file access. The agent that needs to read src/ also gets AWS_SECRET_ACCESS_KEY.
• It leaks sideways. The same file gets copy-pasted into Slack to onboard a teammate, screenshared, and synced into who-knows-what.

The root issue is simple: it's a plaintext file sitting on disk, and anything running in your editor can read a file on disk.

The fix: don't keep a .env at all

The approach that actually removes the risk is to stop having the file. Instead of reading secrets from disk, inject them into the process at runtime — only for as long as the command runs.

That's what I built Klavex to do. Setup is one command, and it imports your existing .env so there's nothing to rewrite:

pip install klavex

klavex init                 # detects your repo, imports your existing .env, pins the project
klavex run -- npm start     # secrets injected into this process at runtime — nothing on disk

After klavex init, you delete the local .env. From then on, klavex run -- <your command> pulls the secrets from an encrypted vault straight into that one child process. They're never written to a file, so there's nothing for an agent to open.

Scoping agents instead of trusting them

The part I care about most: when you do want an agent or a CI job to have keys, you don't hand it the whole vault. You mint it a read-only token scoped to specific environments:

KLAVEX_TOKEN=<scoped-token> klavex run -e <env-id> -- ./run-tests.sh

Grant a token Dev, and Production is simply unreachable — the API refuses to decrypt anything outside the token's allowlist. The token can read its scoped secrets but can't create, change, or delete anything. So an agent gets exactly the keys you chose, and prod stays invisible.

Why not Doppler or Infisical?

Fair question — they're genuinely good tools, and they also do runtime injection. The honest difference is scope and pricing, not security:

• They're full platforms: dozens of integrations, dynamic secrets, rotation, PKI, SSH, audit tiers. A lot to stand up and configure.
• They're priced per seat, which climbs fast for a small team.

If what you want is narrow — "get my secrets off disk and scope what my agents can read" — that's a whole platform to adopt for one job. Klavex's bet is the opposite: it does that one thing, you're set up in one command, AI agents are free and unlimited, and team pricing is flat (it never scales per seat). The day you need dynamic secrets or PKI, Doppler and Infisical are exactly where you should go.

What this does not do

To be precise about the threat model, because it matters: this is not a sandbox. Anything running as your user can still read the process environment at runtime — including, in principle, a sufficiently determined tool. What Klavex removes is the plaintext file that sits on disk forever, readable at any time, by anything. That's the realistic, high-frequency exposure, and it's the one worth closing.

---

It's live, free for solo use: klavex.dev. If you work with coding agents daily, I'd genuinely like to know whether this matches a problem you've hit — or whether I'm the only one who kept watching Claude read my keys.