tool-permission-policy

Write rules as Tool or Tool(specifier), such as Bash(npm test) or Read(./.env), and place them in permissions.allow, permissions.ask, or permissions.deny in settings.json. Deny rules are evaluated first, then ask, then allow, and the first matching behavior wins regardless of specificity.

Claude Code evaluates deny before ask before allow, so a broad deny like Bash(aws *) always blocks a narrower allow like Bash(aws s3 ls). Broad denies cannot contain allowlist exceptions; you must narrow the deny rule itself or move the exception to a separate environment.

No. Hooks are supplemental automation and cannot override matching deny or ask permission rules. A hook's allow output only lets the call continue to permission evaluation, where matching deny rules still block it and ask rules still prompt.

Use bypassPermissions only in isolated containers, VMs, or disposable worktrees without sensitive credentials or production access. Explicit ask rules and root/home deletion circuit breakers still prompt, and managed settings can disable bypass entirely where policy requires it.

Deny and ask rules may use mcp__* to target every MCP tool, but allow rules require a literal server prefix before the glob, such as mcp__github__get_*. Unanchored allow globs like mcp__* are skipped with a warning.

No. Claude Code permissions.* rules and Bash(...) syntax do not govern Claude Platform tools. Platform client-tool authorization belongs in the application handler, and server-tool request policy is configured separately through the Messages API.