Using Auto Mode in Claude Code safely, in 10 steps without suicide commands

If you've been using Claude Code for a while, you know the moment: you're sitting there just pressing Enter, because every file change and every bash command wants to be confirmed individually. Auto Mode takes exactly that off your hands. Claude approves its own tool calls, while in the background a safety check verifies whether the action fits what you actually wanted. Sounds like full throttle with no brakes. But it isn't, if you understand what the mode blocks and which two nets you stretch underneath it yourself.

Important up front: Auto Mode isn't a mode you slide into automatically. The starting mode of every session stays Manual, that is, asking before every action. You switch Auto Mode on deliberately, via Shift+Tab in the session or permanently via defaultMode: "auto" in the settings. It's now widely available, but you don't treat it as set-and-forget for production repos. We'll go through ten steps. First the classification, then turning it on, then the protective mechanisms, then your own net underneath, and at the end the question of when to turn it on at all.

1. Understand what Auto Mode really does

Auto Mode is one of several permission modes in Claude Code. The description in the official docs is short and precise: it approves tool calls automatically, with safety checks in the background that verify the actions fit your request. That's the crucial difference from bypassPermissions. Bypass simply doesn't ask anymore. Auto doesn't ask either, but checks every action against what you actually commissioned.

In practice: you say "build me the login form", Claude edits files and runs npm run build without asking. But if Claude suddenly starts dropping a database or throwing away your local Git history, the background check kicks in. That's not a free pass, it's a different kind of brake.

2. Keep the map of modes in your head

Before you turn Auto Mode on, place it. Claude Code has several permission modes, set via defaultMode in the settings.json. default asks on the first use of each tool. acceptEdits accepts file edits and harmless filesystem commands like mkdir, touch, mv, cp automatically, but only for paths in your working directory. plan is Plan Mode, so read-only and read-only shell, no changes to your code. auto is our topic. bypassPermissions skips all prompts except forced ask rules, and even there rm -rf / stays as an emergency brake with a prompt. dontAsk flips it around and refuses everything that wasn't allowed beforehand.

So the right mental order from cautious to bold is: plan, default, acceptEdits, auto, bypassPermissions. Auto sits well forward in the red zone, but not all the way. If you only want file edits without confirmation and don't need bash authority, you're often better served with acceptEdits.

3. Turn Auto Mode on deliberately

You switch the mode within a session via the permission-mode toggle in the interface. Permanently you set it via defaultMode in your user settings, for example:

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

My advice, with one important nuance: Auto Mode can only be activated permanently via your user settings (~/.claude/settings.json). A defaultMode: "auto" in a project or local settings file is deliberately ignored by Claude Code, precisely so that a foreign repo you clone can't slip the mode onto you. If you don't want it on all the time, leave the user settings on Manual and instead switch per session via Shift+Tab. A globally set Auto Mode bites you exactly when you switch into a foreign or production repo and have forgotten about it. For most people, per-session switching is therefore the safer choice.

4. Don't mistake the background check for magic

The safety check verifies whether an action fits your request. That's good, but it's a heuristic, not a contract. If your request itself was phrased dangerously ("clean up the repo, delete what's not needed"), then a destructive command may well fit your brief and gets waved through.

Consequence for your prompt style in Auto Mode: phrase it tightly. "Build feature X in file Y" is better than "make the project clean". The vaguer your brief, the greater the leeway the check lets through as legitimate. The mode is as safe as your instruction is precise.

5. Know what Auto Mode blocks anyway

Here it gets concrete, and these are verified rules from the changelog. Auto Mode blocks destructive Git commands if you haven't explicitly said that local work may go. Specifically affected are git reset --hard, git checkout -- ., git clean -fd and git stash drop. git commit --amend is blocked if the commit wasn't made by the agent in this session, so nobody rewrites foreign history on you. And terraform destroy, pulumi destroy as well as cdk destroy are locked as long as you haven't named the specific stack.

That's the built-in list of suicide commands the mode catches for you. In practice that means: Auto Mode may build and test, but your uncommitted state and your infrastructure are protected against the most obvious accidents. Still, don't rely on that alone, which is what Step 6 is for.

6. Stretch deny rules as a hard net underneath

The protection list from Step 5 is fixed. You build your own net with deny rules in the permissions. Important to know: rules are evaluated in the order deny, then ask, then allow. The first match wins. So a deny rule always trumps, even against a more specific allow rule. That makes deny your most reliable tool.

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Read(./.env)",
      "Bash(docker system prune *)"
    ]
  }
}

A detail many overlook: a deny rule with a pure tool name like Bash removes the tool completely from Claude's context, Claude doesn't see it at all anymore. A deny rule with a pattern like Bash(rm *) leaves the tool there and only blocks the matching calls. For Auto Mode you usually want the pattern variant, so Claude can keep running normal commands and only the dangerous ones get stopped.

7. Isolate Auto Mode in a worktree

The best net is spatial separation. If Auto Mode runs in its own Git worktree, an action that slips through can at most hit that worktree, not your main branch. You create a worktree, start Claude there in Auto Mode, and at the end you deliberately merge only what's clean. If something goes wrong, you delete the worktree and your original was never touched.

How the setup works in detail is in the playbook Claude Code with Git Worktrees and in Parallel Claude sessions with worktrees. The combination of Auto Mode plus worktree is for me the only configuration in which I run Auto Mode in a serious repo at all.

8. The sandbox as a second separation layer

The worktree separates the Git risk. The bash sandbox separates the system risk. When Claude approves its own bash commands in Auto Mode, you want those commands to run in a restricted environment and not reach your whole system unhindered. The setup for that is laid out step by step in the playbook Setting up the Claude Code bash sandbox.

Worktree plus sandbox plus deny rules is the triple safeguard. Each layer catches a different kind of error. That sounds like a lot, but it's set up once and then permanently your standard environment for unsupervised work.

9. Forbid Auto Mode for others entirely

If you work in a team or secure an environment where nobody should use Auto Mode, there's a hard switch for it. In the settings you set permissions.disableAutoMode to "disable". Analogously, permissions.disableBypassPermissionsMode locks the bypass mode. This is most effective in Managed Settings, because there it can't be overridden by individual developers.

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

That's the right answer when someone asks "how do I stop a junior from accidentally switching off all the caution". Don't regulate it via trust, via Managed Settings.

10. Know when to turn Auto Mode on and when not

Auto Mode is strong for tasks with many small repeated steps in a repo you trust. A larger refactor with a clear pattern, getting the test suite green, carrying a migration through many files. There it saves you real hassle and the background check plus your deny rules catch the crude blunders.

Hands off, by contrast, with production code without a worktree, with vague briefs, with anything that touches infrastructure or databases, and with foreign repos whose contents you can't survey. And because Auto Mode takes the approvals off your hands: keep an eye on the sessions at first rather than doing something else on the side. You build trust by watching, not by looking away.

What's next

If Auto Mode is too bold for you, Plan Mode is the calm counterpart, there Claude only reads and suggests before anything happens. Read Using Plan Mode properly for that. If the topic of security interests you in general, Confused Deputy Audit for Claude Code is the next step. And if you want to watch the costs while working unsupervised, you'll find the routine in Claude Code Cost Controls. If you don't yet have a clean Git setup as a seatbelt, the best place to start is the Git for AI Quickstart, because without commit discipline the best permission system does you little good.

Source

• Permission modes and deny-rule order: Configure permissions, Claude Code Docs
• Auto Mode protection rules for Git, Terraform, Pulumi, CDK: Claude Code Changelog