Help us improve
Share bugs, ideas, or general feedback.
From config-wizard
Guides configuring Claude Code permissions in settings.json using allow, ask, deny rules for tools like Bash, Read/Edit/Write, WebFetch. Covers security best practices, safe vs risky permissions, and troubleshooting denials.
npx claudepluginhub wombat9000/claude-plugins --plugin config-wizardHow this skill is triggered — by the user, by Claude, or both
Slash command
/config-wizard:managing-permissionsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Configure Claude Code permissions to control tool access and protect sensitive files.
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.
Configures Claude Code security settings with permission wildcards, shell operator protections, and project-level access controls. Use for securing tools like Bash and workflows.
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.
Share bugs, ideas, or general feedback.
Configure Claude Code permissions to control tool access and protect sensitive files.
Permissions are configured in settings.json using three groups: allow, ask, and deny.
Rule precedence: Deny > Ask > Allow
Configuration hierarchy (highest to lowest):
.claude/settings.local.json).claude/settings.json)~/.claude/settings.json)Grants explicit permission for tool use without confirmation.
When to use: Safe, routine operations that don't risk data loss or security exposure.
Examples: Reading source code, running tests, read-only git commands.
See references/allow-permissions.md for guidance and examples.
Prompts for user confirmation before allowing tool use.
When to use: Operations requiring review, such as publishing changes or modifying dependencies.
Examples: Git push/commit, package installation, editing critical config files.
See references/ask-permissions.md for examples and avoiding permission fatigue.
Explicitly blocks tool use. Takes precedence over allow and ask rules.
⚠️ Important: Deny rules are workflow controls, NOT security mechanisms. They have significant limitations (tool-specific, easily bypassed, prefix-only matching for Bash).
When to use:
NOT for security: For protecting secrets and credentials, use hooks instead (PreToolUse hooks provide tool-agnostic protection).
See references/deny-permissions.md for key limitations and proper use cases.
All permission rules follow this format:
ToolName(pattern)
Available Tools: Bash, Read, Edit, Write, Glob, Grep, WebFetch, WebSearch, NotebookEdit, Task, Skill, SlashCommand, TodoWrite, AskUserQuestion, BashOutput, KillShell, ExitPlanMode
Most common: Bash, Read, Edit, Write, Glob, Grep, WebFetch
Pattern types:
Bash(git status) matches "git status", "git status file.txt"Read(src/**) matches all files in src/ recursivelyImportant: Bash patterns use prefix-only matching and can be bypassed with command chaining. See deny-permissions.md for complete limitations.
See references/official-reference.md for complete syntax reference and known limitations.
When setting up permissions:
For security: Use PreToolUse hooks to protect secrets and credentials (see Claude Code documentation on hooks).
Sample workflow configuration:
{
"permissions": {
"deny": [
// Resource management (save tokens)
"Read(node_modules/**)",
"Read(build/**)",
"Read(dist/**)",
"Read(*.min.js)",
// Workflow guardrails (prevent mistakes)
"Bash(git push origin main:*)",
"Bash(npm publish:*)"
],
"allow": [
"Bash(npm run test:*)",
"Bash(git status)",
"Bash(git diff:*)",
"Read(src/**)",
"Read(tests/**)"
],
"ask": [
"Bash(git push:*)",
"Bash(npm install:*)"
]
}
}
Note: Hooks handle security (secrets, credentials). Deny rules handle workflow controls.
Concise guides with practical examples: