Configure tools with permission rules and hooks

For the most part, Claude decides when to use these tools and you don't need to name them yourself when interacting with Claude. You reference tool names directly when defining permissions and other configuration:

• in permissions.allow and permissions.deny in settings, and the /permissions interface
• in the --allowedTools and --disallowedTools CLI flags
• in the Agent SDK's allowedTools and disallowedTools options
• in a subagent's tools or disallowedTools frontmatter
• in a skill's allowed-tools frontmatter
• in a hook's if condition

All of these accept the same rule format, ToolName(specifier). The specifier depends on the tool, and several tools share a format:

Rule format	Applies to	Details
Bash(npm run *)	Bash, Monitor	Command pattern matching
PowerShell(Get-ChildItem *)	PowerShell	Command pattern matching
Read(~/secrets/**)	Read, Grep, Glob, LSP	Path pattern matching
Edit(/src/**)	Edit, Write, NotebookEdit	Path pattern matching
Skill(deploy *)	Skill	Skill name matching
Agent(Explore)	Agent	Subagent type matching
WebFetch(domain:example.com)	WebFetch	Domain matching
WebSearch	WebSearch	No specifier; allow or deny the tool as a whole

Tools not listed here, such as ExitPlanMode or ShareOnboardingGuide, accept only the bare tool name with no specifier.

An Edit(...) allow rule also grants read access to the same path, so you don't need a matching Read(...) rule. A Read(...) deny rule also blocks the Edit and Write tools on the same path, including creating a new file there, because both tools change content Claude has to be able to read back. The Read deny check requires Claude Code v2.1.208 or later on edits, and v2.1.228 or later on writes.

Hook matcher fields use bare tool names, not the parenthesized rule format. See matcher patterns for the matching rules. For the field names each tool passes to tool_input in hooks, see the PreToolUse input reference.