When to let a coding agent act without asking you

For the first week you read every permission prompt. By the third week your hand knows where the yes key is, and you are approving a command you have not finished reading. Anthropic put a number on the end state of that habit: “Claude Code users approve 93% of permission prompts” [5]. A gate you open 93% of the time is not a control. It is a keystroke.

So the vendors moved the decision. Instead of asking you each time, the agent now runs in a permission mode you picked once, with rules you wrote once, inside a boundary you set once. That is a better place for the decision, because you make it while you are thinking about it rather than while you are mid-task. It is also easier to get wrong and never notice. This guide is for someone running an agent on their own machine or a small team’s repo. If your employer deploys managed settings to your laptop, the keys below are already decided for you, and your job is to find out what they say.

The approval prompt stops working before you notice

Anthropic’s own framing for why auto mode exists is approval fatigue, and the 93% figure is what that framing rests on [5]. The uncomfortable part is that the prompt still feels like oversight while it has stopped being oversight. Nothing on screen changes when you cross from reading to reflexively approving.

Two of the products people actually use have landed in the same shape. Cursor ships three run modes, and one of them, Auto-review, runs allowlisted calls immediately, runs other shell commands in the sandbox when possible, and sends calls that do not use the sandbox to the Auto-review classifier [7]. Claude Code’s auto mode does the same thing under different names: a second model, not you, reviews the actions that would otherwise have produced a prompt [1]. In both, the answer to approval fatigue is not fewer checks. It is checks a machine performs, at machine speed, so that the checks left for you are the ones worth stopping for.

That only helps if you know which checks moved and which stayed.

Auto mode is a second model reviewing actions, not a switch that turns checks off

In auto mode, Claude Code routes each action that is not a plain read or a working-directory edit through a classifier model, which blocks anything that escalates beyond your request, targets unrecognised infrastructure, or appears driven by hostile content the agent read [1]. Blocked by default: downloading and executing code such as curl | bash, force pushes, production deploys and migrations, terraform destroy, git reset --hard, granting IAM or repo permissions, and printing a live credential into the transcript or a file [1]. Allowed by default: local file work in your working directory, installing dependencies your lock files or manifests already declare, read-only HTTP, and pushing to any branch of the repository you are already working in [1].

Two details decide whether this behaves as you expect. First, the classifier trusts your working directory and the remotes that were configured for it when the session started, and treats everything else as external until you tell it otherwise in autoMode.environment [1][2]. Your own S3 bucket is external. Your company’s package registry is external. A remote you add mid-session with git remote add is external too [1]. Second, the classifier sees your messages, the agent’s tool calls, and your CLAUDE.md, but tool results are stripped, so hostile content inside a file the agent read cannot address the classifier directly [1].

Entering auto mode also quietly suspends the broad allow rules you may have accumulated, including a blanket Bash(*), wildcarded interpreters like Bash(python*), and package-manager run commands. Narrow rules such as Bash(npm test) stay in force, and Claude Code restores the dropped ones when you leave the mode [1]. If the classifier blocks an action three times in a row, or twenty times in a session, auto mode pauses and ordinary prompting resumes; approving the prompted action resumes auto mode. Those thresholds are not configurable [1].

The mode a session starts in is not the same everywhere

This is where people get surprised. On Pro, Max and Team plans, a terminal or VS Code session starts in auto mode by default, on Claude Code v2.1.228 or later, and v2.1.233 or later on native Windows; on earlier versions the built-in default is Manual [1]. A claude -p run, an Agent SDK session, an Enterprise plan, a Console API key, or a session on Amazon Bedrock, Google Cloud’s Agent Platform or Microsoft Foundry all start in Manual mode instead, whose config value is default [1]. Same tool, same version, different starting posture depending on how you launched it and what you pay with.

Defaults on this front also move between releases. Claude Code versions 2.1.158 through 2.1.206 required CLAUDE_CODE_ENABLE_AUTO_MODE=1 before auto mode would work on Bedrock, Agent Platform and Foundry; version 2.1.207 removed that requirement, and the variable is still accepted for compatibility and has no effect [1][2]. If you had scripts that relied on the variable being the thing that turned autonomy on, the variable stopped being the thing.

There is a related trap in settings files. Setting permissions.defaultMode to auto or bypassPermissions in a project’s .claude/settings.json or .claude/settings.local.json does not take effect; those two values apply only from user settings, managed settings, or a --permission-mode flag for one session [1][6]. The docs give the reason where the same restriction covers the classifier’s own configuration: both files live in the repo directory, so a checked-in repo or a build step could otherwise inject its own allow rules [2]. It is also why a teammate’s “it works for me” configuration may silently do nothing for you. Check the status bar rather than assuming: it reads ⏸ manual mode on or ⏵⏵ auto mode on [1].

Choose the mode from what a mistake would cost to undo

The useful question is not how much you trust the model. It is what the worst plausible action would cost you to reverse. A wrong edit in a git branch costs a git checkout. A wrong terraform apply against production costs your afternoon and possibly your client. Sort your work by that, and the mode picks itself.

Claude Code offers six [1]. Manual (default) auto-approves reads only. acceptEdits adds file edits and common filesystem commands such as mkdir, mv and cp inside your working directory. plan researches and proposes without editing your source. auto is the classifier-reviewed mode above. dontAsk runs only what your allow rules, the built-in read-only commands, or a PreToolUse hook approve, auto-denies everything else, and never waits for input, which is the right shape for CI. bypassPermissions skips the checks entirely, and the documentation is blunt that it belongs only in isolated containers and VMs; on Linux and macOS it refuses to start as root or under sudo [1].

Two guardrails hold under every mode except bypass. Writes to protected paths, which include .git, .claude, .gitconfig and your shell startup files, are never auto-approved, and no permissions.allow entry pre-approves them [1]. And an rm or rmdir aimed at a critical path, meaning the filesystem root, a top-level directory, your home directory or your working directory and its parents, can never be approved by an allow rule or by a PreToolUse hook returning allow. In auto mode it goes to the classifier; in dontAsk it is denied outright [1].

Ask and deny rules are the boundaries that survive a long session

Telling the agent “don’t push until I’ve reviewed it” does work. The classifier treats a boundary you state in conversation as a block signal, and it stays in force until you lift it in a later message; the agent’s own judgment that the condition was met does not lift it [1]. But it is not stored as a rule. The classifier re-reads it from the transcript on each check, so context compaction can remove the message that stated it, and with it the boundary [1][2].

For anything you actually care about, write a rule. Rules are evaluated deny, then ask, then allow, the first match in that order determines the outcome, and specificity does not change the order [3]. A broad deny rule blocks every matching call, including calls that also match a narrower allow rule, so a deny rule cannot carry allowlist exceptions [3]. Ask rules that match on a command’s content are evaluated before the classifier and always force a prompt, even in auto mode, because an explicit ask rule is your stated intent to be prompted [2]. The documented recipe for keeping a human checkpoint on publishing while staying hands-off everywhere else is permissions.ask containing Bash(git push *) and Bash(gh pr create *) [2].

Then spend twenty minutes on the other side of the ledger. Every routine block you hit is the classifier not knowing your infrastructure, and the fix is autoMode.environment entries written as plain prose, naming your source-control org, internal domains, buckets, key internal services and package registry [2]. Keep the literal string "$defaults" in any of those arrays: omitting it replaces the entire built-in list for that section, including the soft block rules on force push and curl | bash [2]. Note also that the classifier does not read autoMode from project settings files, so those entries belong in ~/.claude/settings.json [2].

The sandbox decides what a wrong decision can reach

Permission modes decide who approves an action. Isolation decides what the action can touch once approved, and it is the layer solo operators most often skip. Claude Code’s Bash sandbox runs on macOS, Linux and WSL2, with native Windows unsupported, and gives sandboxed commands read and write access to your working directory, added directories and the session temp directory, while routing network access through a proxy that pre-allows no domains by default [4].

Read the read policy carefully, because it is the one that bites. By default the sandbox allows read access to the entire computer apart from certain denied directories, and the documentation notes plainly that this still allows reading credential files such as ~/.aws/credentials and ~/.ssh/ [4]. Blocking those takes explicit sandbox.credentials entries or denyRead paths [4]. And the sandbox is a risk reduction, not a wall: the built-in proxy enforces the allowlist from the requested hostname and by default does not terminate or inspect TLS, so the documentation warns that a broad entry like github.com can create paths for exfiltration [4].

What still goes wrong

The classifier misses things, and Anthropic publishes the number rather than hiding it: “The 17% false-negative rate on real overeager actions is the honest number”, alongside the statement that auto mode “is not a drop-in replacement for careful human review on high-stakes infrastructure” [5]. The docs say the same thing in their own words: auto mode reduces permission prompts but does not guarantee safety, and is for tasks where you trust the general direction [1]. Treat that as the design intent. The classifier is a substitute for a human approver on routine work, and routine is doing real work in that sentence.

It also costs something. The classifier runs on Claude Sonnet 5 by default rather than on your /model selection, adds a round-trip before execution, and on Enterprise plans and on accounts using the Claude API, Bedrock, Agent Platform or Foundry, those calls count toward your token usage [1]. Reads and working-directory edits outside protected paths skip it, so the overhead lands on shell commands and network operations, which is exactly the work an unattended session is full of.

The failure mode nobody warns you about is drift. You add an allow rule to clear a block, then another, and six months later your configuration approves a category of action you would not approve today. Nothing prompts you to review it. Run claude auto-mode config to print what the classifier is actually using with your settings applied, and read your own permissions.allow list occasionally with the question “would I write this rule today” [2]. This guide will not help if the answer to a blocked action is always to widen the rule until the block goes away.