The Autonomy Ladder

The Problem

Permission prompts are the safety model most teams are actually running, and nobody chose it. It works because a human is sitting there. It stops working the moment the session is long, the engineer is in a meeting, or the run started from CI.

So teams do the obvious thing and turn the prompts off. --dangerously-skip-permissions is in half the internal READMEs in the industry, usually with no container around it. That is not a ladder, it is a cliff. Every prompt disappears at once, on a laptop with SSH keys, cloud credentials and a browser profile in the home directory, driving an agent that reads issue text and web pages written by strangers.

The middle rungs exist now. Almost nobody has configured them.

What Changes on August 14

Auto mode becomes the default permission mode for new sessions on Pro, Max and Team plans. Instead of prompting you, a separate classifier model reviews each action before it runs and blocks anything that escalates beyond what you asked for, targets infrastructure it does not recognize, or looks driven by content Claude read rather than by you.

Two things survive the switch. A default you set yourself stays in place unless you accept the one-time switch prompt, and a default your organization manages is unchanged. Everything else moves.

The Four Rungs

• Rung 1, Manual (default).Reads run, everything else prompts. Correct for a codebase you do not know yet and for anything touching auth, payments or migrations.
• Rung 2, acceptEdits and plan.acceptEdits stops asking about file edits and common filesystem commands and keeps asking about everything else. plan stays read-only until you approve an approach. These are the two rungs a senior engineer actually lives on during normal work.
• Rung 3, auto.No routine prompts. A classifier reviews each action instead. Explicit ask rules still prompt and deny rules still block, both evaluated before the classifier runs. This is the new default.
• Rung 4, bypassPermissions and --dangerously-skip-permissions.Nothing is reviewed. Only explicit ask rules, connector tools your org set to ask, MCP tools marked requiresUserInteraction, removals targeting / or your home directory, and the cross-session messaging safeguards still stop it. Claude Code refuses to start with the flag as root on Linux and macOS.

There is a fifth mode, dontAsk, which runs only pre-approved tools and prompts for nothing. It is the CI rung, not a desk rung.

What the Classifier Actually Blocks

Worth reading before you rely on it, because the list is more specific than "risky things":

• Force push, git reset --hard, git clean -fd, git stash drop, and amending a commit that was not created in this session
• curl | bash, and any command carrying a flag that disarms a safety guard such as --insecure
• Production deploys and migrations, terraform destroy and its equivalents, toggling or deleting a production feature flag
• Merging a pull request no human approved, approving Claude's own pull request, disabling CI checks
• Committing or pushing a change that would send secrets outside the repository when CI or a deploy runs it. The check fires when the change lands, whether or not that landing triggers the pipeline
• Launching another autonomous agent loop with isolation and per-action approval disabled

What it allows without asking is the part that surprises people:

• Local file operations in the working directory
• Installing dependencies declared in your lock files
• Reading .env and sending those credentials to their matching API
• Pushing to any branch of the repository you are working in, including the default branch, and opening a pull request that matches your request

The classifier trusts your working directory and the remotes that were configured when the session started. A remote added mid-session with git remote add is not trusted. Everything else is external until you say otherwise.

Teach It Your Infrastructure

Out of the box the classifier does not know your GitHub org, your artifact registry or your staging bucket, so it blocks routine internal operations as potential exfiltration. Fix that once, in ~/.claude/settings.json or managed settings. Entries are prose, not patterns. Write them the way you would describe your infrastructure to a new engineer:

1{
2  "autoMode": {
3    "environment": [
4      "$defaults",
5      "Organization: Acme. Primary use: frontend product development",
6      "Source control: github.com/acme and all repos under it",
7      "Trusted internal domains: *.internal.acme.dev, api.internal.acme.dev",
8      "Key internal services: CI at ci.acme.dev, Artifactory at artifacts.acme.dev",
9      "Internal package registry: npm.acme.dev, all installs route through it",
10      "Sensitive remote targets: the prod-* Kubernetes namespaces"
11    ]
12  }
13}

The literal "$defaults" string splices the built-in entries in at that position. Leave it out and you replace the entire default list for that section, which is almost never what you meant. Check what the classifier ended up with:

1claude auto-mode defaults   # the built-in rules, as JSON
2claude auto-mode config     # your effective rules, "$defaults" expanded
3claude auto-mode critique   # AI review of the rules you wrote

The classifier deliberately does not read autoMode from .claude/settings.json or .claude/settings.local.json, so a checked-out repository cannot grant itself trust. Keep it in user or managed settings.

The Boundaries That Actually Hold

Three mechanisms, three different strengths. Pick by how firm the boundary needs to be, not by which is quickest to type.

• Said in conversation."Do not push until I review" blocks matching actions and stays in force until you lift it. But the classifier re-reads it from the transcript on every check, so context compaction can silently delete it. Fine for a session, never for a policy.
• permissions.ask.Evaluated before the classifier, always prompts for content-scoped rules. This is how you keep a human checkpoint on one specific action while auto mode handles the rest.
• permissions.deny.Blocks before the classifier is consulted. Neither the classifier nor stated user intent can override it. In managed settings this is the only one of the three that is a real policy boundary.

1{
2  "permissions": {
3    "ask": ["Bash(git push *)", "Bash(gh pr create *)"],
4    "deny": ["Read(./.env.production)", "Bash(fly deploy *)"]
5  }
6}

One more, and it is the strongest. A PreToolUse hook fires before any permission-mode check, in every mode. A hook that returns permissionDecision: "deny" blocks the tool even in bypassPermissions mode or with --dangerously-skip-permissions. That is the one gate an engineer cannot walk around by changing their own mode.

Isolation Is a Separate Setting

Permission modes decide whether an action runs. Isolation decides what it can touch once it does. Teams routinely configure the first and skip the second, which is how one prompt injection in a GitHub issue becomes a read of ~/.ssh.

The built-in Bash sandbox is the cheap first step. /sandbox opens the panel. On macOS there is nothing to install, on Linux and WSL2 it needs bubblewrap and socat, and native Windows is not supported. The default boundary: writes limited to the working directory and the session temp directory, and no network domains pre-allowed at all, with a prompt the first time a command needs one.

1{
2  "sandbox": {
3    "enabled": true,
4    "network": {
5      "allowedDomains": ["registry.npmjs.org", "*.github.com"]
6    },
7    "credentials": {
8      "files": [
9        { "path": "~/.ssh", "mode": "deny" },
10        { "path": "~/.aws/credentials", "mode": "deny" }
11      ],
12      "envVars": [{ "name": "NPM_TOKEN", "mode": "deny" }]
13    }
14  }
15}

The credentials block is not optional decoration. The sandbox's default read policy allows reading the entire computer, ~/.ssh and ~/.aws/credentials included, and there is no built-in credential deny list. Only the files and variables you name are protected.

Know what the Bash sandbox does not cover. Read, Edit and Write run inside the Claude Code process under permission rules instead, and MCP servers and hooks run unconstrained on the host. To put all of it behind one OS boundary without Docker, wrap the whole process:

Same Seatbelt and bubblewrap primitives, configured from ~/.srt-settings.json. It is a beta research preview and the config format may still change. Allow writes to at least your project directory, ~/.claude, ~/.claude.json and /tmp, and allow api.anthropic.com plus claude.ai and platform.claude.com if you sign in with OAuth rather than an API key. Without a valid settings file the runtime starts anyway with network blocked, so a clean start is not proof your config loaded.

Above that sit the published dev container with its default-deny iptables firewall, any container you already run in CI, a VM for genuinely untrusted code, and Claude Code on the web, where each session runs in an Anthropic-managed VM behind an allowlist proxy with your GitHub token held outside the sandbox.

The Rule That Matters

Match the rung to the boundary. As one line: never run rung 4 without a container, a VM or the sandbox runtime around the whole process.

Auto mode is a different case. The classifier is a per-action control, not an isolation boundary, so a container there is defense in depth rather than a prerequisite. And the Bash sandbox alone is not sufficient for fully unattended runs in either mode, because file tools, MCP servers and hooks sit outside it. Layering is fine and often right: the Bash sandbox inside a container gives you per-command restrictions on top of the environment boundary.

Why This Matters for Senior Teams

• The default changes whether you decide or not.Every engineer on Pro, Max or Team starts new sessions in auto mode from August 14. A team that has not written its autoMode.environment will spend that week fighting false positives on its own registry and its own GitHub org.
• It ends the --dangerously-skip-permissions habit.People reach for the flag because of prompt fatigue. Auto mode removes the fatigue without removing the review, so the flag stops being the pragmatic choice.
• Policy stops depending on who set up the laptop.Deny rules and sandbox keys in managed settings hold for everyone, and a PreToolUse hook holds even for the engineer who switched to bypass mode.
• Unattended runs become an operational decision instead of a dare.Once the rung and the boundary are written down, "can this run overnight" has an answer that does not depend on the individual.
• It is the honest answer to the security question in the room.Every client asks what stops the agent from touching production. "A prompt appears and someone reads it" is not an answer. A deny rule, a network allowlist and an isolation boundary are.

Where It Fits in the Stack

• Pairs with the Browser Verification Loop.Verification says the output is right. Autonomy says how long it runs before you look. Neither works alone: a closed loop with no boundary is a fast way to break something, and a boundary with no loop is a session that still stops at "it compiled".
• Governs Agent Teams.Every teammate is a full Claude Code instance and inherits the mode and the sandbox config. Getting the rung wrong multiplies by the size of the team.
• Ships in a plugin.Put the deny rules, the sandbox keys and the PreToolUse policy hook in the plugin, and the whole team inherits the same envelope on install, at the same version.
• Written into CLAUDE.md too.The classifier reads the same CLAUDE.md content Claude does, so a line like "never force push" steers both at once.
• Explains the CI rung.dontAsk plus a container is the shape for headless runs, where nobody is there to answer a prompt.

When Not to Use It

• Do not skip to rung 4 to save configuration time.If auto mode is blocking things, the fix is an environment entry, not turning the review off.
• Do not treat the sandbox as a hard boundary.The built-in proxy allows by hostname and does not inspect TLS by default, so a broad allowedDomains entry such as github.com leaves a path for exfiltration. Keep the list narrow, and run a custom TLS-terminating proxy if your threat model needs one.
• Do not widen one layer and forget the other.An allowWrite path, a broad domain, or an excludedCommands exception can quietly undo a restriction on the other side. Filesystem and network isolation only work together.
• Do not put autoMode or defaultMode: "auto" in project settings.Claude Code ignores both from .claude/settings.json and .claude/settings.local.json on purpose. They belong in ~/.claude/settings.json.

Source

• Choose a permission modecode.claude.com (opens in a new tab)
• Configure auto modecode.claude.com (opens in a new tab)
• Configure the sandboxed Bash toolcode.claude.com (opens in a new tab)
• Choose a sandbox environmentcode.claude.com (opens in a new tab)
• Automate actions with hookscode.claude.com (opens in a new tab)