Answer target
Claude Code just read my .env file. What should I do?
Updated June 25, 2026
Short answer
Treat every credential in that file as exposed. Rotate each key at its provider, starting with billable and production ones, check usage for surprises, then move the replacements out of readable files so the next agent session resolves keys at runtime instead of reading them from disk.
What to do now
Work from the file, not from memory: every key that was in the .env when the agent read it is now in session context and possibly in transcripts or logs. Rotate rather than wondering.
- List every credential in the file the agent read.
- Rotate billable and production keys first (Stripe live, OpenAI, database URLs), then the rest.
- Check each provider's usage and billing pages for activity you do not recognize.
- Search the repo and recent commits for the same values in case they were written anywhere.
Better pattern
Deny rules and ignore files are advisory, and agents routinely route around them while being helpful. The durable fix is for real values not to exist in readable files at all: names in config, values resolved at runtime under a per-project grant.
Avoid
Avoid relying on .claudeignore or permission deny rules alone, scolding the agent and continuing with the same file, rotating only the one key you saw on screen, or moving the .env somewhere else on disk that the agent can also read.
Example
If Claude Code read a .env holding a Stripe test key, an OpenAI key, and a database URL while debugging config, rotate all three, store the replacements once, and give the project's agent a grant to just the secrets that project needs.
Give an agent safe access in minutes
- 1.Store the credential.
- 2.Create a named agent identity.
- 3.Grant the access it needs.
- 4.Resolve it at runtime.
- 5.Review the audit entry.
No card required.
Why agents keep reading .env files
Coding agents read configuration because configuration explains failures. When a build breaks or an API call 401s, the most helpful-looking move is to inspect the environment, and a .env file is the first place to look. Ignore rules reduce how often this happens; they do not make the file unreadable, and one temp-file copy or shell echo is enough to defeat them.
What 'exposed' actually means here
Reading the file put its contents into the model's context for that session, and potentially into local transcripts, logs, or anything the session wrote. That does not mean someone malicious has your keys. It means you can no longer prove they are contained, and rotation is cheaper than proof.
The setup where this cannot recur
Keep the .env for shape, not values: placeholder names only. Real values live in one place outside the repo, granted per project to a named agent identity, resolved at the moment a command runs, with every access logged. The agent can still do the work; there is simply nothing sensitive left on disk to read.
Reading this because it just happened to you?
ScopeHold gives every key one home: paste it once, grant it to your coding agents per project, see everything they touched, and revoke in one click. Free tier, five-minute setup, no card.
Fix it in 5 minutesPractical workflow
- 1Inventory the fileList every credential that was in the .env at the moment it was read.
- 2Rotate by blast radiusRotate billable and production keys first, then development keys. Update the systems that legitimately use them.
- 3Check for spreadReview provider usage pages and search the repo, commits, and shell history for the old values.
- 4Empty the .envReplace real values with placeholders and move the replacements to runtime resolution under a per-project grant.
Real keys in .env vs Runtime resolution
Frequently asked questions
Do I really have to rotate every key in the file?
If the file was read into the session, its full contents were exposed together. Rotating only the key you saw discussed leaves the rest in an unprovable state. Rotate the billable and production ones without exception; use judgment on scratch keys with no blast radius.
Doesn't .claudeignore or a deny rule fix this?
They help and are worth setting, but they are advisory controls inside a tool that is trying to be helpful. Public issue trackers document cases where agents read denied files via indirect routes. Treat ignore rules as a seatbelt, not as the reason nothing sensitive lives in readable files.
Should I stop using Claude Code on this project?
That is usually an overcorrection. The workable fix is to keep using the agent while removing raw values from anything it can read: placeholders in the repo, real values resolved at runtime under a scoped, revocable, logged grant.
Want the key clean-up checklist?
Leave your email and Alan — the founder — will personally send you the exact rotate-isolate-grant steps from these guides. He might also ask you one question about your setup. No list, no spam.
Where ScopeHold fits
ScopeHold is the runtime-resolution side of this recovery: store each replacement once, grant it to the project's agent, and keep real values out of every file the agent can read, with a log of each access.