Permissions

Allow and deny rules that gate what an agent can touch — bash commands, tool calls, filesystem paths — without stopping to ask.

What a rule set is

Rules are organized into named sets stored as YAML under ~/.agents/permissions/. A set carries an allow list and a deny list covering three surfaces:

bash — shell commands the agent may run unprompted.
tools — built-in and MCP tool calls.
filesystem — paths the agent may read or write.

Applying a set to an agent version reduces prompts for the ops you trust and hard-blocks the ones you never want. A deny rule always wins over an allow rule.

List what is active

agents permissions list shows the sets in storage; pass an agent@version to see the active rules for that version. The --scope flag picks the user (global) or project (repo-specific) layer.

agents permissions list                 # sets in central storage
agents permissions list claude@2.1.207  # active rules for a version
agents permissions list --scope project # the repo-specific layer
agents permissions view default         # the allow/deny rules of one set

Import and apply

agents permissions add imports rules from an existing agent config, a YAML file, or a GitHub repo, then applies them to versions. This is the quickest way to lift your hand-tuned allow list out of one agent and share it.

# Extract your allow list from an existing config (merges into default.yml)
agents permissions add ~/.claude/settings.json --agents claude

# Install a shared set from GitHub
agents permissions add gh:team/permissions --agents codex,claude

# Apply a stored set to specific versions
agents permissions add --names default --agents claude@2.1.207,codex@0.144.1

# Apply to every installed version, non-interactively
agents permissions add --names default --all --yes

add merges into the managed block by default; pass --replace to drop rules no longer in the central set. agents permissions remove <name> deletes a set from storage.

Which harnesses honor allow lists

Not every CLI exposes a native allow list. The ones that do — where these rules take effect without a confirmation prompt — are claude, kimi, antigravity, and grok. For any other harness, MCP and skills still sync, but the allow-list rules have no native surface to bind to.

Layering

Permission sets stack per config layer. A project can lock down destructive ops in its own project scope without the team or system layer caring, and a stricter set can be applied to an experimental version to sandbox it harder than your default.

Related: Config layers, Hooks, Run modes.