Claude Code Security Settings: 9 Proven Steps [2026]

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.

📑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. Step 1 — Block Claude Code Access to Sensitive Files
5. Step 2 — Block Dangerous Commands
6. Step 3 — Enable Claude Code Sandbox Mode
7. Step 4 — Restrict Network Access
8. Step 5 — Disable Bypass Permissions
9. Step 6 — Strengthen Claude Code Security with Hooks
10. Step 7 — Audit Permissions Regularly
11. Step 8 — Isolate with Dev Containers
12. Step 9 — Enforce Policies with Managed Settings
13. Defense-in-Depth Checklist
14. FAQ — Claude Code Security
15. Conclusion

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.

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

{
  "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

{
  "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 Linux namespaces) to enforce filesystem and network restrictions at the kernel level — far harder to bypass than pattern-based deny rules. 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

{
  "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.

Filesystem Restrictions

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

{
  "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:

{
  "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

{
  "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.

{
  "disableBypassPermissionsMode": "disable"
}

Place this in your managed settings file to enforce it across your organization. Individual developers cannot override a managed setting, so this ensures no one on your team runs Claude Code in an unrestricted mode.

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:

{
  "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:

{
  "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.

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:

{
  "disableBypassPermissionsMode": "disable",
  "permissions": {
    "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.

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

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