Skip to main content
Claude Code asks for permission before taking potentially impactful actions — running shell commands, writing files, making network requests, and so on. The permissions system lets you pre-approve categories of actions so Claude can work autonomously within boundaries you define.

​
How permission prompts work

When Claude wants to use a tool that hasn’t been pre-approved, it pauses and shows you:
  • What tool it wants to use and with what input
  • An explanation of what the action does and why
  • A risk level assessment (Low / Medium / High)
You can allow once, allow for the session, allow always (writes to your settings), or deny the action.
Permission prompts come from /permissions (run it to view and manage rules) and from the settings permissions key.

​
Permission rule syntax

Rules use a Tool(pattern) syntax. The tool name can be combined with a glob-style pattern that matches the tool’s primary input. 
Bash(git *)          # Allow all git commands
Bash(npm run *)      # Allow npm run scripts
Read(src/**)         # Allow reading files under src/
Write(**.md)         # Allow writing Markdown files
Rules without a pattern match all uses of that tool: 
Read         # Allow all file reads
WebSearch    # Allow all web searches
Use the /permissions command to manage rules interactively. Claude Code writes new rules to the correct settings file automatically.

​
Configuring permissions in settings

The permissions key in any settings file accepts three lists of rules:
​
permissions.allow
string[]
Rules for actions Claude may take without prompting. Rules are matched against the tool name and primary input argument.
{
  "permissions": {
    "allow": [
      "Bash(git *)",
      "Bash(npm run *)",
      "Read(**)",
      "Write(src/**)"
    ]
  }
}
​
permissions.deny
string[]
Rules for actions Claude is never allowed to take, even if the user approves interactively.
{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "WebFetch"
    ]
  }
}
​
permissions.ask
string[]
Rules that always require confirmation, overriding any allow rules at a lower-priority settings scope.
{
  "permissions": {
    "ask": ["Bash(git push *)"]
  }
}
​
permissions.defaultMode
string
Default behavior when a tool use doesn’t match any allow or deny rule.
  • "default" — ask for each individual action (default behavior)
  • "acceptEdits" — auto-approve file edits, ask for shell commands
  • "bypassPermissions" — skip all permission checks (requires explicit opt-in)
{ "permissions": { "defaultMode": "acceptEdits" } }
​
permissions.additionalDirectories
string[]
Extra directories outside the project root that Claude Code is allowed to read from and write to.
{
  "permissions": {
    "additionalDirectories": ["/home/user/shared-libs"]
  }
}

​
Permission levels

Claude Code evaluates rules in this order, where later sources win:
1

Policy settings (managed-settings.json)

Set by enterprise administrators. Users cannot override these rules. When allowManagedPermissionRulesOnly is set in policy settings, rules from all other sources are ignored.
2

User settings (~/.claude/settings.json)

Personal defaults that apply across all projects.
3

Project settings (.claude/settings.json)

Team-wide defaults committed to the repository.
4

Local settings (.claude/settings.local.json)

Machine-local overrides. Gitignored. Highest precedence among user-editable sources.
deny rules from any scope block an action regardless of allow rules at other scopes. A deny in project settings cannot be overridden by an allow in local settings.

​
Sandbox mode

Sandbox mode runs shell commands inside an OS-level sandbox that restricts filesystem writes and network access. It provides a harder boundary than permission rules alone.
​
sandbox.enabled
boolean
Enable sandboxing for shell commands. When true, Bash commands run inside a restricted environment.
​
sandbox.failIfUnavailable
boolean
Abort if the sandbox cannot be activated on this system (e.g. missing kernel support). Default: false.
​
sandbox.allowUnsandboxedCommands
string[]
Specific commands that are allowed to run outside the sandbox when sandboxing is enabled.
​
sandbox.network
object
Network policy inside the sandbox (allowed hostnames, ports, etc.).
​
sandbox.excludedCommands
string[]
Commands that bypass the sandbox entirely.
Example: 
{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false,
    "allowUnsandboxedCommands": ["make test"]
  }
}

​
Enterprise permission controls

For organizations managing Claude Code at scale, policy settings expose additional controls:
​
allowManagedPermissionRulesOnly
boolean
When true (set in managed settings), only permission rules from managed settings are respected. User, project, local, and CLI argument rules are ignored.
​
permissions.disableBypassPermissionsMode
"disable"
Set to "disable" to prevent users from entering bypass-permissions mode.

​
Common permission patterns

{
  "permissions": {
    "allow": ["Read(**)"],
    "defaultMode": "default"
  }
}

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Write(src/**)",
      "Write(tests/**)",
      "Bash(git *)",
      "Bash(npm run *)",
      "Bash(npx *)"
    ],
    "deny": ["Bash(git push *)", "Bash(rm -rf *)"]
  }
}

{
  "permissions": {
    "allow": ["Read(**)"],
    "deny": ["Write", "Bash", "Edit"]
  }
}