Can Claude Code Read Your .env?
Yes. Here's How to Keep Keys Out

Yes, Claude Code can read your .env file

Claude Code reads files in your project without asking, and a .env file is a file. Anything in it, from a Stripe key to a database password, can end up in the conversation. That is not a bug; it is how a coding agent works. The question is what you put in its way.

We tested the common answer, a deny rule, on Claude Code version 2.1.296 on 2026-10-11. Two identical folders each held a dummy .env with a made-up token. One folder had a deny rule; one did not. Then we asked Claude to show the file three ways in each folder:

Add the deny rules anyway

They stop the common, accidental reads, which is most of the risk. Put this in .claude/settings.json at the root of your project and commit it, so everyone who opens the project gets the same rules:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

• .claudeignore does nothing. The docs say that if your project has one, “it has no effect, so move its entries into Read deny rules.”
• .gitignore is not a permission. It keeps the file out of git. It does not stop Claude reading it.
• Bare names match at any depth. Per the docs, Read(.env) and Read(**/.env) are equivalent and cover every .env under the project folder.

Move the real values into a password manager

The durable fix is a .env that holds references, not values. The real key lives in your password manager and is handed to your app only while it runs. Two common ways to do it:

Option A: 1Password CLI

1Password's CLI documentation describes a .env written as secret references, run through op run, with “the secrets made available as environment variables only for the duration of the process.” If Claude reads this file, it learns where your key lives, not what it is.

STRIPE_API_KEY="op://dev/stripe/restricted_key"
DATABASE_URL="op://dev/postgres/url"

op run --env-file=.env -- npm run dev

Option B: Bitwarden CLI (free)

Bitwarden's CLI documentation says unlocking the vault creates a session key, and that “Session keys are valid until invalidated using bw lock or bw logout.” Do the unlock in your own terminal, so your master password is typed into Bitwarden and never into a chat:

bw login                                   # once
export BW_SESSION="$(bw unlock --raw)"     # asks for your master password; --raw prints only the session key

# start your app with the key injected for that one process
STRIPE_API_KEY="$(bw get password 'Stripe restricted key')" npm run dev

bw lock                                    # when you are done

Decide whether Claude may run commands that need keys

There are two honest setups. Pick one and write it down in settings, not just in CLAUDE.md, because a sentence in CLAUDE.md is a request and a settings rule is a block.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(op *)",
      "Bash(bw *)"
    ]
  }
}

The docs are clear that a shell rule matches the command as written: a deny rule “doesn't match the same program by path or inside sh -c.” For a guarantee that holds against any command, Claude Code's sandbox enforces file and network limits at the operating-system level.

Rotate anything that sat in a plain .env

If a real key has been in a plain .env in a folder you opened with Claude Code, assume it may have been read, and rotate it once the steps above are in place. It takes a few minutes in most dashboards, and it is the only step that fixes the past rather than the future.

• Use restricted keys. Most payment and cloud providers let you create a key that can only do what the project needs. A leaked read-only key is a much smaller problem.
• Use test keys on your laptop. Keep live keys for the server that needs them.
• Check your history. If .env was ever committed, the value is in git history even after you delete the file. Rotate it.

Frequently Asked Questions