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 with git
  • FileEdit(/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.