Solutions
Stop coding agents reading your .env file
You cannot reliably stop an agent from reading a file sitting in the project, so the fix is to stop the value being in the file: keep the secret in Vault and let the agent run the command that needs it, without the value ever entering its context.
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.
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. The .env file in your project no longer has to hold anything worth reading. Vault is part of Pro.
How it works
- 1Move each value out of .env and into Vault, where it lives on your Mac rather than in your project.
- 2Grant it to the one Thread that needs it. Every other Thread is denied by default, so an agent working elsewhere cannot request it.
- 3Have the agent run its command through Vault, for example: forkbench-secret exec STRIPE_KEY -- ./deploy.sh
- 4Optionally require Touch ID per use, so no command runs with that secret without your fingerprint.
- 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.