You know the rhythm. Claude Code suggests an edit — you hit approve. It wants to run dotnet build
— approve. Then dotnet test
— approve. It reads a file — approve. Another edit — approve. A refactoring session turns into a clicking exercise.
I've caught myself approving commands without even reading them. At that point, the permission system isn't protecting me. It's just slowing me down.
Auto Mode fixes this.
Auto Mode is a permission mode in Claude Code that lets Claude execute actions without asking you first. But unlike --dangerously-skip-permissions
(which disables all safety checks), Auto Mode runs a background classifier that reviews every action before it executes.
Think of it as a security guard who knows your project. It waves through your daily routines — editing files, running builds, executing tests — but stops anything that looks like it could do real damage. A dotnet build
? Fine. A curl | bash
from an untrusted URL? Blocked.
The classifier runs on Claude Sonnet 4.6 as a separate model call. It sees your conversation and the pending action, but not the raw tool results — so hostile content in a file or web page can't trick it into approving something dangerous.
A typical .NET workflow with Claude Code goes like this: you ask Claude to refactor a service class, add unit tests, and run the test suite. That's easily 15-20 permission prompts in a session. Edit the interface, approve. Edit the implementation, approve. Create the test file, approve. Run dotnet test
, approve. Fix a failing test, approve. Run tests again, approve.
With Auto Mode, that entire flow runs uninterrupted. Claude edits your files, runs dotnet build
, executes dotnet test
, reads the output, fixes what's broken, and runs the tests again. You watch the progress, review the results, and step in only when you disagree with the direction.
This is especially powerful for:
Read
call. Auto Mode lets Claude explore freely.Auto Mode trusts your working directory and your repo's configured remotes. Everything else is treated as external until you tell it otherwise.
Allowed by default:
dotnet build
, dotnet test
).env
files and using credentials with their matching APIsBlocked by default:
curl | bash
)main
The blocked list is sensible. These are exactly the actions where you'd want a human in the loop — even if you were running the commands yourself.
One thing to keep straight: the classifier only judges what Claude runs in your terminal. When Claude takes over your mouse and keyboard, approval works on a different track entirely — per app, per session, granted through macOS instead of your permission mode.
Auto Mode requires a Team, Enterprise, or API plan (not Pro or Max), Claude Sonnet 4.6 or Opus 4.6, and the Anthropic API provider. If you're on an eligible plan, enable it with:
claude --enable-auto-mode
After that, Auto Mode joins the Shift+Tab
cycle. You press Shift+Tab
to move through default
→ acceptEdits
→ plan
→ auto
. The status bar shows when Auto Mode is active.
You can also set it as your default mode in your settings:
{
"permissions": {
"defaultMode": "auto"
}
}
In VS Code, click the mode indicator at the bottom of the prompt box — Auto Mode appears once your admin has enabled it.
Auto Mode isn't a black box. When the classifier blocks an action, you see a notification. Blocked actions appear in /permissions
under the "Recently denied" tab, where you can press r
to retry with manual approval.
If the classifier blocks 3 actions in a row or 20 total in a session, Auto Mode s and Claude Code goes back to prompting. Approving a prompted action resumes Auto Mode. This is a safety net — if something is consistently getting blocked, there's probably a reason.
In practice, I rarely hit these limits. The classifier is good at understanding what's routine and what's risky. When it does block something, it's usually because I'm doing something genuinely unusual — like pushing to a remote I haven't used before.
If the classifier blocks actions that are routine for your team — say, deploying to a staging environment or writing to a specific S3 bucket — your admin can configure trusted infrastructure:
{
"autoMode": {
"environment": [
"Trusted staging: deploy.staging.example.com",
"Trusted bucket: s3://our-staging-bucket"
]
}
}
This goes in your settings.json
(not the shared project settings, for security). The classifier uses these hints to understand what's normal for your setup — the same file where the rest of your harness configuration for a real .NET codebase lives.
Claude Code gives you a spectrum of permission modes:
| Mode | What it does | When to use it |
|---|---|---|
default |
||
| Asks for everything | Sensitive work, getting started | |
acceptEdits |
||
| Auto-approves file edits only | Quick iteration with manual build control | |
plan |
||
| Read-only, proposes changes without making them | Exploring before committing to changes | |
auto |
||
| Auto-approves with background safety checks | Long sessions, TDD, refactoring | |
bypassPermissions |
||
| No checks at all | Isolated containers only |
For most .NET development, I switch between acceptEdits
and auto
. When I'm building a new feature and want to stay hands-on, acceptEdits
is enough. When I'm in a refactoring session or running TDD cycles, Auto Mode saves me from clicking approve on the same dotnet test
command for the fiftieth time. And when I want Claude to think about a change before it's allowed to make one, plan mode is the opposite end of the same dial.
Be clear about what Auto Mode isn't, though. It removes prompts; it doesn't add checks. A hook that builds after every edit fires no matter which mode you're in — that's the layer that actually stops something, and it doesn't depend on you noticing.
Next time you start a refactoring session or a TDD cycle, launch with claude --enable-auto-mode
and press Shift+Tab
until you see the auto indicator. Then give Claude something meaty — refactor a service, add tests for an untested class, rename a concept across your solution — and sit on your hands.
Don't watch the stream. Go do something else for ten minutes and come back to the diff. git diff
shows exactly what changed and git checkout .
undoes all of it, so the downside is capped at those ten minutes.
Here's what to check when you come back: how many of the commands it ran would you have approved without reading them? If the honest answer is "nearly all of them", you now know what those permission prompts were costing you. If a few made you nervous, that's worth knowing too — it tells you which corners of your repo need a guardrail before you hand over the wheel.
Originally published at renedekkers.nl.