When Anthropic shipped Claude Code, they weren't just releasing a coding assistant. They were releasing an agent framework – and with that comes a fundamental question every agentic system must answer: who decides what the AI is allowed to do?
The answer in Claude Code is a layered permission system with seven distinct modes. Each mode represents a different stance on the autonomy-safety tradeoff. Most are user-selectable. Two are not – and for good reason.
The 7 modes, explained
Think of the modes as a dial. On one end, Claude can't execute a single command without your explicit sign-off. On the other, it can take near-complete autonomous action, restrained only by hard safety rails baked into the system itself.
1. plan – Draft first, act later
Autonomy: LOW · Who decides: User
Before touching a single file, Claude lays out its entire plan in plain language. You review it, push back, adjust the scope – and only then give it the green light. Nothing executes until you say so.
This is the mode for high-stakes refactors or whenever you want to understand why the model is about to do what it's about to do. It's also a great teaching tool – watching Claude's reasoning unfold before execution gives you real insight into how it thinks.
Best for: new codebases, risky changes, unfamiliar projects.
2. default – Standard interactive use
Autonomy: LOW–MED · Who decides: User
The mode most developers start in. Claude can think, suggest, and prepare – but most tool calls require your explicit approval before they fire. You're the gatekeeper for file writes, shell commands, and external actions.
It balances productivity with control. You won't spend time rubber-stamping trivial analysis steps, but you'll still see every consequential action before it happens. A sensible default for daily use.
Best for: everyday development, pairing sessions.
3. acceptEdits – Auto-approve safe file writes
Autonomy: MEDIUM · Who decides: Auto (file writes) + User (shell)
A targeted upgrade from default. Edits to files inside your working directory get automatically approved – no more click-through for every single file change. But shell commands and anything touching files outside the project root still prompt you.
It's a good sweet spot for iterative coding sessions where you trust Claude's file-writing but want to retain a human checkpoint for anything that reaches outside the project boundary.
Best for: active feature work, iterative coding sessions.
4. auto – ML classifier gates requests
Autonomy: MEDIUM · Who decides: ML Classifier
Gated behind a feature flag – not available to all users yet.
In auto mode, an ML classifier sits between Claude's intent and execution. Requests that clearly match known-safe patterns get fast-patched through. Anything ambiguous or novel gets escalated for a human judgment call.
The appeal is efficiency – routine actions flow through without friction, while anything the classifier isn't confident about still surfaces for review. Think of it as a preview of where agentic systems are heading.
Best for: power users on the feature flag, hybrid workflows.
5. dontAsk – No prompts, rules still enforced
Autonomy: HIGH · Who decides: Rules engine
Claude acts without stopping to ask. No approval dialogs, no confirmations. But deny rules you've configured are still enforced – so the guardrails you explicitly set up remain in place, even if the interactive prompts disappear.
This mode shines for trusted automation pipelines: CI scripts, batch jobs, scripted workflows where human-in-the-loop would be impractical. Before enabling it, make sure your deny rules are tight. The absence of prompts makes mistakes harder to catch in real time.
Best for: CI/CD pipelines, batch automation, scripted workflows.
6. bypassPermissions – Skip most prompts, safety guards hold
Autonomy: MAX · Who decides: System
Maximum autonomy. Claude skips most permission prompts – including many that dontAsk would still surface. But safety-critical guards defined at the system level still apply. This is enforced by the platform itself, not by per-session configuration.
In practice, this mode is designed for trusted environments where the overhead of any prompting is unacceptable – think long-running autonomous agents, sandbox environments, or cases where a human has already reviewed and pre-approved the entire workflow at a higher level.
Use with intent. The "bypass" in the name is accurate. Only enable this when you have strong confidence in both the task scope and Claude's behavior in your environment.
Best for: sandboxed agents, pre-approved automated pipelines.
7. bubble – Subagent escalation (internal only)
Autonomy: INTERNAL · Who decides: Parent subagent
Not user-selectable – internal to multi-agent orchestration.
This one isn't for you – and that's the point. bubble is an internal mechanism that lets a subagent escalate a permission request to its parent agent in a multi-agent hierarchy.
Imagine Claude spawning a specialized sub-task agent. That sub-agent encounters something outside its permission scope. Rather than failing or proceeding recklessly, it bubbles the request up to the orchestrator (the parent Claude instance), which decides how to handle it. This enables safe, composable multi-agent workflows without requiring every sub-agent to have maximal permissions.
Not user-selectable. Used internally by Claude Code's multi-agent infrastructure.
Which mode should you actually use?
The right mode isn't just about autonomy preference – it's about how much you trust the current context. A workflow you've run a hundred times in a sandboxed environment is very different from a one-off refactor on a production codebase.
| Situation | Recommended mode |
|---|---|
| Exploring unfamiliar code | plan or default |
| Active coding sessions | acceptEdits |
| Automated pipelines | dontAsk (with deny rules configured) |
| Sandboxed agents | bypassPermissions |
| Multi-agent orchestration | bubble (automatic, not user-set) |
Remember: only 5 of the 7 modes are user-selectable.
autois feature-flagged, andbubbleis strictly internal to multi-agent orchestration.
The permission model is the agent contract
What makes this permission system interesting isn't any individual mode – it's the philosophy it encodes. Every step up the autonomy dial moves decision-making authority from the human, to rules, to classifiers, to the system itself. And every step comes with a corresponding shift in responsibility.
Claude Code's designers made a deliberate choice: even at maximum autonomy (bypassPermissions), safety-critical guards don't move. That line is held by the platform, not the user. It's a subtle but important constraint – autonomy is expandable, but it's not unlimited.
As AI agents become more capable and more embedded in real workflows, understanding exactly who is deciding what at each step becomes a first-class engineering concern. These seven modes are a clear, practical framework for thinking through that question.
