What Is Auto Mode in Claude Code (And Should You Leave It On)?

Kristoffer · August 12, 2026 · 9 min read

Claude Code auto mode lets Claude edit files and run most shell commands without stopping to ask you first, and Anthropic has made it the default for new sessions. If you opened Claude Code this week and noticed it stopped asking permission before doing things, that's why. Here's what actually changed on your screen, what it still stops for, and the setup that makes it safe to leave on when you can't read the code it's writing.

The short answer: what auto mode does

Auto mode means Claude Code carries out file edits and most terminal commands inside your project without pausing for you to press accept each time. It still stops and asks before actions that are hard to undo or that reach outside your project - things like deleting files above your working folder, pushing to a remote repo, or installing something globally. "Auto" is not "unrestricted."

Leave it on if you're mid-build on a project that's in git and has no production keys in it. Turn it off if this is your first hour in a codebase you don't understand yet, or if the task touches auth, payments or anything live.

What changed this week, exactly

Before this change, the loop looked like this: you gave Claude an instruction, it proposed an edit, you read a diff you probably didn't fully understand, you pressed accept, it proposed the next one. For a feature that touched six files, that was forty or fifty approvals.

Now Claude proceeds and reports back. You see what it did after it did it, summarised at the end of the turn, rather than a stream of yes/no prompts before each step. The change landed with the recent Claude Code releases, and because Claude Code updates itself quietly in the background, plenty of people will find it switched on mid-project with no announcement they ever read. You didn't break anything. The default moved.

If you want the canonical wording, run /release-notes inside Claude Code and read the entry for your version rather than trusting a blog post - including this one - on the details.

What auto mode will still ask you about

This is the part that stops beginners panicking. Auto mode is scoped to your project folder and to actions that are recoverable. It will still interrupt you for things like:

• Commands that delete files, or that operate on paths outside your working directory
• git push, and anything else that writes to a remote
• Installing packages globally, or commands that need elevated permissions
• Requests to network endpoints it hasn't seen before
• Edits to files outside the folder you opened Claude Code in

The exact list varies with your version and your own settings, so don't memorise mine. Type /permissions and read what your install actually allows. That command is the source of truth, and it takes ten seconds.

What auto mode does not protect you from is bad instructions. If you tell it to delete all the test files, it will happily delete all the test files inside the project. The guardrails are about blast radius, not about judgement.

How to switch modes: the three things to type

There are three controls worth knowing, and that's genuinely all.

1. Shift+Tab cycles the permission mode for the current session. Press it repeatedly and you'll rotate through the available modes - typically plan mode, the ask-every-time behaviour, and auto mode. This is the one you'll use ninety percent of the time.
2. The status line at the bottom of the terminal tells you which mode you're in. Look at it before you send a big prompt. If you can't tell what mode you're in, you're about to be surprised by something.
3. /permissions opens the full settings view - which tools are allowed, which are denied, and what the default mode is. This is where you make a preference stick across sessions instead of pressing Shift+Tab every time you launch.

If you'd rather every new session in a project start in plan mode, set the default in that project's Claude settings file rather than retyping it. /permissions will show you where those settings live for your version. Set it once per project, forget about it.

One note on how to turn off auto mode in Claude Code permanently: there isn't a global "off" switch you flip once and never think about. There's a default mode, and there's per-session cycling. Set the default to whatever you want your worst-attention-day behaviour to be, and use Shift+Tab to speed up when you're actually watching.

When Claude Code auto mode is genuinely better for a beginner

The argument against auto mode assumes you were reading those diffs. Be honest: were you? If you've never written code, pressing accept on a 60-line React diff taught you nothing. It just added four seconds and a small dose of anxiety to every step of the build.

Auto mode is clearly better for:

• Multi-file feature builds. "Build the settings screen and wire it to the database" touches a component, a route, a schema file and probably a type definition. In ask-every-time mode that's a dozen approvals for one coherent job. In auto mode it finishes in one pass and you look at the result in the browser, which is the only review you were ever qualified to give.
• UI iteration loops. "Make the cards bigger, move the button to the right, use the brand colour." Twenty tiny edits where the feedback is visual and instant.
• Running tests and fixing failures. Claude runs the suite, reads the errors, patches, reruns. Interrupting that loop to approve each attempt is pure friction.
• Project setup. Installing dependencies, scaffolding folders, initialising config. Nothing here is a decision you'd have made differently.

The pattern: auto mode wins when the work is inside the project, reversible via git, and judged by looking at the running app rather than the code. That covers most of what you'll do while following the complete beginner guide to building apps with AI.

When to turn it off and use plan mode instead

Plan mode is the read-only option. Claude reads your files, works out what it would do, and writes you the plan - without changing anything. You approve the plan, then it executes. That's the difference in Claude Code auto mode vs plan mode: one is "go", the other is "tell me first."

Use plan mode for:

• Your first session in a project you didn't build. Including projects you did build but haven't touched in three weeks. Ask it to explain the structure before it touches anything.
• Auth, payments, database migrations and deploy scripts. These are the four places where a confident wrong move costs you real money or real users. Read the plan.
• Any moment you can't describe what the app currently does. If you can't state the current behaviour, you can't tell whether the new behaviour is correct.
• Big refactors. "Restructure the API layer" in auto mode is how you end up with 40 changed files and no idea which one broke the login.

For a beginner's first hour with any new project, plan mode is the right default. You learn what's there, you get a plan in plain English, and you approve it with some idea of what you're approving.

The safety setup that makes auto mode fine when you can't read code

Is Claude Code auto mode safe? It's as safe as your project setup, and the setup takes about five minutes. Do all of this once:

1. Get the project into git and commit before every prompt. This is the whole safety net. If a commit exists, every mistake is one git revert away from never having happened. No commit, no undo.
2. Work on a branch, not main. git checkout -b feature-settings before you start. Then merge when it works and delete the branch when it doesn't.
3. Keep real API keys out of the repo. Use a .env file, make sure .env is in .gitignore, and confirm it's actually ignored before you commit anything.
4. Use test keys while building. Stripe test mode, sandbox credentials, staging endpoints. If a runaway command hits a test key, you've lost nothing.
5. Never point Claude at a production database. Local or staging only while you're building. This is the single rule with no exceptions.
6. Read the summary, not the diffs. After each turn Claude prints what it changed and why, in English. That's the review you're actually equipped to do. Read it every time.

With those six in place, the worst realistic outcome of auto mode is a wasted twenty minutes. Without them, the worst outcome is much more interesting. If something looks off and you can't tell whether it's normal, ask in the community if your session behaves strangely before you keep prompting on top of it.

What to do if auto mode already broke something

Don't prompt your way out of it. Adding more instructions to a confused session usually deepens the hole. Stop, then:

1. Stop the session. Press Escape to interrupt whatever's running.
2. Look at what moved. In a second terminal, or after exiting:

git status
git diff

git status lists which files changed. git diff shows the changes. You don't need to understand the code - you need to see the file names and how much moved.

3. Revert to your last good commit.

git reset --hard HEAD

That throws away all uncommitted changes and puts you back where you were. This is why step one of the safety checklist is committing before every prompt.

4. Or use /rewind inside Claude Code to step the session back to an earlier state if you'd rather not touch git.
5. Restart in plan mode and ask what happened before asking for a fix. Something like: "The login page stopped rendering after the last change. Read the relevant files and tell me what you think broke, without editing anything."

Then re-prompt with a smaller scope. Most auto mode damage traces back to a prompt broad enough that Claude had to guess. "Fix the app" is an invitation to improvise across ten files. "In SettingsPage.tsx, the save button doesn't persist the theme choice - fix only that" gives it one place to work and one way to be wrong. Narrow prompts and frequent commits do more for your safety than any permission setting.

Next step: open your current project, run git status to confirm it's clean, commit if it isn't, then press Shift+Tab and check what the status line says. Know which mode you're in before your next prompt. If you're still assembling your setup, the tools we actually use alongside Claude Code is where to start.