Skip to content

Permissions

Permissions are capability boundaries that define what an agent is allowed to do — specifically, which tools it may invoke and which are off-limits. They are not behavioral guidance; they are hard fences enforced by the harness before any tool call runs.

Tagline: Governance defines what is correct. Permissions define what is possible.

Permissions operate at the tool level:

  • Allowlist — only these tools may be called (tools in agent frontmatter)
  • Denylist — these tools are explicitly blocked (disallowedTools in agent frontmatter)
  • Project-levelsettings.json allowedTools / permissions apply to the main agent for a repo

A permission boundary is enforced regardless of what the agent is instructed to do. An agent with disallowedTools: [Write] cannot write files even if a skill tells it to.

ScopeLocationEffect
Agent-scopedagents/*.md frontmatter (tools, disallowedTools)Applies to that subagent only
Project-scoped.claude/settings.json allowedToolsApplies to main agent in this repo
User-scoped~/.claude/settings.jsonApplies to main agent in all repos

Both limit what an agent can do, but at different layers:

PermissionsConstraints
MechanismHarness-enforced before tool callBehavioral limit in agent definition or hook
What it stopsSpecific tool invocationsPatterns of behavior (turn count, operation type)
GranularityPer-toolPer-behavior

Permissions bundled in an agent definition travel with the agent — installing a plugin that includes an agent also installs its permissions. Project-level permissions in settings.json are local and not distributed by a plugin.

In the plugin schema:

SchemaField
Claude Code agent frontmattertools, disallowedTools
Open Plugin Spec agent frontmattersame pattern
(no top-level plugin field)
  • Constraints — behavioral limits that complement permissions
  • Persona — the agent definition that bundles permissions
  • Agent Configuration — full picture of what shapes agent behavior