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

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 False Sense of Security: Why CLAUDE.md Won't Save You

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."

---

It's Not Just One Leak — It's Three

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:[e-mail]/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.

---

The Fix That Actually Works: Hard Deny Rules

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.

---

Solving Leak #2: The Test Environment Trick

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.

---

Solving Leak #3: The Pre-Commit Safety Net

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.

---

The Nuclear Option: Container Isolation

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.

---

The Full Config: Copy, Paste, Done

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.

---

The Decision Matrix

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)

---

Before You Close This Tab: The 6-Point Check

Run through these right now, not after your next session:

1. ~/.claude/settings.json exists and has deny rules for .env*, *.pem, *.key, and secrets/**
2. .env.test exists with placeholder values for every key your test suite touches
3. .git/hooks/pre-commit is executable and scans for credential patterns
4. .env is in .gitignore — if it's not, fix that first
5. Production credentials live in a vault, not in a plaintext file anywhere near your project
6. .env files live outside the project directory when possible — one directory up means they're never inside a Claude scan boundary

If 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.

---

The Bottom Line

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.