Auto mode becomes the default permission mode for new Claude Code sessions on Pro, Max, and Team plans starting August 14, 2026
A classifier model, Claude Sonnet 5 by default, reviews every action before it runs instead of prompting you for each one
Three blocked actions in a row, or twenty in one session, pause auto mode and drop the session back into manual prompts
I am not switching my own Shopify sessions to it on day one, and here is the actual reasoning, not just caution for its own sake
What Actually Changes On August 14
Anthropic is flipping the default permission mode in Claude Code. Starting August 14, 2026, new sessions on Pro, Max, and Team plans open in auto mode instead of the manual mode most of us have used since day one. If you have already set your own default, whether that is manual, accept edits, or something else, that choice sticks. You only see a one time prompt asking if you want to switch, and you can say no. Anyone on an org managed account keeps whatever their admin configured.
The practical difference is what happens when Claude wants to run a shell command, touch a file outside your working directory, or make a network call. In manual mode, you get a prompt for almost everything outside a read. In auto mode, a separate classifier model looks at the action first and either lets it through or blocks it, without asking you. You can still cycle modes at any point with Shift+Tab, so nothing here is locked in.
I read through the actual documentation on this rather than the summaries floating around, because a permission model change is exactly the kind of thing worth getting right before you flip it on for a store repo. The docs are specific about scope: this is the CLI, the IDE extensions, the desktop app, and claude.ai/code. Cloud sessions already pre approve file edits by default regardless of mode, so the practical shift there is smaller. Auto mode also requires a supported model. On the Anthropic API and Claude Platform on AWS that means Opus 4.6 or later, Sonnet 4.6 or later, or Fable 5. Anything older, including Sonnet 4.5 or Opus 4.5, does not get auto mode at all, on any provider.
For a one person shop running Claude Code daily across sections, scripts, and blog tooling, a change to what runs without asking is not background noise. It is the thing standing between a normal edit and a command I would have wanted to see first.
There is also a quiet detail about who pays for the extra step. Every classifier check adds a small round trip before an action runs. On the plans most solo builders are on, Pro, Max, and Team, that overhead is not billed to you. It only counts toward token usage on Enterprise plans and on accounts running through the Claude API, Bedrock, or similar provider routes. So the safety layer here is not something you are paying extra tokens for on a normal subscription, which removes the one objection I would have actually cared about.
What The Classifier Actually Blocks
The interesting part is not that prompts go away. It is what the classifier is built to catch instead of a human eyeballing every line. Per the documentation, blocked by default includes downloading and running code with something like curl piped into bash, sending data to external endpoints, production deploys and migrations, force pushes, granting IAM or repository permissions, and destructive git operations like reset hard, checkout with a dot, or clean fd, since those are presumed to discard uncommitted work. Writing a live credential into the transcript is blocked. So is merging a pull request nobody approved, or a command that widens what a deploy publishes.
Newer classifier versions extend this further: repointing an API base URL or webhook receiver at a third party host that does not fit the task, changing where a git remote pushes unless you named the new remote, and opening a pull request against a repository you never mentioned. There is also a rule against a recursive forced delete whose target is a shell variable that never appeared anywhere in the visible conversation, because the classifier reads what you and Claude actually discussed, not command output, so it cannot verify an unnamed target.
On the other side, allowed by default covers the ordinary stuff: local file operations in your working directory, installing dependencies already declared in a lock file, reading a .env file and sending its values to the matching API, read only HTTP requests, and pushing to any branch of the repository you are already working in. That last one includes the default branch now, which is a real change from earlier versions that only allowed pushes to branches Claude itself created.
Writes to a short list of protected paths, things like .git, .claude, and shell profile files, are never auto approved in any mode except full bypass. That part did not change.
Subagents get the same treatment, which matters if you run any kind of multi agent setup. The classifier looks at a delegated task before the subagent even starts, so an obviously risky assignment gets caught at spawn time rather than after damage is done. While the subagent runs, every one of its own actions goes through the same rules as the parent session. When it finishes, the classifier reviews the whole action history one more time, and if anything looks off it prepends a warning to the results instead of just handing them back clean. That closes a gap I had not thought about until I read it: a subagent spawned mid session used to inherit whatever mode you set it, and now it inherits the same scrutiny regardless.
Where This Lands For My Own Workflow
I run Claude Code across three different jobs most days: editing Liquid sections, running audit scripts, and writing these blog drafts. Two of those are low stakes. A blog draft is a markdown file in a folder nobody else touches, and I already review every line before it goes anywhere near the manifest. Auto mode there changes almost nothing, since editing files in a working directory was already unprompted in most modes I use.
The Shopify side is different, and it is exactly why the instructions in this repo are explicit about never touching prices, SKUs, or products without a direct decision from me first. A classifier that is very good at catching a force push or a credential leak is still working from patterns, not from knowing that this particular repo has a rule about template_suffix on page creation, learned the hard way after a default template got polluted with content from an entirely different page. That is a repo specific lesson, not a category the classifier is built to police. I would rather keep the extra prompt on anything that reaches an API call outside my own sandbox until I have watched auto mode handle a few weeks of ordinary edits first.
The docs are honest about this too. Auto mode reduces prompts, it does not remove the need to review sensitive operations, and Anthropic says as much directly rather than leaving it implied.
There is a practical middle ground I am actually curious about, which is plan mode. When auto mode is available, plan mode already routes shell commands through the same classifier while Claude is only reading and researching, before it proposes any change. That gets me most of the speed benefit, letting Claude explore a section file or trace a bug without a prompt for every read, while edits still wait for me to look at the plan first. That is closer to how I already work than full auto mode is, so it is probably where I land rather than either extreme.
The Fallback Nobody Talks About
The part of this I actually like most is the circuit breaker. If the classifier blocks the same session three times in a row, or twenty times total, auto mode pauses itself and Claude Code goes back to prompting you like normal. Approving the next prompted action resumes auto mode from there. That is a sane failure mode. It means a session that keeps hitting the same wall does not just sit there retrying forever, and it does not silently downgrade your safety net either, it hands control back.
Anything you say out loud in a session also counts. If you tell Claude not to push, or to wait until you review something before it deploys, the classifier treats that as a block signal even for actions its default rules would otherwise wave through. That boundary lives in the conversation, though, not as a stored rule, so a long session that compacts its earlier context can lose it. If a boundary actually matters, a written deny rule in settings is the durable version of the same idea.
None of this requires action from me right now. My own default mode is already set, which means the one time switch prompt will ask and I can decline it, and I plan to. I will likely turn auto mode on for the parts of my workflow that are genuinely low risk, once I have watched how it behaves on someone else's repo first. For anything that writes to raxxo.shop directly, manual stays manual for a while longer.
Bottom Line
A default permission mode change in a tool I use every working session is worth actually reading about instead of skimming a headline. Auto mode is not reckless. The block list is long, specific, and clearly built from real incidents rather than a general sense of caution, and the three strikes fallback means a stuck session hands control back instead of grinding forward on trust. What it is not, is a replacement for judgment on anything that touches money, customer data, or a live store. I keep my own line where it already was: file edits and drafts can move fast, anything that reaches the Shopify API gets a human in the loop first, permission mode or not. If you run Claude Code daily, the one thing worth doing before August 14 is deciding your default on purpose, since the alternative is having it decided for you by a prompt you might click through without reading.
For more on how I use Claude Code day to day, see why I keep shipping small tools instead of one big product and the check I run on every tool before I call it shipped.
This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)
Top comments (0)