Auto-Approve in Claude Code: Auto Mode, Allow Rules and Risks

You can make Claude Code stop asking before commands, but “allow all” is the wrong setting for almost everyone. There are three routes to fewer prompts. Auto mode lets a separate classifier model approve routine actions and block risky ones, and on current versions it is where interactive sessions start. Allow rules in settings.json approve specific commands you trust, such as Bash(npm run test *), in any mode. And --dangerously-skip-permissions turns the checks off entirely, which Anthropic says belongs only in an isolated container or virtual machine. Use the first two together, keep a short deny list, and keep the third for throwaway environments.

The six permission modes

A permission mode sets what Claude may do without asking. The permission modes documentation↗ (opens in a new tab) lists six:

• default, labelled Manual: only reads run without a prompt. Every edit, and every command outside a built-in read-only set, asks first.
• acceptEdits: file edits and common filesystem commands (mkdir, touch, mv, cp, rm and a few others) run without asking, but only inside your working directories. Other commands still prompt.
• plan: Claude reads and explores and writes a plan, but does not edit your source until you approve it. Claude Code plan mode covers it.
• auto: everything runs without a prompt, after background safety checks by a classifier model.
• dontAsk: anything that would prompt is denied instead. Only reads and pre-approved tools run, which suits CI and scripts.
• bypassPermissions: everything runs, with no checks. For isolated containers and VMs only.

Press Shift+Tab to cycle modes during a session, start in one with claude --permission-mode acceptEdits, or set a default with permissions.defaultMode in a settings file. Two traps: auto and bypassPermissions do not take effect from a project’s .claude/settings.json or .claude/settings.local.json, so a repository cannot switch them on for you; set auto in ~/.claude/settings.json if you want it as your own default. And dontAsk never appears in the Shift+Tab cycle; it is set with the flag.

Auto mode: fewer prompts with a second opinion

With Claude Code v2.1.283 or later, auto mode is the built-in starting mode for interactive terminal and VS Code sessions, provided your model supports it and your organisation has not switched it off. File reads, and edits inside your working directory other than to protected paths, run without a classifier check. Everything else goes to the classifier, which sees your messages, Claude’s tool calls and your CLAUDE.md, but not tool results, so text hidden in a file or web page cannot argue with it directly.

• Blocked by default: downloading and running code such as curl | bash, sending sensitive data to outside endpoints, production deploys and migrations, force pushes, commands that discard uncommitted work such as git reset --hard, and granting access or changing shared infrastructure, among others.
• Allowed by default: local file work in the working directory, installing dependencies your lock files declare, read-only HTTP requests, and pushing to the repository you are in, including its default branch. A branch named as a deploy target, such as production or gh-pages, is judged on its own terms.
• Broad allow rules are set aside. On entering auto mode, rules such as Bash(*), wildcarded interpreters like Bash(python*), package-manager run commands and Agent allow rules are dropped until you leave it; narrow rules such as Bash(npm test) stay.
• It falls back to asking. After 3 blocks in a row, or 20 in a session, auto mode pauses and Claude Code prompts you again.
• What you say counts, briefly. “Don’t push” in the conversation is treated as a boundary, but compaction can summarise that message away. For a boundary that must hold, write a rule.

Anthropic is explicit that auto mode reduces prompts but does not guarantee safety. The default that most surprises people is the push: if you want to look before anything leaves your machine, add ask rules, which force a prompt even in auto mode. The auto mode configuration guide↗ (opens in a new tab) recommends exactly that for git push and gh pr create, and explains how administrators describe trusted repositories and services in autoMode.environment so routine work stops being blocked.

Allow, ask and deny rules

Rules sit on top of the mode and are the precise tool. According to the permissions reference↗ (opens in a new tab), they are evaluated deny first, then ask, then allow, and the first match wins, so an allow rule can never carve an exception out of a deny. A deny at any settings level cannot be allowed back by another level, and managed settings outrank everything. The format is Tool or Tool(specifier):

• Bash(npm run build) matches that exact command. Bash(npm run *) matches any npm script. Put the * after the subcommand: Bash(git log *) allows only git log, while Bash(git *) allows every git command.
• The space before a trailing * matters. Bash(ls *) matches ls -la but not lsof; Bash(ls*) matches both.
• Compound commands are split. Bash(npm test *) does not approve npm test && curl evil.sh; each part must match on its own.
• Read(./.env) and Edit(/src/**/*.ts) use gitignore-style paths. A single leading / anchors at the settings source (the project, for project settings), // is the filesystem root, and ~/ is your home directory.
• WebFetch(domain:docs.example.com) approves fetches from one host.
• mcp__github or mcp__github__* covers every tool from a server; mcp__github__get_* covers only its get_ tools. An allow glob must start with the server’s name; mcp__* in allow is ignored.
• Agent(Explore) controls whether Claude may use a named subagent.

When you answer a prompt with “Yes, and don’t ask again”, Claude Code saves the rule to .claude/settings.local.json at the repository root, so it applies to later sessions in that repository. /permissions shows every rule and the file it came from. Two cautions: tools that run their argument as a command, such as npx or docker exec, make Bash(npx *) an allow-anything rule; and a rule matches the command as written, so Bash(git push *) does not catch git -C . push. Rules steer the usual case. The boundary that holds for any form of a command is the sandbox, covered in security controls for AI coding agents.

The skip-permissions flag, and when to use it

claude --dangerously-skip-permissions is the same as --permission-mode bypassPermissions. It skips prompts and safety checks, including writes to protected paths such as .git, .claude, .vscode, shell profiles and .mcp.json, which no other mode auto-approves. Deny rules still apply and explicit ask rules still prompt; allow rules have no effect because everything is already allowed. It offers no protection against prompt injection.

• Use it only where the damage stops at the edge of the box: a container, a VM, or a dev container without internet access. Anthropic’s dev container setup↗ (opens in a new tab) runs Claude Code as a non-root user for this purpose.
• On Linux and macOS it refuses to start as root or under sudo.
• --allow-dangerously-skip-permissions adds the mode to the Shift+Tab cycle without starting in it.
• An administrator can remove the option by setting permissions.disableBypassPermissionsMode to "disable" in managed settings; permissions.disableAutoMode does the same for auto mode.

On your own machine, auto mode gives you most of the speed with a check on each risky action, and for an unattended script --permission-mode dontAsk with an explicit --allowedTools list denies anything you did not foresee instead of running it. How to automate Claude Code tasks builds that out.

What never to auto-approve

• Bash(*), or wildcarded interpreters such as Bash(python *) and Bash(node *): each one approves arbitrary code.
• Pushes, force pushes, releases and publishing: git push, npm publish, anything that deploys. Put these under ask, and force pushes under deny.
• Deletion outside a build folder, and anything that rewrites history.
• Network tools such as curl and wget, which can send your code anywhere. Prefer WebFetch(domain:...) rules for the hosts you need.
• Reading secrets: deny .env files and credential folders outright.
• MCP tools that change shared systems for other people: deletes, merges, messages. Approve the read tools, and ask on the writes.

A starter settings file

This .claude/settings.json is a reasonable first commit for a Node repository whose team uses a fenbs board over MCP. It approves tests, lint and local commits, lets Claude read the board and comment, asks before anything leaves the machine or deletes a task, and keeps secrets out of reach. Adjust the commands to your stack.

{
  "permissions": {
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "mcp__fenbs__fenbs_get_*",
      "mcp__fenbs__fenbs_list_*",
      "mcp__fenbs__fenbs_comment"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)",
      "Bash(npm publish *)",
      "mcp__fenbs__fenbs_delete_item"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force *)"
    ]
  }
}

The board is a second layer that does not depend on these rules. When you connect Claude Code to fenbs with /mcp, you choose the scopes the assistant gets: read, write and comment. Start with read and comment, so Claude can report on tasks but not move them, and add write once you trust what it reports. Its access can never exceed your own role, every change it makes is recorded as “Claude via” you, and revoking the token in Settings stops it without signing you out. Roles and permissions for humans and AI agents explains how that works.