Documentation Index
Fetch the complete documentation index at: https://agentic.proxify.io/llms.txt
Use this file to discover all available pages before exploring further.
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.
| Mode | What it does | When to use |
|---|
| Normal | Asks for approval on most tool calls | Early exploration, unfamiliar code, high-risk changes |
| Auto-accept | Approves safe operations automatically | Active implementation after you’ve validated the approach |
| Plan | Claude plans but doesn’t execute until you approve | Architecture decisions, risky refactors, database changes |
| Don’t ask | Like auto-accept but suppresses all prompts | Background agents, CI/CD, well-defined tasks with strong hooks |
| Bypass permissions | No restrictions at all | Containers 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)
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.
Permissions and Instructions
Permission modes control what Claude can do. But there’s a second trust axis: what Claude is told to do. Every skill, plugin, and MCP server injects instructions into the prompt. If those instructions are compromised, permissions are your containment layer.
The rule: lower instruction trust demands tighter capability restrictions.
| Instruction trust | Recommended permission floor |
|---|
| High (your own CLAUDE.md, vetted skills) | Auto-accept or Don’t ask |
| Medium (popular community skill, first use) | Normal — approve each action |
| Low (unknown skill, unvetted MCP server) | Normal + OS-level sandboxing |
Sandboxing for Autonomous Work
Official reference — For OS-level sandboxing (macOS Seatbelt, Linux bubblewrap), filesystem isolation, and network restrictions, see the
official sandboxing docs.
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.
| Layer | What it restricts |
|---|
| Filesystem sandbox | Read/write only within project directory |
| Network sandbox | Outbound only to allowed domains |
| Container isolation | Full OS-level boundary (Docker, devcontainers) |
dontAsk + OS-level sandboxing + stop hooks is the production-grade safety stack.
