The complete guide to claude code permissions auto

What Is Claude Code Permissions Auto?

Claude code permissions auto is the configuration system in Anthropic's Claude Code CLI that controls which tool calls — file reads, shell commands, MCP server actions — the agent executes without stopping to ask for human approval. It is governed primarily by the allow and deny arrays in your settings.json or settings.local.json files, and it determines the effective blast radius of every autonomous session you run.

When you launch Claude Code with --dangerously-skip-permissions or configure a broad Bash(*) allow rule, you are not just skipping friction — you are making an architectural decision about trust boundaries. That decision has consequences that compound the moment an untrusted input reaches your agent.

How the allow/deny arrays work

Claude Code evaluates each proposed tool call against the allow list first, then the deny list. A match in allow means the action proceeds silently. A match in deny blocks it outright. If neither list matches, the agent pauses and asks the user. The pattern syntax supports glob-style wildcards: Bash(git *) allows any git command, while Bash(*) allows every shell invocation. Specificity is your first line of defense.

Anthropic shipped the structured permissions model in the Claude Code 1.x release series (GA in early 2025), graduating it from the experimental autoApprove flag that appeared in the beta. The current schema is documented in the official Claude Code Security documentation alongside guidance on scoping rules to individual projects.

MCP server inheritance

MCP (Model Context Protocol) tools are a separate category. A Bash(*) allow rule does not automatically approve MCP tool calls — those are gated by their own entries in the permissions config. This is a common source of confusion: teams assume that because shell commands run freely, their MCP file-system or database tools will too. They don't, by default. Each MCP server needs explicit allow entries for its tools, or the agent will pause on every invocation. Getting this wrong in either direction either breaks your automation pipeline or silently widens your attack surface.

Why Claude Code Permissions Auto Matters in 2026

Prompt injection attacks against coding agents are no longer theoretical. The MITRE ATLAS framework catalogued AI-specific attack patterns starting in 2023, and by 2025 several public disclosures documented cases where malicious content embedded in files or web pages caused code agents to execute unintended shell commands. One referenced incident involved a repository README that instructed an LLM-based CI assistant to exfiltrate environment variables via a curl call — a direct exploitation of an overly broad Bash(*) allow rule.

The risk profile matters because most teams reach for broad permissions to reduce friction during development, then forget to tighten them before production automation. Anthropic's own documentation warns explicitly against using --dangerously-skip-permissions in networked or multi-user environments, but the flag persists in countless CI scripts and shared development containers.

The settings.json vs settings.local.json distinction

There is a meaningful operational difference between these two files. settings.json is typically committed to version control and represents team-wide defaults. settings.local.json is gitignored by default and holds per-developer overrides. Permissions defined in settings.local.json take precedence over the project-level settings.json. This means a developer can silently widen their local permissions without that change appearing in a code review. For security-conscious teams, auditing settings.local.json across developer machines requires out-of-band tooling — it won't show up in your repo diff.

Auto-approve scope and CI environments

In CI, there is no human in the loop to catch a suspicious tool call. That makes the allow configuration in your CI-specific settings.json a security boundary, not just a convenience setting. Scoping CI permissions to exactly the tools your pipeline needs — and nothing else — is the practical definition of least-privilege for agentic workflows.

How to Approach Claude Code Permissions Auto

Start from deny-all and add only what you need. This sounds obvious, but the default Claude Code installation is permissive by design because it is built for developer productivity. When you are moving from "developer laptop experimentation" to "automated agent running in CI against production repos," you need to reverse that default posture deliberately.

Auditing your current auto-approve rules

Run claude config list to dump your current permission state. Cross-reference every entry in your allow array against what your actual workflow requires. For each rule, ask: what is the worst-case action this pattern permits? Bash(npm *) sounds scoped, but it permits npm publish if you haven't also added a deny rule for it. Write(**) permits overwriting any file in the project tree, including CI configuration and secrets references.

If you are using MCP servers, enumerate every tool each server exposes and add only the specific tool names you intend to auto-approve. MCP tool names follow the pattern mcp__serverName__toolName in the allow array. Wildcard MCP grants like mcp__filesystem__* should be treated with the same caution as Bash(*).

Project-scoped vs global permissions

Claude Code supports permissions at three scopes: global user settings (~/.claude/settings.json), project settings (.claude/settings.json), and local overrides (.claude/settings.local.json). Prefer project-scoped permissions for anything beyond basic read-only file access. Global permissions follow you into every project you open, including unfamiliar repos you clone to investigate an issue. A broad global allow rule is one cloned-malicious-repo away from being a problem.

Best Claude Code Permissions Auto Tools and Solutions

The built-in tooling gets you most of the way there if you use it correctly. Beyond that, the ecosystem has started producing purpose-built solutions.

Native configuration controls

The --allowedTools and --disallowedTools CLI flags let you override your settings.json for a single session without modifying any file on disk. This is useful for one-off tasks where you want elevated permissions that shouldn't persist. The flags accept comma-separated tool patterns and support the same glob syntax as the config file. Using them explicitly in scripts is preferable to modifying shared config files, because the scope is obvious from the command line invocation.

Security-focused platforms

For teams running Claude Code at scale, a dedicated security layer adds visibility that the native config system doesn't provide. At CLaude coe, we built our platform specifically around this problem: auditing what Claude Code's auto-approve rules actually permit, detecting overly broad patterns before they reach production, and enforcing organizational permission policies across all developer machines — not just the ones that committed their settings.json. You can see the full approach in the Claude Code Security product overview.

Policy-as-code approaches

Several teams have started treating their .claude/settings.json as a policy file managed through the same review process as infrastructure code. Requiring pull request approval for any change to the allow array, and running a linter that flags wildcard patterns, catches configuration drift before it becomes a security incident. This is lightweight to implement and the organizational friction is low because the file is already in version control.

Claude Code Permissions Auto Best Practices

These are the rules that consistently show up in post-mortems when auto-approve configurations go wrong.

• Never use Bash(*) in CI. Enumerate the exact commands your pipeline needs. The extra configuration time is negligible compared to the risk of arbitrary shell execution in an automated context.

  • Treat --dangerously-skip-permissions as a code smell. If it appears in a script, it needs a comment explaining why and a ticket to replace it with scoped rules.
  • Separate read and write permissions explicitly. Read(**) and Write(**) are different risk levels. Agents frequently need broad read access but should have narrow write access scoped to specific directories.
  • Rotate your settings.local.json audit. Because this file is gitignored, it requires an explicit process — checklist, onboarding doc, or tooling — to keep it in scope for security reviews.
  • Test your deny rules. Add a canary: a rule that should be blocked, with a test that confirms the block fires. Configuration bugs in deny lists are silent by nature.

For teams working through the full hardening process, the Claude Code Security blog covers specific scenarios including MCP server configuration, prompt injection mitigations, and multi-agent permission delegation patterns.

Frequently Asked Questions

What is claude code permissions auto?

Claude code permissions auto is the system that determines which Claude Code tool calls execute without human confirmation. It is configured via the allow and deny arrays in settings.json or settings.local.json, and it controls the full range of agent actions: shell commands, file reads and writes, and MCP server tool invocations.

What is the safest Claude Code permissions auto setting?

The safest baseline is an empty allow array with no wildcard patterns, which forces human confirmation on every tool call. For practical use, the safest functional configuration depends on your workflow, but the principle is the same: enumerate only the exact tool patterns you need, avoid wildcards where specific patterns are possible, and keep write permissions narrower than read permissions. Never use --dangerously-skip-permissions in networked or automated environments.

How do I audit my current auto-approve rules?

Run claude config list to see your active configuration. Also check three file locations: ~/.claude/settings.json (global), .claude/settings.json in your project root (project-level), and .claude/settings.local.json (local overrides, gitignored). The local override file takes precedence and is frequently overlooked in audits because it doesn't appear in version control. For organization-wide auditing across developer machines, you need out-of-band tooling — native Claude Code config management doesn't aggregate across users.

Does Bash(*) auto-approve MCP tool calls?

No. Bash(*) approves shell command invocations only. MCP server tools are a separate tool class and require their own explicit allow entries in the format mcp__serverName__toolName or with a wildcard like mcp__serverName__*. Teams migrating from shell-heavy workflows to MCP-based integrations often discover this when their MCP tools start pausing for approval even though their shell commands run freely.

How does settings.local.json differ from settings.json?

settings.json is committed to version control and represents shared project defaults visible to your whole team. settings.local.json is gitignored and holds per-developer overrides that take precedence over the project file. The practical implication: a developer can expand their local permissions without code review visibility. For security-sensitive projects, you should either prohibit settings.local.json in your developer guidelines, or implement a process to audit it explicitly outside of normal code review.

How to get started with claude code permissions auto?

Start by running claude config list on an existing project to understand what you currently have. Then review Anthropic's settings reference and map your actual workflow needs to specific tool patterns. Replace any wildcards with exact matches where possible, scope write permissions to specific directories, and commit your settings.json with a pull request so the initial configuration goes through review. From there, treat any change to the allow array with the same scrutiny as a change to your infrastructure configuration.

What are common claude code permissions auto mistakes to avoid?

The most consequential mistakes: using Bash(*) in CI pipelines, committing settings.local.json with elevated permissions into shared environments, forgetting that --dangerously-skip-permissions in a script persists across every use of that script, and failing to audit MCP server tool permissions separately from shell permissions. A subtler mistake is adding allow rules reactively whenever the agent pauses — over time, this produces a permissions config that reflects every friction point in your workflow rather than a deliberate security posture.