Layer 1 — Permission deny rules (weakest, but do it anyway)
Put this in ~/.claude/settings.json (applies to all projects) or .claude/settings.json
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.)",
"Read(./secrets/)",
"Read(~/.ssh/)",
"Bash(cat .env)",
"Bash(cat ./.env*)"
]
}
}
Layer 2 — Sandboxing
This is the strongest single-machine control because it's enforced at the OS level, not by Claude's judgment. With sandboxing enabled, cat .env fails at the OS level, regardless of whether your permission rules catch it.
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"filesystem": {
"denyRead": ["./.env", "./.env.*", "/.aws/credentials", "/.ssh"]
}
}
}
Enable it with the /sandbox command. On macOS it works out of the box using Seatbelt. On Linux and WSL2, install bubblewrap and socat first. One gotcha worth noting: if you use the sandbox, also add ~/.aws/credentials and ~/.ssh/ to denyRead; the default sandbox read policy allows them. A bonus is fewer prompts — when sandboxing is enabled with the default autoAllowBashIfSandboxed: true, sandboxed Bash commands run without prompting; the sandbox boundary replaces the per-command permission prompt.
Layer 3 — PreToolUse hook (the power-user belt-and-suspenders)
Hooks are the most reliable application-level block because a hook that exits with code 2 stops the tool call before permission rules are evaluated. The documented pattern is to allow Bash broadly and enforce a blocklist in a PreToolUse hook.
And depends of your OS you can enforce things like Keychain or envchain,
Layer 1 — Permission deny rules (weakest, but do it anyway)
Put this in ~/.claude/settings.json (applies to all projects) or .claude/settings.json
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.)",
"Read(./secrets/)",
"Read(~/.ssh/)",
"Bash(cat .env)",
"Bash(cat ./.env*)"
]
}
}
Layer 2 — Sandboxing
This is the strongest single-machine control because it's enforced at the OS level, not by Claude's judgment. With sandboxing enabled, cat .env fails at the OS level, regardless of whether your permission rules catch it.
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"filesystem": {
"denyRead": ["./.env", "./.env.*", "
/.aws/credentials", "/.ssh"]}
}
}
Enable it with the /sandbox command. On macOS it works out of the box using Seatbelt. On Linux and WSL2, install bubblewrap and socat first. One gotcha worth noting: if you use the sandbox, also add ~/.aws/credentials and ~/.ssh/ to denyRead; the default sandbox read policy allows them. A bonus is fewer prompts — when sandboxing is enabled with the default autoAllowBashIfSandboxed: true, sandboxed Bash commands run without prompting; the sandbox boundary replaces the per-command permission prompt.
Layer 3 — PreToolUse hook (the power-user belt-and-suspenders)
Hooks are the most reliable application-level block because a hook that exits with code 2 stops the tool call before permission rules are evaluated. The documented pattern is to allow Bash broadly and enforce a blocklist in a PreToolUse hook.
And depends of your OS you can enforce things like Keychain or envchain,