The complete guide to claude code permissions list

The Complete Guide to Claude Code Permissions List

The Claude Code permissions list is the explicit set of tool calls, shell commands, and file operations that Claude Code is allowed — or required to ask about — before executing them in your environment.

That one sentence is the whole answer. Everything else in this article is about why that list matters, how to configure it correctly, and what breaks when you get it wrong. If you're deploying Claude Code in any professional context — a CI pipeline, a shared developer workstation, a production-adjacent environment — the permissions list is not optional reading.

What Is the Claude Code Permissions List?

Claude Code operates by issuing tool calls: reading files, running bash commands, calling external APIs, spawning subprocesses. By default, some of these require explicit user approval. Others run silently. The permissions list, configured primarily through settings.json and .claude/settings.json, is how you control which category each tool call falls into.

There are two core lists: allowedTools (tools that run without a prompt) and blockedTools (tools that are never permitted). A third mechanism, permissions.ask, covers tools that require interactive confirmation. These settings can live at the user level (~/.claude/settings.json) or at the project level (.claude/settings.json inside a repo), and project-level settings override user-level ones where they conflict.

Tool names in the list use a specific format: Bash, Read, Write, Edit, WebSearch, mcp__servername__toolname for MCP-sourced tools. Glob patterns like Bash(git *) let you permit only a subset of a tool's invocations — for example, allowing all read-only git commands without permitting git push or git reset --hard.

Why the Claude Code Permissions List Matters in 2026

The attack surface for AI coding assistants grew materially in 2025. Prompt injection via malicious repository content — README files, inline comments, crafted package names — became a documented, repeatable technique. In their 2024 research paper "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications" (Greshake et al., arXiv:2302.12173), researchers demonstrated that indirect prompt injection could redirect LLM tool use against a user's environment. That research predates Claude Code, but the attack class applies directly to any agent that reads untrusted content and executes tool calls.

The GitHub Advisory Database recorded multiple MCP server vulnerabilities in 2025, including cases where third-party MCP servers requested excessive tool permissions that were silently inherited by any agent connecting to them. Without a tightly scoped Claude Code permissions list, a malicious or misconfigured MCP server can expand what Claude Code will execute on your behalf — without a single confirmation prompt.

There's also the insider risk angle. Developers working in monorepos with broad default permissions have reported accidental destructive operations: Claude Code issuing git reset --hard, overwriting uncommitted changes, or running database migrations against non-sandbox environments. These aren't theoretical. They're the kinds of incidents that end up in post-mortems.

For a fuller picture of the threat model, the Claude Code Security documentation covers prompt injection risks, MCP trust boundaries, and the permission model in detail.

How to Configure Your Claude Code Permissions List

Start with the principle of least privilege, applied specifically to your workflow. Don't block everything and whittle down — that leads to a frustrating loop of re-approving routine operations. Instead, identify the operations your workflow actually needs, and permit exactly those.

A typical read-heavy research workflow might permit Read, Glob, Grep, and Bash(git log *) while blocking Write, Edit, and all network operations. A CI pipeline doing automated code review might permit Read, Bash(npm test), and specific MCP tool calls, while blocking anything that touches the filesystem outside the workspace directory.

Project-level .claude/settings.json files are your friend here. They let you scope permissions to the specific repo without touching global user settings. A project with a dangerous migration script can block Bash(npx sequelize *) locally, regardless of what the user's global settings allow. This scoping is critical in multi-project environments where developers switch between codebases with different risk profiles.

Here's a minimal example of a project-level permissions configuration:

{
  "permissions": {
    "allow": ["Read", "Glob", "Grep", "Bash(git log *)"],
    "deny": ["Write", "Edit", "WebSearch", "Bash(rm *)"]
  }
}

The deny list takes precedence over allow. If a tool matches both, it's blocked. That behavior is intentional and worth knowing before you debug a permission that seems like it should work.

Claude Code Permissions List Tools and Solutions

Native configuration through settings.json covers most use cases, but several tooling layers sit on top of it for teams that need centralized enforcement.

Policy-as-code through version control is the simplest approach: commit .claude/settings.json to the repo so every developer inherits the same permissions list. Combined with branch protection rules that block edits to that file without review, you get audit-trail coverage for permission changes. This is low-overhead and works in any team using Git.

MCP server scoping is worth treating as a separate permissions surface. Each MCP server you connect to Claude Code introduces its own tool namespace. The mcpServers configuration block accepts trust levels (local, auto, never) that determine whether tool calls from that server auto-execute or require confirmation. Misconfiguring this is the most common way teams end up with a broader permissions footprint than they intended.

Enterprise permission management at the organizational level — centrally defined allowlists distributed to developer machines — is an area where dedicated tooling adds value. The Claude Code Security product overview describes how centralized policy management, audit logging, and permission enforcement work across teams at scale.

At Claude Code Security, we've seen teams go from ad-hoc per-developer configurations to centrally audited permission policies and reduce their security incident rate from AI-related operations significantly. The mechanism isn't complicated — it's consistently applying the permissions list across environments.

Claude Code Permissions List Best Practices

A few concrete recommendations based on what actually causes problems in production environments:

• Scope MCP permissions explicitly. Don't rely on the default trust level for third-party MCP servers. Enumerate exactly which tools from each server should auto-execute, and block the rest. This is the single highest-leverage change most teams can make to their claude code permissions list.

  • Block destructive Bash patterns by default. Bash(rm *), Bash(git reset *), Bash(git push --force *), database drop commands — these should require explicit confirmation unless there's a very specific, justified reason to automate them.
  • Use project-level configs over user-level ones for production-adjacent work. User-level settings are too easy to drift on. Project-level settings are version-controlled and reviewable.
  • Audit your permissions list after adding MCP servers. New servers extend the tool namespace. Run a quick review of your allowedTools list any time you add an MCP integration.
  • Test permission boundaries with a dry-run before enabling automation. Run Claude Code in interactive mode with the intended permissions list and observe what it asks about versus what it executes silently. There's no substitute for empirical verification.

For more on how these practices integrate with broader AI security posture, the Claude Code Security blog covers MCP server hardening, settings.json reference configurations, and incident analyses from real deployments.

The underlying point is simple: the permissions list is a security control, not a convenience setting. Treat it accordingly. Review it when you onboard new developers. Update it when your workflow changes. Block what you don't use. The cost of over-permitting is paid when something goes wrong, and by then it's too late.

If you're ready to move beyond manual configuration to policy-managed permissions across your team, Claude Code Security pricing covers options for both small teams and enterprise deployments.

Frequently Asked Questions

What is the Claude Code permissions list?

The Claude Code permissions list is the configuration — defined in settings.json files — that specifies which tool calls Claude Code can execute automatically versus which require explicit user approval before running. It controls access to bash commands, file operations, web requests, and MCP server tools.

What happens when a tool call isn't on the permissions list?

If a tool isn't in the allowedTools list and isn't explicitly blocked, Claude Code defaults to asking for confirmation before executing it. If it's in blockedTools (or the deny array), the call is rejected outright and Claude Code will report that the action isn't permitted. It won't silently skip or retry through an alternate path.

Can permissions be scoped per project?

Yes. Project-level permissions live in .claude/settings.json at the root of a repository. These override user-level settings (~/.claude/settings.json) for any session opened within that project. This means you can lock down a high-risk codebase without affecting permissions in other projects on the same machine.

How does the Claude Code permissions list work with MCP servers?

MCP servers introduce their own tool namespaces, formatted as mcp__servername__toolname. These tool names can appear in your allowedTools or blockedTools lists just like built-in tools. Additionally, each MCP server has a trust level setting that determines its default behavior — whether its tools auto-execute, require approval, or are never permitted. Configure both the server trust level and individual tool entries for complete control.

What are the best tools for managing the Claude Code permissions list?

For individuals, native settings.json configuration with version-controlled project-level files is sufficient. For teams, the priority is centralizing policy so permissions don't drift per-developer. Dedicated Claude Code security management tools handle centralized policy distribution, audit logging of tool calls against the permissions list, and alerting on violations — the Claude Code Security product overview covers this in detail.

What are common Claude Code permissions list mistakes to avoid?

The most frequent mistakes: (1) leaving MCP server trust levels at defaults without reviewing which tools they expose, (2) setting broad Bash(*) allow rules that bypass the intent of the permissions system entirely, (3) keeping all permissions at the user level where they apply globally across every project regardless of risk, and (4) never auditing the permissions list after workflow changes or new integrations. Each of these has caused real incidents in production environments.