The .env Setup That Keeps Claude Code From Leaking Your Secrets (Full Config Included) cover

The .env Setup That Keeps Claude Code From Leaking Your Secrets (Full Config Included)

darkzodchi avatar

darkzodchi · @zodchiii · Apr 30

View original post

Claude Code reads your .env files the moment it opens your project.

Your API keys, database passwords, Stripe tokens, everything in .env file is loaded into memory and can end up in conversation logs sent to Anthropic's servers.

The only thing that actually blocks access is one line in settings.json, which most people don't have it and don't know about.

Here's the full security config 👇

Before we dive in, I share daily notes on AI & vibe coding in my Telegram channel: https://t.me/zodchixquant🧠

Why CLAUDE.md rules don't protect you

Most people add "never read .env files" to their CLAUDE.md and assume they're safe (they're not)

CLAUDE.md is a suggestion. Claude follows it most of the time, but under pressure (complex tasks, long context, ambiguous instructions) it can and does ignore advisory rules.

A GitHub issue from April 2026 confirmed: Claude reads and echoes .env contents into the conversation even when CLAUDE.md explicitly prohibits it.

The only reliable protection is a deny rule in settings.json. Deny rules are enforced at the system level before Claude even sees the file.

The difference between "please don't read this" and "you physically cannot read this."

The 3 ways your secrets leak

It's not just about Claude reading .env directly. There are three paths:

1. Direct file read. Claude scans your project, opens .env, and the contents become part of the conversation context. This is the obvious one and the easiest to block with deny rules.

2. Runtime output capture. Claude runs your tests or starts your app. A failed HTTP request logs the full Authorization: Bearer sk-live-abc123... header. A database timeout dumps the connection string with the password. Claude captures all command output. Your secrets are now in the conversation, even though Claude never opened .env.

3. Grep and search tools. Claude uses grep to search your codebase for a function name. The search hits a config file containing credentials. The grep output includes the matched lines with your secrets visible.

Most people only protect against path 1. Paths 2 and 3 are where the real damage happens.

The deny rules that actually work

Add these to ~/.claude/settings.json for global protection across every project:

This blocks Claude from reading or writing any .env file, PEM keys, SSH keys, AWS configs, credential files, and npm/PyPI tokens. The ** wildcard means it applies to every subdirectory in your project.

Blocking runtime leaks

Deny rules stop direct file reads but not runtime output. For that, use test-specific .env files with dummy values:

Point your test framework at .env.test instead of .env. Now when Claude runs your tests and captures output, the only keys visible are dummies.

The pre-commit hook that catches everything

Even with deny rules, mistakes happen. Add a git pre-commit hook that scans for secrets before any commit reaches your repo:

Make it executable: chmod +x .git/hooks/pre-commit

This catches Anthropic API keys, Stripe keys, GitHub tokens, AWS keys, Slack tokens, SendGrid keys, JWTs, and private key material. If any of these show up in a staged file, the commit is blocked.

Container isolation (the nuclear option)

For maximum security, run Claude Code inside a container where .env files literally don't exist:

From Claude's perspective, .env is an empty file. Your secrets never enter the container filesystem. This is overkill for most projects but essential for client work with production credentials.

The full security config (copy-paste ready)

Complete ~/.claude/settings.json with all security protections:

This is the settings.json from my previous article plus every security rule from this one. Allow rules for daily workflow, deny rules for secrets and dangerous operations. One file, full protection.

The checklist

Before your next Claude Code session:

1. Do you have deny rules for .env files in settings.json?

2. Do your tests use .env.test with dummy values?

3. Is there a pre-commit hook scanning for secret patterns?

4. Are production credentials stored in a vault, not plaintext files?

5. Is .env in your .gitignore?

6. Are .env files outside your project directory for extra safety?

If you checked all 6, your secrets are as protected as they can be. If you checked 0, you're one ambiguous Claude prompt away from your API keys appearing in a conversation log on Anthropic's servers.

I share daily notes on AI, finance, and vibe coding in my Telegram channel: https://t.me/zodchixquant

Thanks for reading🙏🏼