Claude Code Permissions: Trust Levels, Allow Lists, and Safe Defaults

Claude Code asks for permission before taking actions that affect your system. Understanding how that permission model works lets you configure it to match your risk tolerance — from "ask me before every file write" to "run fully autonomously."

How permissions work

Every tool call Claude Code makes falls into one of three permission buckets:

1. Always allowed — low-risk read operations (Read, Grep, Glob) that never prompt.

2. Prompt on first use (default) — higher-risk operations (Edit, Write, Bash) where Claude asks for your approval the first time in each session.

3. Always denied — tools or patterns you've explicitly blocked in settings. Claude cannot call these regardless of context.

The permission model is configured in your settings.json. There are two levels:

• User-level (~/.claude/settings.json): applies to all projects
• Project-level (.claude/settings.json): applies only when running from that directory, overrides user-level for the tools it specifies

Permission modes

You set the permission mode via the --permission-mode flag or in settings.

When to use bypass: automated scripts, CI/CD pipelines where you've reviewed the task in advance. Never use it when exploring an unfamiliar codebase or running an unknown task.

Configuring allowed and disallowed tools

Allow specific tools only

Restrict Claude to a whitelist of tools. Any tool not in the list is implicitly denied:

{
  "allowedTools": ["Read", "Grep", "Glob"]
}

This creates a read-only Claude Code — it can explore and search but cannot modify files or run commands. Useful for code review and analysis tasks.

Disallow specific tools

Block specific tools while keeping all others available:

{
  "disabledTools": ["Bash", "WebFetch", "WebSearch"]
}

This keeps file editing but prevents shell execution and web requests. Good for offline-only workflows.

Common safe configurations

Read-only mode (safe for exploring unfamiliar codebases):

{
  "allowedTools": ["Read", "Grep", "Glob", "Agent"]
}

No shell execution (file edits only):

{
  "disabledTools": ["Bash"]
}

No web access (air-gapped or policy-restricted environments):

{
  "disabledTools": ["WebFetch", "WebSearch"]
}

Per-project permissions

For a project with different risk tolerance than your default, use .claude/settings.json in the project root. This file is typically committed to version control so the entire team shares the same settings.

Example: a production infrastructure project where shell execution requires explicit approval:

{
  "permissions": {
    "allow": [],
    "deny": [
      "Bash(git push*)",
      "Bash(kubectl*)",
      "Bash(terraform apply*)"
    ]
  }
}

This uses pattern-based deny rules: Bash(pattern) blocks bash commands matching the pattern. Claude cannot run git push, kubectl commands, or terraform apply without triggering an error message.

Pattern-based rules

Pattern rules match against the tool input, not just the tool name.

Syntax: ToolName(pattern) where pattern is a glob-style match against the command input.

{
  "permissions": {
    "deny": [
      "Bash(rm -rf*)",
      "Bash(* --force*)",
      "Edit(*/.env*)",
      "Write(*secrets*)"
    ]
  }
}

This blocks:

• Any rm -rf command
• Any command with --force
• Editing any .env file
• Writing any file with "secrets" in the path

Note: the patterns are case-sensitive and match against the full command string for Bash, or the full file path for file-operation tools.

The full settings.json reference

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run build)"
    ],
    "deny": [
      "Bash(git push*)",
      "Bash(rm -rf*)"
    ]
  },
  "allowedTools": [],
  "disabledTools": [],
  "hooks": {
    "PreToolUse": [],
    "PostToolUse": []
  }
}

permissions.allow: specific patterns that are always permitted without a prompt, even if they would normally require approval.

permissions.deny: patterns that are always blocked. Takes precedence over allow.

allowedTools: if non-empty, only these tools are available. Everything else is blocked.

disabledTools: tools in this list are blocked regardless of other settings.

Trust levels explained

When you approve a tool call during a session, Claude Code remembers the approval at different levels:

"Always allow" and "always deny" responses write to your project-level .claude/settings.json if it exists, or create one. Review these accumulating entries periodically — a "yes always" given hastily can create a permanent permission you didn't intend.

Auto mode and autonomous execution

When you invoke /auto or start a session with a task that requires unattended execution, you can pre-authorize the tools Claude will need rather than accepting all prompts:

In settings.json before starting the session:

{
  "permissions": {
    "allow": [
      "Bash(npm*)",
      "Bash(git add*)",
      "Bash(git commit*)"
    ]
  }
}

This pre-authorizes npm commands and safe git operations without enabling a full bypass.

What each tool can do (risk reference)

Understanding what each tool is capable of helps you set the right defaults.

Bash is the highest-risk tool — it has the same access to your system as you do. A Bash command can delete files, push code, modify databases, and make network requests. Pattern-based deny rules on Bash are the most important safety measure.

Common permission mistakes

Setting bypassPermissions permanently in ~/.claude/settings.json: this turns off all safety prompts for every project. Only set this for specific automated workflows, not as a global default.

Forgetting to commit .claude/settings.json: your project team shares your safety rules only if you commit the file. Add it to version control with the rest of your project config.

Too-broad allow rules: Bash(*) in allow means every bash command is approved without prompting — equivalent to full bypass. Be specific: Bash(npm test) not Bash(*).

Not reviewing accumulated always allow entries: over time, quickly-granted "always allow" approvals accumulate in settings.json. Review and trim them quarterly.

FAQ

Does Claude Code need root/sudo access? No. Claude Code runs as the current user. If it attempts a command requiring sudo, it will be blocked by the OS, not by the permission system. Never run Claude Code as root.

Can Claude Code access files outside my working directory? Yes — Claude Code's Read and Bash tools can access any path the current user can access. Use .gitignore-style patterns in hooks to block reads of sensitive paths if needed.

Can I share settings between team members? Yes — commit .claude/settings.json to your repository. All team members who use Claude Code in that project will use the same settings. User-level ~/.claude/settings.json is personal.

What happens when Claude tries a denied action? The tool call is blocked and Claude receives an error message explaining what was denied. Claude will typically acknowledge the restriction and ask you how to proceed differently.

Is there an audit log of what Claude did? Not built-in, but the Hooks system (see Claude Code Hooks guide) lets you log every tool call to a file with a PreToolUse hook on "*".

Sources

1. Claude Code permissions documentation — April 2026
2. Claude Code security guide — April 2026