Permissions and permission modes

Permissions are the boundary between “Claude suggested this” and “Claude did this.” Every other safety mechanism in Claude Code — sandboxing, hooks that block, managed MCP — is either enforcing or complementing this one.

The two questions

What may it do without asking? That is the permission mode and the allowlist. Approving a tool once does not approve it forever unless you configured it that way.

Where may it do it? That is path scoping and sandboxing. The sandboxed Bash tool and the sandbox environments documentation cover running commands with real isolation rather than trust.

Things worth knowing before you loosen anything

• Approval in one context does not carry to the next. An allowlist entry added for one task stays added.
• MCP servers inherit your permissions. Connecting a server that can write is a permission decision, not an integration decision. Managed MCP exists so organisations can make it centrally.
• Hooks can enforce what permissions allow. A PreToolUse hook can block a call the permission system would have permitted — useful for path protection.
• Computer use changes the risk category. See computer use.

For organisations

Server-managed settings let an administrator set permissions centrally rather than relying on each developer’s local configuration. Combined with managed MCP and analytics, that is the difference between a policy and a hope.

What this page does not claim

The exact names, precedence and syntax of permission modes and rules are documented upstream and change; this page deliberately describes the model rather than copying the reference, so it does not go quietly stale. Read Configure permissions for the current syntax.