Rules: Defined Down to Every Single Command
Permission modes are a coarse-grained master switch. Permission Rules are fine-grained allowlists and blocklists that let users configure precise behavior for specific tools and commands.
Rule Format
ToolName(rule content)
Examples:
Bash(git *)— allow all Bash commands starting withgitFileEdit(/src/*)— allow editing all files under/src/Bash(rm -rf *)— if set to deny, blocks all rm -rf commands
Three Behaviors
// src/utils/permissions/PermissionRule.ts
type PermissionBehavior = 'allow' | 'deny' | 'ask'
// allow = auto-approve, don't bother the user
// deny = reject outright; Claude cannot execute
// ask = force a confirmation dialog (even in bypassPermissions mode)
Rule Sources (highest to lowest priority)
policySettings ← Enterprise admin push (MDM/remote config); users cannot override
userSettings ← User global config (~/.claude/settings.json)
projectSettings ← Project-level config (.claude/settings.json, committable to git)
localSettings ← Local private config (.claude/settings.local.json, not committed)
cliArg ← Command-line argument (--allowedTools)
command ← Slash command dynamic setting
session ← In-effect for current session only
Product design highlight: projectSettings can be committed to git, meaning teams can share permission configs — new members who clone the repo automatically get the same rules, no manual setup required.