Skip to main content
When Claude wants to edit a file, run a shell command, or make a network request, it pauses and asks you to approve the action. Permission modes control how often that pause happens. The mode you pick shapes the flow of a session: Manual mode has you review each action as it comes, while looser modes let Claude work in longer uninterrupted stretches and report back when done. Pick more oversight for sensitive work, or fewer interruptions when you trust the direction.

​
Available modes

Each mode makes a different tradeoff between convenience and oversight. The table below shows what Claude can do without a permission prompt in each mode.
ModeWhat runs without askingBest for
defaultReads only. Labeled Manual in the CLI and IDE extensionsGetting started, sensitive work
acceptEditsReads, file edits, and common filesystem commands (mkdir, touch, mv, cp, etc.)Iterating on code you’re reviewing
planReads onlyExploring a codebase before changing it
autoEverything, with background safety checksLong tasks, reducing prompt fatigue
dontAskOnly pre-approved toolsLocked-down CI and scripts
bypassPermissionsEverythingIsolated containers and VMs only
The mode that reviews every action is named Manual in the CLI, in claude --help, and in the VS Code and JetBrains extensions. 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, for example claude --permission-mode manual or "defaultMode": "manual". The Manual label and the manual alias require Claude Code v2.1.200 or later. In every mode except bypassPermissions, writes to protected paths are never auto-approved, guarding repository state and Claude’s own configuration against accidental corruption. Modes set the baseline. Layer permission rules on top to pre-approve or block specific tools. Deny rules and explicit ask rules apply in every mode, including bypassPermissions. Allow rules have no effect in that mode because everything else is already approved.

​
Switch permission modes

You can switch modes mid-session, at startup, or as a persistent default. The mode is set through these controls, not by asking Claude in chat. Select your interface below to see how to change it.
During a session: press Shift+Tab to cycle default → acceptEdits → plan. The current mode appears in the status bar. Not every mode is in the default cycle:
  • auto: appears when your account meets the auto mode requirements; cycling to it switches modes without a confirmation prompt
  • bypassPermissions: appears after you start with --permission-mode bypassPermissions, --dangerously-skip-permissions, or --allow-dangerously-skip-permissions; the --allow- variant adds the mode to the cycle without activating it
  • dontAsk: never appears in the cycle; set it with --permission-mode dontAsk
Enabled optional modes slot in after plan, with bypassPermissions first and auto last. If you have both enabled, you will cycle through bypassPermissions on the way to auto.At startup: pass the mode as a flag.
claude --permission-mode plan
As a default: set defaultMode in settings.
{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}
The same --permission-mode flag works with -p for non-interactive runs.

​
Auto-approve file edits with acceptEdits mode

acceptEdits mode lets Claude create and edit files in your working directory without prompting. The status bar shows ⏵⏵ accept edits on while this mode is active. In addition to file edits, acceptEdits mode auto-approves common filesystem Bash commands: mkdir, touch, rm, rmdir, mv, cp, and sed. These commands are also auto-approved when prefixed with safe environment variables such as LANG=C or NO_COLOR=1, or process wrappers such as timeout, nice, or nohup. Like file edits, auto-approval applies only to paths inside your working directory or additionalDirectories. Paths outside that scope, writes to protected paths, and all other Bash commands still prompt. When the PowerShell tool is enabled, acceptEdits mode also auto-approves Set-Content, Add-Content, Clear-Content, and Remove-Item on in-scope paths, along with their common aliases. The same scope and protected-path rules apply. Use acceptEdits when you want to review changes in your editor or via git diff after the fact rather than approving each edit inline. Press Shift+Tab once from Manual mode to enter it, or start with it directly: 
claude --permission-mode acceptEdits

​
Analyze before you edit with plan mode

Plan mode tells Claude to research and propose changes without making them. Claude reads files, runs shell commands to explore, and writes a plan, but does not edit your source. Permission prompts still apply as they do in Manual mode. Enter plan mode by pressing Shift+Tab or prefixing a single prompt with /plan. You can also start in plan mode from the CLI: 
claude --permission-mode plan
Press Shift+Tab again to leave plan mode without approving a plan.

​
Review and approve a plan

When the plan is ready, Claude presents it and asks how to proceed. From that prompt you can:
  • Approve and start in auto mode
  • Approve and accept edits
  • Approve and review each edit manually
  • Keep planning with feedback
  • Refine with Ultraplan for browser-based review
Approving a plan exits plan mode and switches the session to the permission mode each approve option describes, so Claude starts editing. To plan again, cycle back to plan mode with Shift+Tab, or prefix your next prompt with /plan. Press Ctrl+G to open the proposed plan in your default text editor and edit it directly before Claude proceeds. When showClearContextOnPlanAccept is enabled, each approve option also offers to clear the planning context first. Accepting a plan also names the session from the plan content automatically, unless you’ve already set a name with --name or /rename.

​
Set plan mode as the default

To make plan mode the default for a project, set defaultMode in .claude/settings.json: 
{
  "permissions": {
    "defaultMode": "plan"
  }
}

​
Eliminate permission prompts with auto mode

Auto mode requires Claude Code v2.1.83 or later.
Auto mode lets Claude execute without routine permission prompts. A separate classifier model reviews actions before they run, blocking anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read. Explicit ask rules still force a prompt. Auto mode also nudges Claude to keep working without stopping for clarifying questions, though Claude still asks when your prompt or a skill explicitly relies on it. For stronger autonomous behavior while keeping permission prompts, set the Proactive output style instead.
Auto mode is a research preview. It reduces permission prompts but does not guarantee safety. Use it for tasks where you trust the general direction, not as a replacement for review on sensitive operations.
Auto mode is available only when your account meets all of these requirements:
  • Plan: All plans.
  • Owner: on Team and Enterprise, an Owner must enable it in Claude Code admin settings before users can turn it on. Administrators can also lock it off by setting permissions.disableAutoMode to "disable" in managed settings.
  • Model: on the Anthropic API, Claude Opus 4.6 or later, or Sonnet 4.6 or later. On Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, and signed-in Claude apps gateway sessions, only Claude Sonnet 5, Opus 4.7, and Opus 4.8. Older models, including Sonnet 4.5, Opus 4.5, Haiku, and claude-3 models, are not supported on any provider.
  • Provider: available by default on the Anthropic API. On Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, and signed-in Claude apps gateway sessions, auto mode is off until you set CLAUDE_CODE_ENABLE_AUTO_MODE.
If Claude Code reports auto mode as unavailable, one of these requirements is unmet; this is not a transient outage. A separate message that names a model and says auto mode “cannot determine the safety” of an action is a transient classifier outage; see the error reference. If you set defaultMode: "auto" in settings and the session starts in default mode with no error, the setting is likely in .claude/settings.json or .claude/settings.local.json. Claude Code v2.1.142 and later ignore auto from those files so a repository cannot grant itself auto mode. Move it to ~/.claude/settings.json.

​
Enable auto mode on Bedrock, Agent Platform, or Foundry

On Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, and signed-in Claude apps gateway sessions, auto mode does not appear in the Shift+Tab cycle until CLAUDE_CODE_ENABLE_AUTO_MODE is set to 1. The variable works in Claude Code v2.1.158 and later. Only Claude Sonnet 5, Opus 4.7, and Opus 4.8 are supported on these providers. To enable it for one developer, add the variable to the env block in ~/.claude/settings.json: 
{
  "env": {
    "CLAUDE_CODE_ENABLE_AUTO_MODE": "1"
  }
}
To enable it for your organization, add the same env block to managed settings. Once the variable is set, auto mode appears in the Shift+Tab cycle for every session. To make it the default starting mode, also set "permissions": {"defaultMode": "auto"} in user or managed settings. On these providers, Claude Code ignores defaultMode: "auto" unless CLAUDE_CODE_ENABLE_AUTO_MODE is also set. To prevent developers from enabling auto mode, set disableAutoMode to "disable" in managed settings. This overrides the enable variable. If you connect through an LLM gateway configured with ANTHROPIC_BASE_URL, auto mode may already be reachable without the enable variable, because the gateway routes requests through the Anthropic API. This does not apply to a signed-in Claude apps gateway session, which is its own provider class and requires the enable variable. The disableAutoMode setting applies the same way in either configuration.

​
What the classifier blocks by default

The classifier trusts your working directory and the remotes that were configured for it when the session started. A remote added or repointed during the session with git remote add or git remote set-url isn’t trusted, and everything else is treated as external until you configure trusted infrastructure. Before v2.1.200, remotes added mid-session were also trusted. Blocked by default:
  • Downloading and executing code, like curl | bash
  • Sending sensitive data to external endpoints
  • Production deploys and migrations
  • Mass deletion on cloud storage
  • Granting IAM or repo permissions
  • Modifying shared infrastructure
  • Irreversibly destroying files that existed before the session
  • Force push, or pushing directly to main
  • git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop, or git stash clear, which the classifier presumes would discard uncommitted changes
  • git commit --amend when the commit at HEAD was not created in this session
  • From v2.1.198, git commit --amend when the commit at HEAD has already been pushed. A message-only reword is not blocked: --amend -m with nothing newly staged, on a commit that Claude created during this session
  • terraform destroy, pulumi destroy, cdk destroy, or terragrunt destroy, and applying a plan that destroys resources
Claude Code v2.1.195 and later block more categories by default. Several depend on environment entries, such as sensitive remote targets and protected IaC scopes, that you can narrow to concrete names.
  • Writing to a secret manager, or changing DNS records or TLS certificates
  • Merging a pull request no human has approved, approving Claude’s own pull request, or disabling CI checks
  • Posting a comment that is itself a command to automation, such as atlantis apply or a bot’s /deploy or /merge
  • Toggling, ramping, or deleting a production feature flag
  • Applying infrastructure changes to a protected IaC scope, or draining and removing cluster nodes
  • Writes to a shared compute cluster that reach beyond the resource you named, such as a label selector or --all that catches other users’ jobs
  • Creating Kubernetes resources that run on every node or intercept cluster traffic, such as DaemonSets and admission webhooks
  • Interactive shells or port-forwards into a sensitive remote target
  • Opening a tunnel or reverse shell that makes a local service reachable from the public internet
  • Printing a live credential or token into the transcript or a file
  • Accessing a location listed as a sensitive data location in your environment, or copying data out of one. As of v2.1.198 this also blocks sending data from one to an audience the entry excludes
  • Routing a package install around your internal package registry to a public registry. As of v2.1.198, this also applies when you’ve told Claude an internal registry or mirror exists in the conversation, not only when one is listed in your environment
  • Running a command with a flag that disarms a safety guard, like --insecure
  • Launching an autonomous agent loop that runs without human approval or a sandbox, such as one started with --dangerously-skip-permissions or --no-sandbox. As of v2.1.198 this also covers running a third-party agent or eval harness with isolation and per-action approval disabled, such as a runner started with --yes-always
  • Claude in Chrome browser actions that could send page content, cookies, or credentials off-origin
Claude Code v2.1.198 and later also block these by default:
  • Deleting files in /tmp, $TMPDIR, or another shared scratch or cache directory by wildcard, glob, or age filter rather than by a specific named path
  • Including sensitive details in content sent, uploaded, published, or written to other people or shared systems, when your own message didn’t authorize those details for that recipient. PR and issue bodies, commit messages, and comments count as this kind of outbound content when the repository is outside the trust boundary or public, including your organization’s own public repositories; internal file paths, code names, live API response data such as emails or account identifiers, and infrastructure identifiers count as sensitive details. The PR, issue, and commit-message scoping requires Claude Code v2.1.200 or later
  • Sending keystrokes to Claude Code’s own tmux pane to drive its own interface, which the classifier treats as Claude changing its own permissions or oversight
Claude Code v2.1.200 and later also block these by default:
  • Commenting out, deleting, or force-passing a test or assertion that guards security behavior, such as auth, access control, input validation, or sandboxing
  • Deleting or tearing down a stateful resource Claude didn’t create in the session, when no more specific deletion rule applies and you didn’t name that resource
  • Repointing an API base URL, proxy endpoint, webhook receiver, or registry mirror at a third-party host that doesn’t fit the task, including in example files like .env.example
  • Changing where pushes go with git remote set-url or git remote add, unless you named the new remote
  • Pushing secrets to a repository known to be public, or pushing other sensitive or confidential material there that isn’t part of that repository’s own work. When a repository’s visibility isn’t established, the classifier doesn’t block on that alone; it judges the content against the other rules instead
  • Opening a pull request against a different repository or organization, forking with gh repo fork, or pushing to a third-party repository, unless you named that external target
Allowed by default:
  • Local file operations in your working directory
  • Installing dependencies declared in your lock files or manifests
  • Reading .env and sending credentials to their matching API
  • Read-only HTTP requests
  • Pushing to the branch you started on or one Claude created
Claude Code v2.1.195 and later also allow these by default:
  • Deleting the exact jobs Claude created earlier in the same session
  • Reading, reviewing, or writing security-related code, configs, and threat models as part of your task
  • Messages between agents working together in the same multi-agent session
  • Sending data to the trusted domains, buckets, and services you list in environment. This covers data flow only, not destructive or credential operations on the same infrastructure
  • Claude in Chrome navigation to a trusted internal domain, localhost, or a URL you named
Sandbox network access requests are routed through the classifier rather than allowed by default. As of v2.1.198, the classifier reuses its verdict for a network host and port instead of re-running on every connection:
  • An allow is reused until new content enters the conversation, at which point that host is checked again
  • In the interactive CLI, a deny is dropped when the turn ends
  • In non-interactive mode and Agent SDK sessions there is no turn boundary, so a deny is reused for the rest of the run
  • Changing your permission mode or rules drops all cached verdicts
Run claude auto-mode defaults to see the full rule lists. If routine actions get blocked, an administrator can add trusted repos, buckets, and services via the autoMode.environment setting: see Configure auto mode.

​
Boundaries you state in conversation

The classifier treats boundaries you state in the conversation as a block signal. If you tell Claude “don’t push” or “wait until I review before deploying”, the classifier blocks matching actions even when the default rules would allow them. A boundary stays in force until you lift it in a later message. Claude’s own judgment that a condition was met does not lift it. Boundaries are not stored as rules. The classifier re-reads them from the transcript on each check, so a boundary can be lost if context compaction removes the message that stated it. For a hard guarantee, add a deny rule instead.

​
When auto mode falls back

Each denied action shows a notification and appears in /permissions under the Recently denied tab, where you can press r to retry it with a manual approval. If the classifier blocks an action 3 times in a row or 20 times total, auto mode pauses and Claude Code resumes prompting. Approving the prompted action resumes auto mode. These thresholds are not configurable. Any allowed action resets the consecutive counter, while the total counter persists for the session and resets only when its own limit triggers a fallback. In non-interactive mode with the -p flag, repeated blocks abort the session since there is no user to prompt. Repeated blocks usually mean the classifier is missing context about your infrastructure. Use /feedback to report false positives, or have an administrator configure trusted infrastructure.
Each action goes through a fixed decision order. The first matching step wins:
  1. Actions matching your allow or deny rules resolve immediately, except writes to protected paths, which route to the classifier even when an allow rule matches
  2. Read-only actions and file edits in your working directory are auto-approved, except writes to protected paths
  3. Everything else goes to the classifier. As of v2.1.199, an MCP tool marked with _meta["anthropic/requiresUserInteraction"] skips the classifier and prompts you directly, so a consent step is never auto-approved on the tool author’s behalf
  4. If the classifier blocks, Claude receives the reason and tries an alternative
On entering auto mode, broad allow rules that grant arbitrary code execution are dropped:
  • Blanket Bash(*) or PowerShell(*)
  • Wildcarded interpreters like Bash(python*)
  • Package-manager run commands
  • Agent allow rules
Narrow rules like Bash(npm test) carry over. Dropped rules are restored when you leave auto mode.The classifier sees user messages, tool calls, and your CLAUDE.md content. Tool results are stripped, so hostile content in a file or web page cannot manipulate it directly. A separate server-side probe scans incoming tool results and flags suspicious content before Claude reads it. For more on how these layers work together, see the auto mode announcement and the engineering deep dive.
The classifier checks subagent work at three points:
  1. Before a subagent starts, the delegated task description is evaluated, so a dangerous-looking task is blocked at spawn time.
  2. While the subagent runs, each of its actions goes through the classifier with the same rules as the parent session, and any permissionMode in the subagent’s frontmatter is ignored.
  3. When the subagent finishes, the classifier reviews its full action history; if that return check flags a concern, a security warning is prepended to the subagent’s results.
Step 1 requires Claude Code v2.1.178 or later. Earlier versions applied the classifier at steps 2 and 3, but did not evaluate the task description before the subagent started.
The classifier runs on a server-configured model that is independent of your /model selection, so switching models does not change classifier availability. Classifier calls count toward your token usage. Each check sends a portion of the transcript plus the pending action, adding a round-trip before execution. Reads and working-directory edits outside protected paths skip the classifier, so the overhead comes mainly from shell commands and network operations. As of v2.1.198, a sandbox network verdict for a host and port is reused instead of re-classified on every connection, so repeated connections to the same host don’t each add a check. What the classifier blocks by default describes how long an allow and a deny last.

​
Allow only pre-approved tools with dontAsk mode

dontAsk mode auto-denies every tool call that would otherwise prompt. The status bar shows ⏵⏵ don't ask on while this mode is active. Only actions matching your permissions.allow rules and read-only Bash commands can execute; explicit ask rules are denied rather than prompting. As of v2.1.199, an MCP tool marked with _meta["anthropic/requiresUserInteraction"] is also denied in this mode even when an allow rule matches it, because its approval card needs an answer this mode never collects. This makes the mode fully non-interactive for CI pipelines or restricted environments where you pre-define exactly what Claude may do. Cloud sessions on Claude Code on the web ignore defaultMode: "dontAsk"; see bypassPermissions for details. Set it at startup with the flag: 
claude --permission-mode dontAsk

​
Skip all checks with bypassPermissions mode

bypassPermissions mode disables permission prompts and safety checks so tool calls execute immediately. As of v2.1.126 this includes writes to protected paths, which earlier versions still prompted for. Explicit ask rules still force a prompt in this mode, and removals targeting the filesystem root or home directory, such as rm -rf / and rm -rf ~, still prompt as a circuit breaker against model error. As of v2.1.199, MCP tools marked with _meta["anthropic/requiresUserInteraction"] also still prompt. Only use this mode in isolated environments like containers, VMs, or dev containers without internet access, where Claude Code cannot damage your host system. You cannot enter bypassPermissions from a session that was started without one of the enabling flags; restart with one to enable it: 
claude --permission-mode bypassPermissions
The --dangerously-skip-permissions flag is equivalent. On Linux and macOS, Claude Code refuses to start in this mode when running as root or under sudo: 
--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons
The check is skipped automatically inside a recognized sandbox. To run autonomously in a container, use the dev container configuration, which runs Claude Code as a non-root user. Claude Code on the web does not honor defaultMode: "bypassPermissions" or "dontAsk" from your settings files, so a repository’s checked-in settings cannot start a cloud session in bypass-permissions mode. The setting is ignored silently and the session starts in the mode shown in the mode dropdown instead. See Switch permission modes for which modes cloud sessions offer.
bypassPermissions offers no protection against prompt injection or unintended actions. For background safety checks with far fewer permission prompts, use auto mode instead. Administrators can block this mode by setting permissions.disableBypassPermissionsMode to "disable" in managed settings.

​
Protected paths

Writes to a small set of paths are never auto-approved, in every mode except bypassPermissions. This prevents accidental corruption of repository state and Claude’s own configuration.
ModeProtected-path writes
default, acceptEdits, planPrompted
autoRouted to the classifier
dontAskDenied
bypassPermissionsAllowed
permissions.allow rules in settings files do not pre-approve protected-path writes. The safety check runs before Claude Code evaluates allow rules from settings, so an entry such as Edit(.claude/**) in ~/.claude/settings.json or .claude/settings.json does not change the per-mode outcome in the table above. 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 .claude/ writes in that session without prompting again. Protected directories:
  • .git
  • .config/git
  • .vscode
  • .idea
  • .husky
  • .cargo
  • .devcontainer
  • .yarn
  • .mvn
  • .claude, except for .claude/worktrees where Claude stores its own git worktrees
Protected files:
  • .gitconfig, .gitmodules
  • .bashrc, .bash_profile, .bash_login, .bash_aliases, .bash_logout, .zshrc, .zprofile, .zshenv, .zlogin, .zlogout, .profile, .envrc
  • .npmrc, .yarnrc, .yarnrc.yml, .pnp.cjs, .pnp.loader.mjs, .pnpmfile.cjs, bunfig.toml, .bunfig.toml
  • .bazelrc, .bazelversion, .bazeliskrc
  • .pre-commit-config.yaml, lefthook.yml, lefthook.yaml, .lefthook.yml, .lefthook.yaml
  • gradle-wrapper.properties, maven-wrapper.properties
  • .devcontainer.json
  • .ripgreprc, pyrightconfig.json
  • .mcp.json, .claude.json

​
See also

  • Permissions: allow, ask, and deny rules; managed policies
  • Configure auto mode: tell the classifier which infrastructure your organization trusts
  • Hooks: custom permission logic via PreToolUse and PermissionRequest hooks
  • Ultraplan: run plan mode in a Claude Code on the web session with browser-based review
  • Security: safeguards and best practices
  • Sandboxing: filesystem and network isolation for Bash commands
  • Non-interactive mode: run Claude Code with the -p flag