Claude Code's New Auto Permission Mode — Fewer Prompts, Smarter Guardrails

So a couple of weeks ago I wrote about sandboxing in Claude Code and how it hacks away at the constant approve/deny prompts by putting Claude inside OS-level boundaries. That was a solid step forward — but Anthropic clearly weren’t done, because alongside the Opus 4.7 release they’ve shipped a brand new permission mode called auto which comes at the same problem from a completely different angle.

Where sandboxing says “anything inside these boundaries just happens,” auto mode says “anything the model decides is safe just happens.” It’s a subtle but pretty big shift and it’s worth understanding what’s going on under the hood before you flip it on.

What is auto mode, actually? #

Auto mode is a new permission mode that auto-approves tool calls — file edits, bash commands, network requests, the lot — but runs each one through a background safety classifier first. The classifier looks at what Claude is about to do, cross-references it against what you actually asked for, and then either lets it through, blocks it, or falls back to the normal permission prompt.

Anthropic describe it as a research preview which is worth flagging up front. It’s not the new default and the docs themselves say: “Auto mode is a research preview. It reduces prompts but does not guarantee safety.” So it’s very much a tool for specific situations rather than a “turn it on and forget about it” setting.

Here’s how it sits alongside the existing modes:

So auto sits between acceptEdits and bypassPermissions — broader in scope than accepting edits but with actual intelligence behind it rather than a blanket “yes to everything.”

What the classifier approves (and what it blocks) #

This is the interesting bit for me. The classifier has a default understanding of what’s risky and what isn’t, and it gets a lot right out of the box.

Allowed by default:

• Local file operations inside your working directory
• Installing declared dependencies (npm, pip, cargo, etc.)
• Reading .env files and sending credentials to the APIs they match
• Pushing to the current branch

Blocked by default:

• Piping remote scripts into a shell (curl | bash and friends)
• Sending sensitive data to unexpected external endpoints
• Production deploys and migrations
• Mass deletion on cloud storage
• Force push, or pushing to main
• Irreversibly destroying files that existed before the session started

That last one is really nice. It means Claude can delete files it created during the session without bothering you, but if it goes anywhere near something that was already there before you started? You get asked.

How it actually decides #

The classifier isn’t just pattern-matching on commands. It looks at:

• User intent — what you asked for in the conversation
• Action scope — does this action match the scope of what was requested?
• Destination — is this going somewhere trusted or somewhere unknown?
• Escalation — is Claude quietly doing more than you asked?

The really cool bit is that boundaries you state in plain English actually get enforced. If you tell Claude “make the changes but don’t push anything” or “wait for me to review before committing” the classifier will hold those as hard rules for the rest of the session. That’s a lot more natural than writing out a denylist in settings.json.

There’s also a circuit breaker built in. If the classifier blocks three actions in a row, or twenty across a session, auto mode pauses and drops back to normal prompting. The idea being that if the model is repeatedly trying to do risky things, something has probably gone sideways and you should be back in the loop.

Turning it on #

Easiest way is just to flip it on for a single session:

claude --permission-mode auto

Or if you want it as your default for a particular project, pop it in .claude/settings.json:

{
  "permissions": {
    "defaultMode": "auto"
  }
}

You can also cycle through modes during a session with Shift+Tab which is handy if you want to drop into plan to explore then back into auto to actually do the work.

A few things to be aware of:

• It’s not on every plan. Auto mode is available on Team, Enterprise and API (with Sonnet 4.6, Opus 4.6 or Opus 4.7), and on Max with Opus 4.7. It’s not on Pro, Haiku, or via Bedrock / Vertex / Foundry.
• Team and Enterprise admins have to enable it first in the admin settings before individual users can switch it on.
• Denied actions show up in /permissions under a “Recently denied” list. You can press r on one to retry it with manual approval if you think the classifier got it wrong.

Auto mode and sandboxing — do I need both? #

This is the question I had straight away, and the answer is yes, they complement each other nicely. They’re operating at different levels:

• Sandboxing is OS-level. Seatbelt on macOS hard-blocks any process Claude spawns from touching files or hosts outside the allowed set. It doesn’t care why something’s happening, it just enforces the rules.
• Auto mode is model-level. It looks at the intent of the action and decides whether it matches what you asked for.

Think of sandboxing as the walls of the room and auto mode as a colleague sat next to you going “hang on, are you sure about that?” whenever Claude reaches for something dodgy. You want both. The walls stop a truly broken action from escaping, and the classifier catches the subtler stuff like “this command is technically inside the sandbox but it’s not actually what the user asked for.”

With sandbox enabled and autoAllowBashIfSandboxed on (which is the default), sandboxed bash commands don’t even go through the classifier — they just run. So the two layers coordinate rather than doubling up the work.

There’s also a skill for that — /fewer-permission-prompts #

Anthropic actually shipped a third piece around the same time that’s worth knowing about, because it chips away at the same problem from a completely different angle. It’s a bundled skill called /fewer-permission-prompts (you might also see it as /less-permission-prompts in some builds — same idea either way).

Where auto mode uses live judgement from the model, this skill takes a much more old-school approach. It scrolls back through your session transcripts, works out which commands you’ve been approving over and over, and proposes adding them to the permissions.allow list in your project’s .claude/settings.json. No classifier, no live risk assessment — just a plain static allowlist based on what you’ve actually been doing.

You invoke it like any skill:

/fewer-permission-prompts

The focus is deliberately narrow — it only looks at read-only bash commands and MCP tool calls. Things like git status, ls, grep, npm test, MCP read operations — the stuff that shows up ten times a session and that you’re never, ever going to say no to. Once those are in the allowlist they just stop prompting.

Why have both auto mode and the skill? #

These two features are going after the same prompt-fatigue problem but they’re complementary rather than redundant:

• Auto mode is judgement-based. The classifier looks at every action in real time with full conversational context.
• /fewer-permission-prompts is rule-based. Specific safe commands get baked into a static allowlist, derived from your actual past sessions.

In practice I’d use both. The static allowlist clears out the truly repetitive stuff — reads, statuses, test runs — before anything else has to think about it. Auto mode then handles the broader surface where context actually matters (edits, installs, pushes, anything with side effects). The two layers stack nicely: fast path for known-safe rules, classifier for everything else.

Worth flagging that the skill sticks to read-only commands for a reason. It’s tempting once you see the allowlist to start hand-adding destructive commands to get rid of yet more prompts — don’t. That’s exactly what auto mode is built for, because destructive commands are where context matters the most. Keep the allowlist boring and let the classifier do the interesting work.

When I’d think twice about using it #

The Anthropic guidance is pretty clear and I agree with it — auto mode is for tasks where you trust the general direction but want the friction taken out. It is not a substitute for human review on:

• Anything touching production infrastructure
• Irreversible operations (database migrations, destructive cloud ops)
• Work where the classifier doesn’t really have the context to judge risk (novel architectures, niche tooling)

For day-to-day “refactor this module,” “add tests for this function,” “update these docs” kind of work? Auto mode is genuinely great. For “deploy this to prod” or “run this migration against our staging DB”? I’d still be in default mode with my finger hovering over the approve button.

And as always, git hygiene is your safety net. Commit before a big session, work on branches, review diffs before merging. None of that changes just because the permission flow is smoother.

Is it worth it? #

For me, yeah — sandboxing cut the prompts down, /fewer-permission-prompts clears out the repetitive reads, and auto mode handles the wider surface with actual judgement on top. That stack feels like the right direction: OS-level walls for the hard boundaries, a static allowlist for the obvious no-brainers, model-level review for the judgement calls, and a human in the loop for the stuff that actually matters.

It’s still a research preview so I’d expect the behaviour to evolve, and I’d keep half an eye on the changelog for tweaks to the classifier’s defaults. But having used it for a bit, going back to classic default-mode prompting feels noticeably more laborious than it did before.

Give it a go on a low-stakes project first — start a session with --permission-mode auto, try some typical work, and see how the classifier handles what you throw at it. Keep /permissions open if you want to watch what it’s denying. And if something gets blocked that shouldn’t have been, that’s what the retry flow is for.