Review Permissions

If the user's intent does not match the purpose of this skill, load plugin-lifecycle to route to the right skill and process: Skill(skill="plugin-creator:plugin-lifecycle").

Claude Code Permissions Reference

Claude Code uses a tiered permission system to balance capability and safety. Permissions control which tools Claude can use and what resources they can access.

Permission Tiers

Rule Evaluation Order

Rules evaluate in order: deny → ask → allow. First match wins. Deny rules always take precedence.

flowchart TD
    Start([Tool call requested]) --> Deny{Matches a deny rule?}
    Deny -->|Yes| Blocked[BLOCKED — tool cannot run]
    Deny -->|No| Ask{Matches an ask rule?}
    Ask -->|Yes| Prompt[Prompt user for approval]
    Ask -->|No| Allow{Matches an allow rule?}
    Allow -->|Yes| Approved[APPROVED — tool runs]
    Allow -->|No| Default[Default behavior for tool type]

Permission Modes

Set defaultMode in settings files:

WARNING: bypassPermissions disables all checks. Only use in isolated environments. Administrators can prevent it with disableBypassPermissionsMode: "disable" in managed settings.

Permission Rule Syntax

Rules follow the format Tool or Tool(specifier).

Match All Uses

Use tool name without parentheses:

• Bash — matches all Bash commands
• WebFetch — matches all web fetch requests
• Read — matches all file reads

Bash(*) is equivalent to Bash.

Tool-Specific Specifiers

Bash (Wildcard Patterns)

* matches at any position. Space before * enforces word boundary.

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(git * main)",
      "Bash(* --version)",
      "Bash(* --help *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Word boundary behavior:

• Bash(ls *) — matches ls -la but NOT lsof (space enforces boundary)
• Bash(ls*) — matches both ls -la AND lsof (no boundary)

Shell operator awareness: Claude Code recognizes shell operators (&&, |, ;). A rule like Bash(safe-cmd *) will NOT approve safe-cmd && other-cmd.

Caveat: Bash argument constraint patterns are fragile. For reliable URL filtering, deny curl/wget and use WebFetch(domain:...) instead, or use PreToolUse hooks.

Read and Edit (Gitignore Patterns)

Follow gitignore specification:

IMPORTANT: /Users/alice/file is NOT absolute. It is relative to the settings file. Use //Users/alice/file for absolute paths.

Glob behavior: * matches files in a single directory. ** matches recursively across directories.

WebFetch

• WebFetch(domain:example.com) — matches requests to example.com

MCP

• mcp__puppeteer — all tools from the puppeteer server
• mcp__puppeteer__* — wildcard, same effect
• mcp__puppeteer__puppeteer_navigate — specific tool

Task (Subagents)

• Agent(Explore) — matches Explore subagent
• Agent(Plan) — matches Plan subagent
• Agent(my-custom-agent) — matches custom agent

Deny specific agents:

{
  "permissions": {
    "deny": ["Agent(Explore)"]
  }
}

Managed Settings (Organization Deployment)

Administrators deploy managed-settings.json to system directories. These cannot be overridden by user or project settings.

Locations:

• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Linux/WSL: /etc/claude-code/managed-settings.json
• Windows: C:\Program Files\ClaudeCode\managed-settings.json

These are system-wide paths (not user home directories) requiring administrator privileges.

Managed-Only Settings

Settings Precedence

Highest to lowest priority:

1. Managed settings (system-wide, cannot be overridden)
2. Command line arguments
3. Local project settings (.claude/settings.local.json)
4. Shared project settings (.claude/settings.json)
5. User settings (~/.claude/settings.json)

A permission allowed in user settings but denied in project settings is blocked.

Working Directories

By default, Claude has access to files in the launch directory. Extend access:

• Startup: claude --add-dir <path>
• Session: /add-dir
• Persistent: add to additionalDirectories in settings

Additional directories follow the same permission rules as the original working directory.

Permissions + Sandboxing

Permissions and sandboxing are complementary security layers:

• Permissions control which tools Claude can use and which resources they access (all tools)
• Sandboxing provides OS-level enforcement restricting Bash filesystem and network access (Bash only)

Use both for defense-in-depth:

• Permission deny rules block Claude from attempting access
• Sandbox restrictions prevent Bash commands from reaching resources outside boundaries
• Filesystem sandbox restrictions use Read/Edit deny rules (not separate sandbox config)
• Network restrictions combine WebFetch permissions with sandbox allowedDomains

Manage Permissions

Use /permissions during a session to view and manage all permission rules and their source settings files.

Detailed Reference

For comprehensive rule examples, Bash pattern edge cases, and hook-based permission extension, see references/permissions-reference.md.

SOURCE: Claude Code Permissions Documentation (accessed 2026-02-17)