how much should you let claude code do without asking?
most people meet claude code through a stream of permission prompts, get tired of clicking yes, and reach for the setting that stops the asking. there are six of those settings, they are not interchangeable, and on a pro, max or team plan your sessions already start in one of the looser ones.
claude code's permission mode decides which actions run without asking you first. there are six. manual asks before everything except reads, accept edits approves file changes in your working directory, plan blocks edits while claude explores, auto hands the review to a classifier model, dont ask denies anything that would prompt, and bypass skips the checks.
what a permission mode actually decides
a permission mode sets which actions claude can take in a session without asking you first, and nothing claude reads can change it. that second half is the part worth internalising. anthropic's claude code documentation puts it flatly:
"Permission rules are enforced by Claude Code, not by the model."
the same page adds that instructions in your prompt or your CLAUDE.md shape what claude tries to do, but do not change what claude code allows (Anthropic, Claude Code documentation, accessed 15 sep 2026).
so the mode is a real boundary rather than a polite request. to move it you use the /permissions command, a rule in a settings file, the mode itself, or a PreToolUse hook. a paragraph in your CLAUDE.md asking claude to be careful is not a control. it is a suggestion, and it sits on the wrong side of the line.
two more things sit on top of the mode. deny rules block in every mode, including bypass permissions. allow rules have no effect in bypass permissions at all. so the mode sets the baseline and your rules bend it, in one direction each.
the six permission modes, side by side
the modes differ on one axis: how much runs without a prompt. the first three columns come from anthropic's permission modes documentation. the last column is how i actually assign them when i set claude code up on a real business.
| mode | runs without asking | anthropic says it is for | i reach for it when |
|---|---|---|---|
| default (manual) | reads only | reviewing every action yourself, sensitive work | the code is unfamiliar, or the folder holds anything i cannot cheaply replace |
| acceptEdits | reads, file edits, and common filesystem commands | iterating on code you are reviewing | i will read the diff afterwards and the work is inside one repo |
| plan | reads, plus classifier-approved commands when auto mode is available | exploring a codebase before changing it | i want to understand something before anything gets touched |
| auto | everything, with background safety checks | long tasks, reducing prompt fatigue | the direction is one i trust and the task is long enough that clicking yes becomes the bottleneck |
| dontAsk | reads and pre-approved tools; anything that would prompt is denied | locked-down ci and scripts | something runs unattended and i want a hard allowlist, not a judgement call |
| bypassPermissions | everything | isolated containers and vms only | almost never, and never on the machine my actual work lives on |
in the cli you cycle with shift+tab, and the status bar names the mode you are in. dont ask is the exception: it never appears in the cycle, and you set it with --permission-mode dontAsk (Anthropic, Claude Code documentation, accessed 15 sep 2026).
you are probably already in auto mode
on pro, max and team plans, in a terminal or through the vs code extension, the built-in starting permission mode is auto mode. that is anthropic's documented default, not a setting someone turned on for you (Anthropic, Claude Code documentation, accessed 15 sep 2026). the built-in auto default requires claude code v2.1.228 or later on macos, linux and wsl, and v2.1.233 or later on native windows.
the exceptions matter as much as the rule. sessions start in manual mode on an enterprise plan, with a claude console api key, in claude -p runs, on the agent sdk, and on bedrock, google cloud's agent platform, microsoft foundry and claude platform on aws. so the same command can start in a different mode on your laptop than it does in your ci.
this is worth checking rather than assuming, because auto mode is the one people describe to me as "claude just did it" without knowing a mode was involved.
what auto mode's classifier blocks by default
auto mode does not remove the review, it moves it. a separate classifier model reads each action before it runs and blocks anything that escalates beyond your request, targets unrecognised infrastructure, or looks driven by hostile content claude read. anthropic publishes the default block list, and it is more specific than most people expect:
- downloading and executing code, such as piping a download straight into a shell
- sending sensitive data to external endpoints
- production deploys and migrations
- mass deletion on cloud storage
- granting iam or repository permissions
- modifying shared infrastructure
- irreversibly destroying files that existed before the session
- force push, and git commands the classifier reads as discarding uncommitted work
- committing or pushing a change that would send secrets outside the repository
the classifier trusts your working directory and the remotes that were configured when the session started. a remote you add or repoint mid-session with git remote add is not trusted (Anthropic, Claude Code documentation, accessed 15 sep 2026). everything else counts as external until you configure trusted infrastructure yourself.
anthropic is direct about the limit of this, and so am i: auto mode reduces prompts but does not guarantee safety. it is for work where you trust the general direction, not a replacement for review on the operations that would actually hurt.
accept edits quietly includes rm
the summary table describes accept edits as file edits plus common filesystem commands, and the full list is more than it sounds: mkdir, touch, rm, rmdir, mv, cp and sed. that is anthropic's own enumeration on the permission modes page (Anthropic, Claude Code documentation, accessed 15 sep 2026).
the guardrails are real. auto-approval applies only to paths inside your working directory or your additional directories, writes to protected paths like .git and .claude still prompt, and removals targeting a critical path are never auto-approved in any mode, bypass included. but "accept edits" reads to most people as "accept edits," and a mode that silently approves rm inside your project folder is worth knowing about before you leave it running.
this is the same lesson as keeping ai from making mistakes on your own data: the failure is rarely the model doing something wild. it is a setting that was looser than you pictured.
what changed on september 14, 2026
claude code v2.1.271 went out on 14 september 2026 and tightened three things about auto mode specifically. the version's publish timestamp comes from the npm registry entry for the claude code package; the changes themselves are listed in anthropic's changelog, which carries no dates of its own.
first, bash, powershell and monitor gained a per-command allowed_domains in auto mode with sandboxing. the hosts a command needs are now reviewed together with that command and opened for it alone, and other hosts are refused. that is narrower than a session-wide allowlist.
second, inline shell commands inside a skill or a slash command now follow default-mode permission rules instead of going to the classifier. a command no rule decides on runs as a reviewed tool call. if you ship skills to other people, that is the bullet to read twice.
third, a subagent now reports back to its caller through a dedicated hand-back call that the safety classifier reviews, rather than having its last message reviewed after the fact.
none of this changes which six modes exist. it changes where auto mode's edges sit, and all three move in the same direction, which is the useful signal.
how to pick your mode, in four steps
- check what mode you are actually in. read the status bar before you read anything else. manual shows a pause marker; accept edits, auto, dont ask and bypass each show their own label. shift+tab cycles.
- make the folder recoverable first. work inside a git repository with your changes committed. the mode decides what happens without asking. version control decides how cheaply you undo it. this single habit does more than any mode choice.
- match the mode to the job, not to your patience. manual or plan for unfamiliar code and anything client-facing. accept edits when you will genuinely read the diff. auto for long work whose direction you trust.
- write down the rules you never want reconsidered. deny rules block in every mode, bypass included. the handful of things that must never happen belong in a deny rule or a PreToolUse hook, not in a mode and not in a prompt.
this is a different dial from effort
permission mode decides whether claude asks. effort level decides how hard it works on each reply. they are independent, and people confuse them because both feel like a single "how much claude" slider. turning effort up does not make claude more cautious, and dropping to manual mode does not make it think less. i covered the other dial in which claude effort level you should actually use.
there is a third layer underneath both: the bash sandbox and whatever isolation you run claude code inside. the mode decides whether an action needs your approval. the sandbox decides what that action can reach once it runs. they combine, and anthropic treats them as separate controls for a reason.
the takeaway
the question is not whether to trust claude code. it is which of six documented boundaries matches the job in front of you. check your status bar, because on pro, max and team plans you start in auto mode whether or not you chose it. commit your work before you start, so the worst outcome is a diff you revert. keep manual and plan for the folders that hold something you cannot replace, and keep bypass for a container. then put the rules that must never break into deny rules and hooks, where nothing claude reads can argue with them.
common questions
is it safe to let claude code run commands on my computer?
it depends entirely on the permission mode, and the mode is yours to set. in manual mode claude reads files freely and asks before anything else. in auto mode a separate classifier model reviews each action first and blocks a published list of categories, including downloading and executing code, production deploys, force push and mass deletion. bypass permissions skips those prompts, and anthropic says to use it only inside a container or vm. run claude code in a folder that is under version control, and the worst case is a diff you can revert.
what permission mode does claude code start in by default?
on pro, max and team plans, in a terminal or through the vs code extension, the built-in starting permission mode is auto mode. on an enterprise plan, with a claude console api key, in claude -p runs and on the agent sdk, sessions start in manual mode instead. the built-in auto default needs claude code v2.1.228 or later on macos, linux and wsl, and v2.1.233 or later on native windows. on earlier versions the built-in default is manual.
what is the difference between auto mode and bypass permissions in claude code?
auto mode removes the prompts but keeps a reviewer: a separate classifier model checks each action and blocks anything that escalates beyond what you asked for, targets infrastructure it does not recognise, or looks driven by hostile content claude read. bypass permissions removes the review as well. it also drops the protection on paths like .git and .claude. anthropic's own guidance is to use bypass permissions only in isolated environments like containers or vms.
can claude give itself more permissions by reading my CLAUDE.md file?
no. anthropic's documentation states that permission rules are enforced by claude code, not by the model, and that instructions in your prompt or CLAUDE.md shape what claude tries to do but do not change what claude code allows. to grant or revoke access you have to use the /permissions command, the permission rules in a settings file, a permission mode, or a PreToolUse hook. that separation is what makes the mode a real boundary rather than a request.
want the guardrails set up once, properly?
the ai builder toolkit is a set of claude skills you install and run, with the permission rules and hooks already written in, so the jobs you repeat every week run the same way every time. no course, no call.
see the toolkitworking out your own setup alongside other people beats doing it alone. the ai builders lounge is where the weekly builds happen.
or just follow along. new field notes most weeks on x, instagram, and tiktok.