Analyzed: March 31, 2026 leak snapshot
Permissions are one of the real control planes of Claude Code. They affect what tools the model even sees, not just what happens after a tool call is emitted.

​
Core model

The permission engine works with three rule behaviors:
  • allow
  • deny
  • ask
Those rules can come from multiple sources, including settings files, CLI arguments, commands, and session state. The main implementation is src/utils/permissions/permissions.ts.

​
What the engine decides

For each tool call, Claude Code can:
  • allow it immediately
  • deny it immediately
  • prompt the user
  • require sandbox override approval
  • route it through classifier logic first
The result is not just a boolean. It is a structured decision with explanation metadata.

​
Sources of rules

Visible sources in this snapshot include:
  • userSettings
  • projectSettings
  • localSettings
  • flagSettings
  • policySettings
  • cliArg
  • command
  • session
The engine flattens these into effective allow, deny, and ask rule lists.

​
Pre-tool filtering

src/tools.ts calls filterToolsByDenyRules() before handing the tool list to the model. That means blanket deny rules can remove tools from the prompt entirely. For MCP, server-prefix rules can hide every tool from a server before the model sees them. This is a stronger security posture than “let the model call it and deny later”.

​
Rule matching

The engine matches:
  • whole tools
  • tool-specific content or prefixes
  • MCP server prefixes
  • MCP tool-qualified names
  • agent-type-specific rules for delegated agents
This is why permission rules can be both broad and precise.

​
Decision reasons

Permission prompts are explainable. createPermissionRequestMessage() can attribute the request to:
  • classifier review
  • hooks
  • a matching rule
  • subcommand decomposition
  • sandbox override
  • working-directory checks
  • current permission mode
  • async-agent restrictions
That is unusually detailed for a CLI agent.

​
Dangerous auto-mode permissions

permissionSetup.ts explicitly blocks or flags permission rules that would bypass classifier review in auto mode. The dangerous classes include:
  • blanket shell allow rules
  • interpreter wildcard rules
  • PowerShell code-execution cmdlets
  • blanket agent delegation approval
  • Anthropic-internal tmux send-key paths
The design goal is clear: auto mode should not be equivalent to unrestricted shell execution.

​
Sandbox interaction

Permissions and sandboxing are separate but linked. A command can be allowed only inside the sandbox, or require a separate approval to run outside it. The permission-reason model includes sandboxOverride as a first-class decision reason.

​
Hooks and policies

Permission prompts can also be influenced by hooks. A hook can block or require approval for an action even when a simple allowlist would have permitted it. That gives enterprise policy and local automation a place to interpose before execution.