Claude Code Permission Modes — Four Modes, One Security Decision

Anthropic’s internal incident log contains an entry about a developer whose Claude Code session deleted remote git branches from a misinterpreted instruction. Another entry: an engineer’s GitHub auth token uploaded to an internal compute cluster. A third: a migration attempted against a production database. None of these required a bug in the model — just an agent running with too much permission and not enough friction.

TL;DR

• Claude Code has four permission modes: default (approve everything), acceptEdits (auto-approve file writes, prompt for bash), plan (read-only analysis), and auto (classifier-gated unattended execution).
• The permission mode you pick is a security decision, not a UX preference. Start with plan to review intent, set up a dev container to isolate the environment, then enable auto mode if unattended shell execution is what you actually need.
• Auto mode requires Sonnet 4.6 or Opus 4.6 and a Team, Enterprise, or API plan. It launched as a research preview — expect occasional over/under-blocking as classifier calibration continues.

The permission mode you pick in Claude Code is not a UX preference. It’s a security decision with a real blast radius. Most developers are either rubber-stamping every prompt — Anthropic’s internal data shows users approve 93% of permission requests without reviewing them — or reaching for --dangerously-skip-permissions because the approvals are annoying. Auto mode, shipped March 24, 2026, is the first usable middle ground. But it has hard requirements, real token costs, and limits the classifier won’t save you from. This guide walks through all four modes, what each actually does, and how to pick the right one for the task you’re running.

Prerequisites

• Claude Code installed and authenticated
• Claude Sonnet 4.6 or Opus 4.6 (required for auto mode specifically)
• Team, Enterprise, or API plan (auto mode is not available on Pro or Max as of April 2026)
• For Team/Enterprise: admin must enable auto mode in Claude Code admin settings before users can activate it
• A dev container or isolated environment if you plan to use auto mode (more on why below)

The Four Modes

Claude Code cycles through four permission modes via Shift+Tab. They represent four distinct stances on how much autonomy you’re handing to the agent.

Default Mode

Every file write and every bash command triggers an approval prompt. This is the conservative baseline — it forces you to review each state-changing operation before it executes.

When to use it: Exploratory work on unfamiliar codebases. Working directly on your host machine with live credentials in the environment. Any session where you want tight oversight because you don’t yet trust the task definition.

The real cost: At 93% approval rates, most of that clicking is rubber-stamping. For a 200-action refactoring session, that means interrupting your workflow roughly 200 times to click “approve” on things you’d approve anyway. Default mode’s safety guarantee only holds if you actually read each prompt. Most people don’t.

acceptEdits Mode

File operations — reads, edits, and writes — proceed automatically. Bash commands still require approval. The model can modify your codebase without prompting, but cannot execute shell commands unattended.

When to use it: Editing-heavy tasks where you trust the file changes but want to gate shell execution. Large refactors, test generation, documentation updates. If you’re doing significant codebase editing and the bash prompts are the interruption point, this mode is often enough — and it costs nothing extra in tokens.

What it won’t protect you from: Malicious or incorrect file writes. The model can overwrite configuration files, delete content, or make sweeping changes across your project without any per-operation confirmation. Scope your working directory appropriately.

Plan Mode

Read-only. Claude can analyze your codebase, ask clarifying questions, and write a plan to a markdown file — but it cannot edit source files or execute commands. This mode exists for understanding before action.

When to use it: Onboarding to a complex codebase before making changes. Getting a structured breakdown of what a large task will require. Reviewing the agent’s approach before you authorize execution. Plan mode is underused — running it before a major refactor costs little and catches scope mismatches early.

What it produces: A markdown plan file in your working directory. Review it, adjust your prompt if the scope is wrong, then switch modes to execute.

Auto Mode

The classifier-gated unattended execution mode. Before each tool call, a separate instance of Claude Sonnet 4.6 evaluates the pending action against three risk categories and either approves or blocks it. Safe operations proceed without prompting; risky ones are blocked with feedback.

Auto mode does not appear in the Shift+Tab cycle until you start Claude Code with the --enable-auto-mode flag:

claude --enable-auto-mode

Once enabled, Shift+Tab cycles through all four modes including auto.

When to use it: Long-running tasks you want to run unattended — full feature implementation, large refactors, test suite generation — where both file edits and shell execution need to proceed without per-operation approval. Only when you’re in an isolated environment (see sandbox section below).

When acceptEdits is enough: If your task is primarily file editing with minimal shell execution, acceptEdits gives you most of the productivity benefit at zero classifier overhead. Auto mode earns its cost when unattended shell execution is specifically what you need.

Auto Mode: How the Classifier Works

The classifier is a separate Claude Sonnet 4.6 instance — it runs regardless of which model you’re using for your main session. Before each tool call executes, it receives the conversation transcript and the pending action, then evaluates against three risk categories:

Scope escalation: Is the action beyond what you asked for? If you asked for a database schema migration and the model is about to create an IAM user, that’s a scope escalation signal.

Untrusted infrastructure targeting: Is the action targeting systems the classifier doesn’t recognize as part of your project environment? Network operations against unknown endpoints, S3 buckets not referenced in your codebase, external APIs not in your dependencies.

Prompt injection: Does the action look like it was driven by hostile content the model encountered in a file or web page? The classifier is deliberately isolated from tool results — injected instructions in files you’re editing cannot influence its approval decisions. A separate server-side probe scans incoming tool results and flags suspicious content before Claude reads it, and the classifier itself never sees tool results, making this a two-layer defense.

What skips the classifier: Read-only file operations and edits within your working directory bypass classifier evaluation. This reduces token overhead for the bulk of routine editing work. The overhead concentrates on shell commands and network operations, which is where the real risk lives anyway.

The fallback mechanism: If the classifier blocks 3 consecutive actions, or accumulates 20 total blocks in a session, auto mode stops and returns to manual prompting. This is what makes false positives survivable — a long-running session doesn’t die on the first aggressive classification, it degrades gracefully.

Auto mode launched as a research preview. Anthropic is collecting production data to refine classifier thresholds, so expect occasional over-approvals and over-denials as calibration continues. This is not a reason to avoid it — it’s a reason to run it in a sandboxed environment while the classifier matures.

What the Classifier Won’t Catch

The classifier is not a comprehensive safety net. Treating it like one is how you end up with an incident log entry.

Ambiguous intent: If your task description is underspecified, the classifier evaluates intent based on what’s in the conversation. Vague instructions produce uncertain classifications. The classifier can only work with the context it has.

Unknown environment context: The classifier doesn’t know your infrastructure topology. An action targeting an internal endpoint it doesn’t recognize might pass as “probably fine” because it lacks the context to flag it as production.

Sequential escalation: Individual actions can each look innocuous while collectively escalating to something dangerous. Creating an IAM user passes classifier review. Opening a network path to an internal service passes classifier review. Combined in sequence, you’ve created a credential-bearing path to production infrastructure — and the classifier evaluated each step in isolation. This is the failure mode that’s hardest to defend against programmatically.

The practical takeaway: the classifier reduces risk meaningfully, but it does not eliminate it. The safety boundary that actually contains blast radius is the sandbox you run the agent in, not the classifier running in front of it.

Sandbox Setup Before You Enable Auto Mode

I use auto mode inside a dev container. Not because I distrust the classifier, but because the classifier explicitly acknowledges it won’t catch everything, and a sandboxed environment provides the safety boundary the classifier cannot.

Here’s the pre-enablement checklist before you run --enable-auto-mode:

Verify no credentials are in scope:

# Check for cloud provider credentials
env | grep -E 'AWS_|GOOGLE_|AZURE_|GCP_'

# Check for SSH keys the agent could access
ls ~/.ssh/

# Review secrets in working directory .env files
cat .env | grep -E 'SECRET|KEY|TOKEN|PASSWORD|CREDENTIAL'

Environment isolation requirements:

• Dev container or Docker: the agent’s filesystem access is bounded by the container
• No volume mounts to ~/.ssh, ~/.aws, ~/.config/gcloud, or equivalent
• Database connections pointing to local or staging only — never production connection strings
• External API credentials scoped to sandbox or test accounts if needed at all

What --dangerously-skip-permissions is actually for: Ephemeral CI containers where the environment is the safety boundary. A container that gets destroyed after the job completes, with no credentials that persist beyond the run, no access to production systems, no real state to corrupt. If that description doesn’t match your environment, don’t use it.

Running auto mode or --dangerously-skip-permissions on your host machine with production credentials in the environment is exactly the scenario Anthropic’s incident log was built from. The classifier reduces risk. It does not eliminate it. Isolate the environment first.

Minimal Dev Container Configuration

FROM node:20-slim

# Install Claude Code
RUN npm install -g @anthropic/claude-code

# Create non-root user (no host credential inheritance)
RUN useradd -m -s /bin/bash devuser
USER devuser

WORKDIR /workspace

# Mount your project here — no home directory mounts

docker run -it \
  -v $(pwd):/workspace \
  # No -v ~/.ssh:/home/devuser/.ssh
  # No -v ~/.aws:/home/devuser/.aws
  your-claude-code-image

Token Cost Reality

The classifier adds overhead on every shell command and network operation. Anthropic hasn’t published exact figures, but the cost structure is predictable: each checked action sends a portion of the conversation transcript plus the pending action to a Sonnet 4.6 classifier instance. For a session with heavy shell execution — running tests repeatedly, build commands, git operations — this adds up. For a session that’s primarily file editing with occasional shell calls, the overhead is minimal because read-only and working-directory edits skip classification entirely.

Each classifier check also adds a round trip before the action executes. For rapid sequences of shell commands, the latency is noticeable. For tasks that are naturally async (agent generates code, runs a test suite, iterates on failures), the overhead is absorbed into the wait time anyway.

The practical calculation: If your task is primarily editing — refactoring, test generation, documentation — acceptEdits gives you unattended file operations with no classifier overhead. Auto mode earns its token cost when you specifically need unattended shell execution in a loop: running tests after every change, iterating on build output, executing migration scripts in sequence.

How to Measure the Overhead for Your Workflow

Before committing to auto mode for a class of tasks, run a quick comparison:

# Run a representative short session (20–30 actions) in acceptEdits mode
# Note: token count from session summary, wall-clock time for the task

claude --mode acceptEdits
# ... run your representative task ...
# Record: total tokens, total time

# Run the same session in auto mode
claude --enable-auto-mode
# Cycle to auto with Shift+Tab
# ... run identical task ...
# Record: total tokens, total time

Compare the two. Look for two things: the token delta (classifier overhead per action) and the latency delta (extra round trips). If the token overhead is negligible for your task profile and the latency is absorbed into natural wait time, auto mode is worth enabling. If your task involves tight loops of fast shell commands where each extra 200ms compounds, acceptEdits may be the better tradeoff.

Most developers find that editing-heavy sessions show minimal overhead — the classifier cost is effectively zero because most actions skip it. Sessions with intensive shell execution show meaningful overhead per action.

Picking the Right Mode

Start with plan mode on any task you haven’t run before. Review what the agent intends to do. If the scope matches your intent, switch to the execution mode that fits your environment and oversight preference.

Situation	Mode
Unfamiliar codebase, host machine, live credentials present	default
Heavy editing, minimal shell execution, trust the file changes	acceptEdits
Complex task, want to review before execution	plan → then switch
Long-running unattended execution in a dev container	auto
Ephemeral CI container, fully isolated	--dangerously-skip-permissions
Any of the above on a machine with production DB credentials	Stop, isolate first

Enabling Auto Mode: Step-by-Step

Step 1: Verify plan eligibility

Auto mode requires a Team, Enterprise, or API plan. It is not available on Pro or Max as of April 2026. On Team or Enterprise, your admin must enable it in the Claude Code admin settings panel before individual users can activate it.

Verify your model access — you need Sonnet 4.6 or Opus 4.6. Auto mode is not available on Haiku, claude-3 series models, or third-party providers including Bedrock, Vertex, and Foundry.

Step 2: Set up your isolated environment

Before enabling auto mode, complete the sandbox checklist above. Run the credential verification commands, confirm you’re in a container or VM, and ensure no production-scoped credentials are in the environment.

Step 3: Enable in VS Code (if applicable)

If you’re using the VS Code extension, the advanced permission modes are hidden behind a deliberate gate. In VS Code settings, search for “Claude Code permissions” and enable the setting labeled “Allow dangerously skip permissions” (JSON key: claudeCode.allowDangerouslySkipPermissions).

This setting does not activate --dangerously-skip-permissions or change your default operating mode. It does not make anything more permissive by itself. It only unhides the advanced permission-mode controls in the extension UI — Anthropic gates them behind this toggle because they consider the modes risky enough to require an explicit opt-in before the controls even appear. Once enabled, you can choose your mode manually; the default remains default mode until you change it.

Step 4: Start Claude Code with the flag

claude --enable-auto-mode

Auto mode now appears in the Shift+Tab cycle. The cycle order is: default → acceptEdits → plan → auto.

Step 5: Cycle to auto mode and confirm

# Inside Claude Code session
# Press Shift+Tab until the mode indicator shows: auto

The status display shows the current mode. Confirm it reads “auto” before starting a long-running task.

Troubleshooting

--enable-auto-mode flag has no effect

Cause: Admin hasn’t enabled auto mode in the Team/Enterprise admin settings, or you’re on a Pro/Max plan.

Fix: Check your plan tier. If on Team or Enterprise, ask your admin to enable auto mode in the Claude Code admin panel. Auto mode won’t appear in the Shift+Tab cycle until both the admin setting and the CLI flag are active.

Auto mode keeps falling back to manual prompting

Cause: Classifier is blocking actions and accumulating toward the 3-consecutive or 20-total threshold. This triggers graceful degradation to manual mode.

Fix: Review the classifier feedback on blocked actions. If the blocks are false positives — legitimate operations being flagged — refine your task description to be more specific about intended scope and infrastructure targets. Vague task descriptions produce conservative classifier behavior. Recall that auto mode launched as a research preview, so occasional over-blocking is expected while classifier calibration continues.

Session exits auto mode mid-task unexpectedly

Cause: 3 consecutive classifier denials hit the fallback threshold.

Fix: This is working as intended. Review what was blocked, answer the manual prompt to continue, and consider whether your task description needs more context about your environment for the classifier to evaluate accurately.

Auto mode not available in VS Code extension

Cause: “Allow dangerously skip permissions” setting not enabled in VS Code.

Fix: Open VS Code settings, search for “Claude Code permissions”, enable “Allow dangerously skip permissions” (claudeCode.allowDangerouslySkipPermissions). This unhides the advanced permission-mode controls — it doesn’t change your active mode or enable bypass mode automatically.

Next Steps

Auto mode is the productivity unlock for long-running agentic tasks — but it assumes you’ve done the isolation work first. A classifier running in front of an agent with production database credentials is not a safety guarantee; it’s a false sense of security. The classifier is good. It is not a substitute for environment isolation.

The sequence that actually works: plan mode to review intent, dev container to isolate the environment, auto mode to execute unattended. In that order, every time.

For a deeper look at what Claude Code can do once you have the permission model right, see the Claude Code features guide and the codebase readiness checklist for autonomous agents. The permission mode is the foundation — the interesting work starts once you’ve got it set correctly.