Help us improve
Share bugs, ideas, or general feedback.
From plugin-creator
Configures Claude Code permissions: tool rules (allow/deny/ask), modes (plan/dontAsk/bypass), sandboxing. Use for Bash/Edit/WebFetch policies, debugging prompts, org managed settings.
npx claudepluginhub jamie-bitflight/claude_skills --plugin plugin-creatorHow this skill is triggered — by the user, by Claude, or both
Slash command
/plugin-creator:permissionsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
Provides reference for Claude Code permission modes (default, acceptEdits, plan, dontAsk, bypass), allow/deny lists, pattern matching, and tool categories. Use to configure secure tool access and switch modes runtime.
Guides Claude Code permission configuration, rules (allow/ask/deny), modes, tool-specific patterns (Bash/read/edit/WebFetch), /permissions command, and troubleshooting via docs-management delegation.
Explains Claude Code settings hierarchy, permission wildcards, allow/deny patterns, and tool configurations. Use for setting up project permissions, debugging access issues, or understanding tool blocks.
Share bugs, ideas, or general feedback.
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.
| Tool Type | Examples | Approval Required | "Don't ask again" Scope |
|---|---|---|---|
| Read-only | File reads, Grep, Glob | No | N/A |
| Bash commands | Shell execution | Yes | Permanent per project + command |
| File modification | Edit, Write | Yes | Until session end |
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]
Set defaultMode in settings files:
| Mode | Behavior |
|---|---|
default | Prompts for permission on first use of each tool |
acceptEdits | Auto-accepts file edit permissions for session |
plan | Read-only — cannot modify files or execute commands |
delegate | Coordination-only for team leads (requires active agent team) |
dontAsk | Auto-denies tools unless pre-approved via /permissions or permissions.allow |
bypassPermissions | Skips all permission prompts (containers/VMs only) |
WARNING: bypassPermissions disables all checks. Only use in isolated environments. Administrators can prevent it with disableBypassPermissionsMode: "disable" in managed settings.
Rules follow the format Tool or Tool(specifier).
Use tool name without parentheses:
Bash — matches all Bash commandsWebFetch — matches all web fetch requestsRead — matches all file readsBash(*) is equivalent to Bash.
* 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.
Follow gitignore specification:
| Pattern | Meaning | Example |
|---|---|---|
//path | Absolute path from filesystem root | Read(//Users/alice/secrets/**) |
~/path | Path from home directory | Read(~/Documents/*.pdf) |
/path | Relative to settings file | Edit(/src/**/*.ts) |
path or ./path | Relative to current directory | Read(*.env) |
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(domain:example.com) — matches requests to example.commcp__puppeteer — all tools from the puppeteer servermcp__puppeteer__* — wildcard, same effectmcp__puppeteer__puppeteer_navigate — specific toolAgent(Explore) — matches Explore subagentAgent(Plan) — matches Plan subagentAgent(my-custom-agent) — matches custom agentDeny specific agents:
{
"permissions": {
"deny": ["Agent(Explore)"]
}
}
Administrators deploy managed-settings.json to system directories. These cannot be overridden by user or project settings.
Locations:
/Library/Application Support/ClaudeCode/managed-settings.json/etc/claude-code/managed-settings.jsonC:\Program Files\ClaudeCode\managed-settings.jsonThese are system-wide paths (not user home directories) requiring administrator privileges.
| Setting | Effect |
|---|---|
disableBypassPermissionsMode | Set "disable" to prevent bypassPermissions mode |
allowManagedPermissionRulesOnly | When true, only managed settings can define allow/ask/deny rules |
allowManagedHooksOnly | When true, only managed and SDK hooks are allowed |
strictKnownMarketplaces | Controls which plugin marketplaces users can add |
Highest to lowest priority:
.claude/settings.local.json).claude/settings.json)~/.claude/settings.json)A permission allowed in user settings but denied in project settings is blocked.
By default, Claude has access to files in the launch directory. Extend access:
claude --add-dir <path>/add-diradditionalDirectories in settingsAdditional directories follow the same permission rules as the original working directory.
Permissions and sandboxing are complementary security layers:
Use both for defense-in-depth:
allowedDomainsUse /permissions during a session to view and manage all permission rules and their source settings files.
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)