Stop Claude Code from reading your .env file

A .env file is just a file. An agent running in your terminal has the same filesystem access you do, so it can open one, and several popular agents load .env files they find without asking first. Claude Code has been reported to do exactly that, including where a .claudeignore or .gitignore entry should have prevented it (The Register, January 2026). Anthropic's own issue tracker shows the same pattern from the inside: open reports of Claude Code reading a .env file despite an explicit memory rule telling it not to, because a rule is an instruction the agent can also decide to ignore. The moment that happens the value is in the agent's context, which means it has been sent to the model provider, and it will sit in that conversation's history. GitGuardian's State of Secrets Sprawl 2026 found code written with an agent leaks credentials at roughly twice the rate of code written without one, and AI-service leaks up 81% year over year.

Ignore-file entries are the wrong tool here, because they are a request to the agent rather than a boundary around it, and the reports above are what that distinction looks like in practice. Forkbench does not change how your agent behaves either, since it runs the same binary you run today. What it changes is where the value can live. A secret you put in Vault reaches the command that needs it and never the agent, so there is nothing in the prompt, the command line or the transcript to leak. Tell that secret where it is allowed to be used and a copy sent anywhere else is refused rather than delivered, with the attempt on the record. You can require a Touch ID approval on every use, or grant a short standing window instead. Secrets never sync in the clear either: a second machine is admitted only by comparing a short code with one already enrolled, and removing a machine means what it had stops working. The .env file in your project no longer has to hold anything worth reading. Vault is free.

How it works

1. 1Move each value out of .env and into Vault, where it lives on your machine rather than in your project.
2. 2Grant it to the one Thread that needs it. Every other Thread is denied by default, so an agent working elsewhere cannot request it.
3. 3Have the agent run its command through Vault, for example: forkbench-secret exec STRIPE_KEY -- ./deploy.sh
4. 4Optionally require Touch ID per use, so no command runs with that secret without your fingerprint.
5. 5Rotate anything that was already in a .env an agent had open. Assume it reached the provider, because it did.

Straight about the guarantee: This closes accidental exposure, not deliberate exfiltration. An agent you authorise to run a command could still print what it was handed, and Forkbench does not police your filesystem: it governs what it holds, so a secret you leave in a project file is still readable by anything with your shell access.

Frequently asked

• How do I keep API keys away from an AI coding agent altogether?

  Stop the value being anywhere the agent can read. Put the secret in Vault, grant it to the one Thread that needs it, and have the agent run its command through Vault: forkbench-secret exec GITHUB_TOKEN -- gh pr create --fill. The agent gets the result, and the plaintext never appears in a prompt, a log, the chat history or the agent's own process environment. Vault is free.

• Will a .claudeignore or .gitignore entry stop it?

  Not reliably. Both are requests to the tool rather than boundaries around it, and the reports above are agents reading a .env despite exactly such a rule. A memory rule is an instruction an agent can also decide to ignore, which is why the fix is to move the value rather than to ask more firmly.

• What if an agent has already read my .env?

  Rotate every value in it, and assume each one reached the model provider, because it did the moment it entered the context. There is no way to retract a value from a conversation history. Then move what you rotate into Vault so the file has nothing worth reading next time.