Claude Code Is Reading Your .env File Right Now — And You Probably Don't Know It

Claude Code automatically scans project files, including `.env` files containing sensitive credentials like database passwords and API keys, as soon as a project is opened. A GitHub issue confirmed that Claude reads and echoes `.env` contents into conversation context even when explicitly told not to in `CLAUDE.md`, because these advisory rules are suggestions rather than hard constraints. The only effective protection is adding deny rules in `settings.json`, which physically prevent Claude from reading files before they enter the conversation context.

Every time you open a project with Claude Code, it starts scanning your files. Your source code. Your configs. Your .env file. By the time you type your first prompt, Claude already knows your database password, your Supabase service key, and that Twilio auth token you've been meaning to rotate for three months. And depending on your setup, all of that might be sitting in Anthropic's conversation logs right now. I know this sounds alarmist. But this isn't theoretical — a GitHub issue filed in April 2026 confirmed that Claude reads and echoes .env contents into conversation context, even when you've explicitly told it not to in your CLAUDE.md . That was the moment I stopped trusting advisory rules and started understanding how Claude's permission system actually works. Here's what I found — and more importantly, how to actually fix it. The first thing most developers do is open their CLAUDE.md and write something like: "Never read .env files. Never expose API keys." Reasonable. Logical. And almost completely useless as a security control. Here's the uncomfortable truth: CLAUDE.md is a suggestion, not a constraint. Claude follows it under normal conditions — short context windows, simple tasks, clear intent. But push the model into a complex debugging session with a long conversation history and an ambiguous instruction, and those advisory rules start slipping. The model isn't being malicious. It's just prioritizing. When the system prompt says "don't read .env " but the task at hand requires understanding why a database connection is failing, the task usually wins. The only thing that actually enforces a hard boundary is a deny rule in settings.json . Deny rules are evaluated before Claude even attempts the operation. The file never opens. The contents never enter the context. It's the difference between "please don't" and "you physically cannot." Most developers, once they hear about this problem, go add a deny rule for .env files and call it done. That blocks one of the three ways your secrets get exposed. Leak 1: Direct file read — This is the obvious one. Claude scans your project directory, opens .env , and the keys become part of the conversation. Deny rules stop this completely. Leak 2: Runtime output capture — This is the sneaky one. Claude runs your test suite. One test makes an HTTP request with an Authorization header. The request fails and the error log dumps the full header value — your live API key — into the terminal output. Claude captures all of that output. Your secret is now in the conversation, and Claude never needed to open a single file. Or imagine a database connection timing out. The error message includes the full connection string: postgres://admin:MyActualPassword123@prod-database.us-east-1.rds.amazonaws.com/appdatabase . Claude sees it. It's in context. Done. Leak 3: Search and grep — Claude uses grep to find where you defined a helper function. The search returns matches from a config file that happens to contain your Resend API key alongside the function definition. The matched lines show up in grep output. Claude reads it. You never suspected a thing. warning + Reality Check Most guides on this topic protect against Leak 1 only. Leaks 2 and 3 are where real credentials actually escape in production workflows. I'll show you how to handle all three. Open ~/.claude/settings.json — or create it if it doesn't exist. This is the global config that applies to every project you open with Claude Code. Add deny rules for every sensitive file pattern you want to block: { "permissions": { "deny": "Read /.env ", "Read /secrets/ ", "Read /credentials/ ", "Read /.ssh/ ", "Write /.env ", "Write /secrets/ ", "Write /credentials/ ", "Write /.ssh/ " } } The wildcard means these rules apply to every subdirectory, not just the project root. If you have a monorepo with a packages/api/.env.production , it's blocked. If your CI scripts live in tooling/scripts/.env.ci , it's blocked. Write rules matter too — you don't want Claude accidentally creating or overwriting .env files during a "let me set up your environment" task. Deny rules can't intercept runtime output — that's just text flowing through the terminal. The solution is to ensure Claude never runs code that has access to real credentials in the first place. Create a .env.test file that contains placeholder values for every key your app uses: .env.test — safe values for all automated tasks ANTHROPIC API KEY=sk-ant-test-placeholder-not-real SUPABASE URL=https://test-project.supabase.co SUPABASE SERVICE ROLE KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.test RESEND API KEY=re test placeholder 123456789 TWILIO ACCOUNT SID=ACtest00000000000000000000000000000 TWILIO AUTH TOKEN=test auth token placeholder value REDIS URL=redis://localhost:6379 Then point your test runner at .env.test instead of .env . For Python projects using pytest , add this to pytest.ini : pytest env files = .env.test For Node.js projects, load it explicitly in your test setup: // test/setup.js import { config } from 'dotenv' config { path: '.env.test', override: true } Now when Claude runs your test suite and a request fails with a logged header, the only key that shows up is sk-ant-test-placeholder-not-real . Harmless. Even with deny rules and test environments, the repo itself is the last line of defense. A pre-commit hook scans every staged file before it reaches git history — and git history is permanent in a way that conversations aren't. Create .git/hooks/pre-commit : /usr/bin/env bash Pre-commit hook: blocks commits that contain credential patterns set -euo pipefail SECRET PATTERNS= 'sk-ant-api' Anthropic production keys 're A-Za-z0-9 {20,}' Resend API keys 'eyJhbGciOiJIUzI1NiJ9' Supabase JWTs common header 'ACa 0-9a-f {32}' Twilio Account SIDs 'AKID A-Z0-9 {16}' Cloud access key IDs 'postgres:// ^@ +: ^@ +@' Postgres DSNs with embedded passwords 'mongodb\+srv:// ^@ +: ^@ +@' MongoDB Atlas URIs '-----BEGIN RSA|EC|OPENSSH PRIVATE KEY-----' BLOCKED FILENAMES= '.env' '.env.local' '.env.production' 'id rsa' 'id ed25519' ' .p12' ' .pfx' 'service-account.json' FOUND ISSUE=0 Check for secret patterns in staged diff for pattern in "${SECRET PATTERNS @ }"; do if git diff --cached --diff-filter=ACM -- . | grep -qE "^\+. ${pattern}"; then echo "❌ BLOCKED: Potential secret found matching pattern: ${pattern}" FOUND ISSUE=1 fi done Check for sensitive filenames being staged for filename in "${BLOCKED FILENAMES @ }"; do if git diff --cached --name-only | grep -qF "${filename}"; then echo "❌ BLOCKED: Sensitive file staged for commit: ${filename}" FOUND ISSUE=1 fi done if $FOUND ISSUE -eq 1 ; then echo "" echo "Remove the flagged content and try again." echo "If this is a false positive, use: git commit --no-verify" exit 1 fi echo "✅ Pre-commit security scan passed." exit 0 Make it executable: chmod +x .git/hooks/pre-commit This catches the patterns that matter for modern stacks: Anthropic keys, Resend, Supabase JWTs, Twilio, cloud IAM keys, embedded database passwords in connection strings, and private key material. If you hit a false positive on a test value, git commit --no-verify skips the hook — but that's a conscious override, not an accident. For client work or anything touching production credentials, there's a more drastic approach: don't let .env files exist inside Claude's environment at all. Replace .env with an empty file at mount time docker run \ -v "$ pwd :/workspace" \ -v /dev/null:/workspace/.env \ -v /dev/null:/workspace/.env.local \ -w /workspace \ your-dev-image From Claude's perspective, .env is an empty file. The deny rules still apply. The test environment still runs. But even if something went wrong at every other layer, there's nothing to leak because the file physically contains nothing. This is overkill for personal projects. It's the right call for anything where you're holding someone else's production database password. Here's the complete ~/.claude/settings.json that combines everything — allowing normal development operations while blocking secrets and dangerous commands: { "permissions": { "allow": "Read", "Glob", "Grep", "LS", "Edit", "MultiEdit", "Write src/ ", "Write tests/ ", "Write docs/ ", "Bash python -m pytest ", "Bash uv run ", "Bash poetry run ", "Bash npm run ", "Bash npx ", "Bash git status ", "Bash git diff ", "Bash git log ", "Bash git add ", "Bash git commit " , "deny": "Read /.env ", "Read /.dev.vars ", "Read / .pem ", "Read / .key ", "Read / .p12 ", "Read /secrets/ ", "Read /credentials/ ", "Read /.aws/ ", "Read /.ssh/ ", "Read /config/secrets.toml ", "Read /config/production.json ", "Read /.netrc ", "Read /.pypirc ", "Write /.env ", "Write /secrets/ ", "Write /.ssh/ ", "Write .github/workflows/ ", "Bash rm -rf ", "Bash sudo ", "Bash git push ", "Bash pip install --user ", "Bash curl | bash ", "Bash curl | sh ", "Bash wget -O- | sh " , "defaultMode": "acceptEdits" } } The allow list covers what you actually do day-to-day: reading code, making edits, running tests, checking git status. The deny list covers secrets, sensitive system directories, and shell patterns that could pipe remote code into execution. Your situation → What to do ───────────────────────────────────────────────────────────────── Personal projects, no production creds → deny rules in settings.json Team project with shared repo → deny rules + pre-commit hook Running Claude-generated tests often → deny rules + .env.test setup Client work / holding their credentials → All of the above + container isolation CI/CD pipeline with Claude integration → Vault AWS Secrets Manager, GCP Secret Manager Run through these right now, not after your next session: ~/.claude/settings.json exists and has deny rules for .env , .pem , .key , and secrets/ .env.test exists with placeholder values for every key your test suite touches.git/hooks/pre-commit is executable and scans for credential patterns.env is in .gitignore — if it's not, fix that first.env files live outside the project directory when possible — one directory up means they're never inside a Claude scan boundaryIf you checked all six: you're in better shape than 95% of Claude Code users. If you checked zero: you're one long debugging session away from your live credentials becoming part of a conversation log you can't delete. The deny rules take five minutes to set up. The pre-commit hook takes another five. That's ten minutes against an unlimited blast radius. Claude Code is genuinely useful. That's not in question. But "useful" and "safe by default" are different things, and right now it leans heavily toward the former. The tooling to make it safe exists — it's just not turned on out of the box. CLAUDE.md instructions feel like security because they're written with security intent. But they're conversation rules, not permission boundaries. One confused model state and they're gone. Deny rules in settings.json are a different category entirely. They're enforced at the system level, before the model sees anything. That's what a real boundary looks like. Set them up once. Run every future session knowing your secrets are actually safe.