Claude Code Permissions: Six Modes, One Decision (2026)

The flag is called --dangerously-skip-permissions on purpose. Somebody at Anthropic decided the friction of typing that word was worth more than a shorter name, and after you understand what the mode actually turns off, that seems like the right call. Most guides to Claude Code permissions stop at "press Shift+Tab to stop the prompts," which answers the wrong question. The real question is how much of the safety machinery you're switching off at each step, and what still protects you afterwards. Six modes, three rule types, and one list of files that no mode will auto-approve: that's the whole system, and it takes about ten minutes to hold in your head.

The Six Modes, Ranked by How Much They Trust the Agent

Each mode is a different trade between convenience and oversight. The column that matters is what runs without asking you.

One naming quirk causes a lot of confusion, so it's worth getting straight early. The mode that reviews every action is labeled Manual in the CLI, in claude --help, in the VS Code and JetBrains extensions, and in the desktop app. Its config value is default, which is what hooks and SDK integrations use. The CLI accepts manual as an alias wherever you type the value, so claude --permission-mode manual and "defaultMode": "manual" both work.

Manual, acceptEdits, and the Shift+Tab Cycle

Pressing Shift+Tab mid-session cycles default → acceptEdits → plan. The status bar tells you where you are: ⏸ manual mode on in gray, ⏵⏵ accept edits on, ⏸ plan mode on, ⏵⏵ auto mode on, ⏵⏵ don't ask on, or ⏵⏵ bypass permissions on.

Not everything is in that cycle. auto shows up only when your account qualifies for it. bypassPermissions appears only after you start with an enabling flag. dontAsk never appears in the cycle at all and has to be set with --permission-mode dontAsk. When optional modes are enabled they slot in after plan, with bypassPermissions first and auto last.

acceptEdits is the one most people settle into, and it's more generous than the name suggests. Beyond file edits, it auto-approves the common filesystem commands mkdir, touch, rm, rmdir, mv, cp, and sed, including when they're wrapped in timeout, nice, or nohup. Crucially, that auto-approval only applies to paths inside your working directory or your configured additionalDirectories. Everything outside that scope still prompts.

To start in a mode rather than cycling into it, pass the flag, or set a default in a settings file:

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

If you want the read-only end of the spectrum for a specific piece of work, plan mode is the mode designed for it, and it deserves its own treatment.

Auto Mode: A Second Model Watching the First

Auto mode is the genuinely new idea in this list, and it's worth understanding rather than just enabling. Instead of asking you, a separate classifier model reviews each action before it runs and blocks anything that escalates beyond what you asked for, targets infrastructure it doesn't recognize, or looks driven by hostile content Claude just read.

What it blocks by default is a useful list even if you never turn the mode on, because it's essentially a curated inventory of ways an agent can ruin your afternoon: downloading and executing code such as curl | bash, sending sensitive data to external endpoints, production deploys and migrations, mass deletion on cloud storage, granting IAM or repo permissions, force pushes, terraform destroy and its equivalents, and destructive git commands like git reset --hard, git clean -fd, or git stash drop that would throw away uncommitted work.

What it allows by default is equally telling: local file operations in your working directory, installing dependencies declared in your lock files, reading .env and sending credentials to their matching API, read-only HTTP requests, and pushing to branches of the repository you're already working in.

Three details make auto mode behave differently from what people expect. First, boundaries you state in conversation are treated as block signals: tell Claude "don't push until I review" and the classifier blocks matching actions even where the default rules would allow them. Those boundaries aren't stored as rules, though; the classifier re-reads them from the transcript each time, so a boundary can be lost when context compaction removes the message that stated it. For a hard guarantee, use a deny rule. Second, on entering auto mode, broad allow rules that grant arbitrary code execution get dropped, including blanket Bash(*), wildcarded interpreters like Bash(python*), and package-manager run commands; narrow rules like Bash(npm test) carry over and the dropped ones come back when you leave. Third, if the classifier blocks three actions in a row or twenty in total, auto mode pauses and normal prompting resumes.

The classifier also costs something. It runs on Claude Sonnet 5 by default rather than your /model selection, each check sends part of the transcript plus the pending action, and those calls count toward your token usage. Reads and working-directory edits skip the classifier, so the overhead comes mainly from shell commands and network operations. Whether that's a rounding error or a real line item depends on your workload; the pricing breakdown is the place to work that out.

--dangerously-skip-permissions: Read This Before You Type It

bypassPermissions disables permission prompts and safety checks so tool calls execute immediately, including writes to protected paths. These two commands are equivalent:

claude --permission-mode bypassPermissions
claude --dangerously-skip-permissions

Anthropic's guidance is unambiguous: use it only in isolated environments such as containers, VMs, or dev containers without internet access, where Claude Code can't damage your host. The documentation states plainly that it offers no protection against prompt injection or unintended actions.

A few guardrails survive even here. Explicit ask rules still force a prompt. Removals targeting the filesystem root or home directory, such as rm -rf / and rm -rf ~, still prompt as a circuit breaker against model error, including when the removal hides inside command substitution like echo "$(rm -rf ~)". On Linux and macOS, Claude Code refuses to start in this mode as root or under sudo, printing --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons; the check is skipped inside a recognized sandbox, which is why the dev container configuration runs Claude Code as a non-root user.

Two behaviors surprise people. You can't enter bypassPermissions from a session that didn't start with it enabled, which is a deliberate one-way door. And in a session where bypass permissions are available, plan mode's blocks aren't enforced either: Claude is still told to plan without editing, but an edit it attempts during planning runs without prompting. Administrators can remove the option entirely by setting permissions.disableBypassPermissionsMode to "disable" in managed settings.

Dev, a contractor who ships infra changes for three clients, keeps one alias that starts a container and runs Claude Code inside it with bypass on, and never types the flag outside that alias. It took him one incident, a git checkout -- . over four hours of uncommitted work, to build the habit. Auto mode blocks that exact command by default now; bypass mode does not.

Allow, Ask, and Deny Rules

Modes set the baseline. Rules are how you get precision, and they're the answer to "how do I stop the prompts" that doesn't involve loosening everything. Three rule types layer on top of whatever mode you're in:

The practical pattern is narrow allows plus a few hard denies. Allow Bash(npm test) and Bash(git status) so the routine loop stops interrupting you; deny writes to your production config path so no mode and no prompt-injection can reach it. That combination gets you fewer prompts and a higher floor at the same time, which is strictly better than moving one notch down the mode ladder. If you want programmable logic rather than static rules, a PreToolUse hook can inspect the actual command and decide.

Protected Paths: The Files No Mode Auto-Approves

There's a list of paths Claude Code will not auto-approve writes to in any mode except bypassPermissions, and, importantly, allow rules in settings files don't override it. The safety check runs before Claude Code evaluates your settings, so an entry like Edit(.claude/**) in your settings file changes nothing.

Protected directories include .git, .config/git, .vscode, .idea, .husky, .cargo, .devcontainer, .yarn, .mvn, and .claude (except .claude/worktrees). Protected files include .gitconfig and .gitmodules, every shell startup file from .bashrc to .zshenv to .envrc, package-manager configs such as .npmrc, .yarnrc, and bunfig.toml, pre-commit and hook configs, and .mcp.json and .claude.json.

Read that list as a threat model rather than an inventory. Every entry is a file that changes what runs later: a shell rc file, a git hook config, a package-manager registry setting, an MCP server definition. Those are the files an attacker would target precisely because editing them is quiet and the payoff arrives on your next command. In modes that prompt, the prompt for a .claude/ write offers "Yes, and allow Claude to edit its own settings for this session," which approves later writes in that session without asking again.

Where the Real Risk Actually Lives

Here's the part that argues against the framing of this entire article. Permission modes govern what the agent does with the instructions it has. They say nothing about where those instructions came from.

A hook config, an MCP server, a plugin, or a skill you installed from a gist can all shape agent behavior before any permission check runs, and several of them execute code with your privileges by design. A malicious hook that exfiltrates an environment variable on every tool call looks almost identical to a benign logging hook, and it doesn't need a permission prompt because you already approved it at install time. Tightening from acceptEdits to Manual does nothing about that; you'd just be approving the exfiltration one call at a time.

So the honest ranking of what to spend attention on is: read what you install, then pick a mode. Prefer sources that scan what they publish. On PolySkill every skill is security-scanned before it's listed, which is the same instinct as verifying an installer's GPG signature rather than trusting the download page. Neither replaces reading the thing, but both change the base rate.

Pick the Loosest Mode You Could Defend Afterwards

There's no correct mode, only a correct question: if this session did something you didn't intend, would you be able to explain the mode you chose without wincing? Manual for anything near auth, payments, or production. acceptEdits for the ordinary loop of writing and reviewing code, with a couple of narrow allow rules so the prompts stay meaningful. Auto mode when the task is long and you trust the direction, understanding it's a probabilistic safety net rather than a wall. dontAsk in CI, where nobody is there to answer. And bypassPermissions only where the blast radius is a container you can throw away. Whatever you land on, add two deny rules for the paths you'd hate to lose, because those keep working in every mode, including the one named after the danger.

Browse next: Claude Code Plan Mode (2026) | Claude Code Hooks (2026) | How to Install Claude Code (2026) | Claude Code MCP (2026)

Back to Blog