Your coding agent can read your .env. Two settings fix that.

If you run a coding agent in a repo that holds real API keys, assume it can read them. Claude Code's file tools can open any file in your project unless a rule says otherwise. And if you made a .claudeignore file to keep secrets out, Anthropic's docs are blunt: it has no effect. Move its entries into Read deny rules.

Step 1: deny rules. Add this to .claude/settings.json in your project (it's shared with anyone who clones the repo), or to ~/.claude/settings.json for yourself:

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

That's the shape of Anthropic's own example. Deny always wins: rules are checked deny first, then ask, then allow, and an allow rule can't carve an exception out of a deny. A Read deny also stops Claude's Edit and Write tools on the same path, including creating a new file there (Claude Code v2.1.208 or later for edits, v2.1.228 or later for writes).

The gap. The docs say these rules cover Claude's built-in file tools, shell commands Claude Code recognizes such as cat, head, tail, sed and tee, and redirections like < file. They do not cover a command that reads files without naming them, such as grep -r pattern ., or a Python or Node script that opens the file itself. The same goes for shell deny rules: Bash(curl *) doesn't stop /usr/bin/curl or sh -c 'curl …'.

Step 2: the sandbox. For a block the operating system enforces on every process a command starts, turn on the sandbox. It's off by default. Run /sandbox in a session, or add:

• "sandbox": { "enabled": true, "allowUnsandboxedCommands": false, "filesystem": { "denyRead": ["./.env", "./.env.*", "./secrets"] } }

In project settings, a ./ path in the sandbox means the project root. In user settings it means ~/.claude, so use ~/ or absolute paths there. Note that the sandbox and permission rules write paths differently: in permission rules a single leading / is relative to the settings file's location (the project root, for project settings), while in sandbox paths it means the filesystem root.

Why allowUnsandboxedCommands: false. When a command fails inside the sandbox, Claude can retry it outside with a dangerouslyDisableSandbox parameter. That retry goes through the normal permission flow, but an allow rule that matches the command also approves the retry with no prompt. Setting allowUnsandboxedCommands to false makes Claude Code ignore the parameter.

Tokens in your environment, too. The sandbox's credentials block can unset variables such as GITHUB_TOKEN and NPM_TOKEN before each sandboxed command runs, with entries like { "name": "NPM_TOKEN", "mode": "deny" } under credentials.envVars.

Who it's for: anyone running Claude Code, especially in auto or allow-heavy setups, in a project with a .env, a secrets/ folder or cloud credentials on the same machine.

The catches. You need both layers: the sandbox covers shell commands only, while Claude's file tools, MCP servers and hooks run outside it. The sandbox runs on macOS, Linux and WSL2; on native Windows, commands run unsandboxed, and Linux needs bubblewrap and socat installed. Neither layer stops you from committing a key. The strongest fix is still the boring one: keep production secrets off the machine your agent works on, and give it a development key you can revoke.

What we did and didn't do: MODEL did not run these settings for this piece. Everything above comes from Anthropic's Claude Code documentation, read on October 18, 2026, and linked below. This is not sponsored and has no affiliate links.

MODEL Editors