Prevent Claude Code from accessing .env

Claude Code is a powerful tool. You give it access to your codebase, it reads files, runs commands, and helps you ship faster. But that same file access means it can, and sometimes will, read your .env file.

Your .env file contains API keys, database credentials, OAuth secrets, and more. You definitely don't want an AI model sending those to a remote API. Even if you trust the tool, reducing the blast radius of any accidental exposure is just good practice.

How to block it

Claude Code has a permissions system built into its settings file. You can explicitly deny read access to sensitive files by editing ~/.claude/settings.json:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(*.pem)",
      "Read(*.key)",
      "Read(~/.ssh/**)"
    ]
  }
}

This tells Claude Code to refuse any attempt to read those files, even if it decides it needs to on its own.

A few things to keep in mind:

• This list is not exhaustive. Every project is different. You may have secrets in config/secrets.yml, terraform.tfvars, or a custom config directory.
• Think about where your project stores sensitive values and add those paths to the deny list.
• The ~/.claude/settings.json file applies globally. You can also create a .claude/settings.json at the project level if you want per-project rules.

How to verify it works

Testing this correctly matters. Follow these steps carefully:

1. Create a brand new empty folder, separate from your real project.
2. Inside that folder, create a .env file with completely fake, dummy data. Something like:

API_KEY=dummy-value
SECRET=not-a-real-secret

3. Open Claude Code in that folder and explicitly ask it to read the .env file.
4. It should refuse. If it does, your deny rules are working.

Never test this on your real project with real credentials. Verify the block with a dummy project before trusting it with anything real.

What if Claude Code already read your .env?

Treat every key as compromised. Immediately:

• Rotate all secrets that were in the file — API keys, database passwords, OAuth tokens, everything.
• Revoke the old keys in the respective dashboards (AWS IAM, Stripe, GitHub, etc.).
• Check access logs if available to see whether any unexpected activity occurred.
• Update your .env with the new values after rotation.

It doesn't matter whether you think the exposure was harmless. Rotation is cheap. A breach is not. When in doubt, rotate.

Make it a habit

Add the deny rules to your ~/.claude/settings.json once, and every project benefits from them automatically. Think of it like .gitignore: you wouldn't commit your .env to a public repo, so don't let it be read by a tool that phones home either.