Skip to main content
Official reference — For permission configuration syntax and managed settings, see the official permissions docs. This page is about when to use each mode, not how to configure them.

​
Modes as Workflow Levers

Most engineers pick a permission mode once and forget about it. But switching modes mid-session — via Shift+Tab — is a workflow optimization tool.
ModeWhat it doesWhen to use
NormalAsks for approval on most tool callsEarly exploration, unfamiliar code, high-risk changes
Auto-acceptApproves safe operations automaticallyActive implementation after you’ve validated the approach
PlanClaude plans but doesn’t execute until you approveArchitecture decisions, risky refactors, database changes
Don’t askLike auto-accept but suppresses all promptsBackground agents, CI/CD, well-defined tasks with strong hooks
Bypass permissionsNo restrictions at allContainers only. Never on your host machine.

​
The Trust Progression

Permission modes map to trust — and trust should increase as guardrails do: 
Start a feature   →  Normal (explore, understand the code)
Validated approach →  Auto-accept (implement with confidence)
Risky refactor     →  Plan (review before execution)
Background agent   →  Don't ask (hooks enforce safety)
The key insight: you don’t need the same permission level for the entire session. Shift+Tab lets you tighten or loosen controls as the risk profile changes.

​
Modes and Multi-Agent Work

For Agent Teams and subagents, permission modes interact:
  • Teammates inherit the lead’s permission mode by default
  • Subagents can be spawned with explicit modes via the mode parameter
  • Background agents prompt for permissions before launching — set to dontAsk if your hooks handle safety
If an agent stalls, it’s often waiting for a permission prompt you can’t see. Route background agents to dontAsk mode with hooks providing the safety layer.

​
Sandboxing for Autonomous Work

Official reference — For OS-level sandboxing (macOS Seatbelt, Linux bubblewrap), filesystem isolation, and network restrictions, see the official sandboxing docs.
When running agents with dontAsk or bypassPermissions, sandboxing provides the safety net that permissions would normally give. The tradeoff: you lose fine-grained control but gain a hard boundary that can’t be bypassed by prompt injection.
LayerWhat it restricts
Filesystem sandboxRead/write only within project directory
Network sandboxOutbound only to allowed domains
Container isolationFull OS-level boundary (Docker, devcontainers)
For overnight autonomy, the combination of dontAsk + OS-level sandboxing + stop hooks is the production-grade safety stack.
← Prev: Agent Teams · Next: Cost & Model Routing →