Choose a permission mode

Control whether Claude asks before acting. Switch permission modes with Shift+Tab in the CLI, the mode indicator in VS Code, or the mode selector in Desktop.

A permission mode sets which actions Claude can take in a session without asking you first. In Manual mode, Claude Code stops and asks you before most actions that edit files, run shell commands, or reach the network. In auto mode, a second model, the classifier, reviews actions instead of you; how the classifier evaluates actions lists which actions it reviews and which skip it.

With Claude Code v2.1.283 or later, auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions. On earlier versions, it's the built-in starting permission mode only on Pro, Max, and Team plans. Which mode a session starts in covers the surfaces and settings that change the starting permission mode. You can also change a running session's permission mode at any time.

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. Manual mode appears under its config value, default.

The mode that reviews every action is named 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, for example claude --permission-mode manual or "defaultMode": "manual". The Manual label and the manual alias require Claude Code v2.1.200 or later. The desktop app's label doesn't depend on your CLI version.

Writes to protected paths are never auto-approved except in bypassPermissions mode and in plan-mode sessions where bypass permissions are available, meaning interactive terminal sessions started in a way that puts bypassPermissions in the mode cycle.

Modes set the baseline. Layer permission rules on top to pre-approve or block specific tools. Deny rules block in every mode, including bypassPermissions. Deny and ask rules don't apply to EndConversation as long as Claude still has at least one other tool it can call. Allow rules have no effect in bypassPermissions.

Actions no mode auto-approves

Claude Code doesn't auto-approve the following in any mode, including bypassPermissions. Each bullet links to the section that says what happens instead in each mode:

• Tools matched by an explicit ask rule

• Connector tools your organization set to ask, in sessions where that setting reaches Claude Code

• Tools that require user interaction: the built-in AskUserQuestion tool and MCP tools marked requiresUserInteraction

• rm and rmdir removals targeting a critical path, which no allow rule or PreToolUse hook "allow" approves

• The cross-session messaging safeguards

• Reads outside the working directories while permissions.blockReadsOutsideWorkingDirectories is on: recognized file-reading Bash commands prompt even in auto mode and bypassPermissions mode, and so does any unsandboxed retry that needs approval to run outside the sandbox. Requires Claude Code v2.1.257 or later.

  A command the shell parser can't trace, such as one that changes directory more than once or runs a subshell, prompts the same way even when it names no outside path. This prompt doesn't apply when the command runs in the sandbox and the sandbox enforces the block.

Common setups

Permission modes decide whether Claude asks before an action, and the Bash sandbox and outer isolation boundaries decide what an action can reach once it runs. Each row below pairs a goal with the flags or settings that get you there and the isolation it needs, as a starting point. Available modes lists what runs without a prompt in each mode.

The Bash sandbox and auto mode work independently and combine, with the exceptions listed under Sandbox modes. For the full interaction, see How sandboxing relates to permissions and permission modes and How isolation relates to permission modes.

Which mode a session starts in

When you start a new session in a terminal, Claude Code takes the permission mode from the first of these that applies:

1. The --permission-mode flag, or --dangerously-skip-permissions

2. permissions.defaultMode in a settings file

   If you set "auto" in .claude/settings.json or .claude/settings.local.json, the value doesn't take effect, and Claude Code then uses the built-in default rather than a defaultMode from ~/.claude/settings.json. If you set "bypassPermissions" in those two files, it doesn't take effect either, and the session starts in Manual mode. The other values apply from any settings file.

3. The built-in default

Conversations the VS Code extension starts follow the extension's own list in Switch permission modes. For the permission mode Claude Code starts a resumed session in, see permission mode on resume.

The built-in auto default requires Claude Code v2.1.228 or later on macOS, Linux, and WSL, and v2.1.233 or later on native Windows. On earlier versions, the built-in default is Manual.

The built-in default depends on how you run Claude Code. The first row that matches your session applies. The table covers sessions you start in a terminal or through the VS Code extension; for the desktop app and claude.ai, see the Desktop and Web tabs in Switch permission modes.

In your first session after an install or upgrade, Claude Code can choose the starting permission mode before its feature flags arrive. That session can start in a different permission mode than the table gives, and your next session matches the table.

When the flag, a settings file, or the built-in default selects auto but auto mode isn't available to the session, Claude Code starts the session in Manual instead. Auto mode is unavailable when the session doesn't meet the availability requirements, such as a settings file turning it off or a model that doesn't support it, or when Anthropic has temporarily turned it off server-side.

The first time the built-in default starts one of your sessions in auto mode, Claude Code shows a notice that links to this page:

• In a terminal, once, at the top of the session
• In the VS Code extension, as a card on the new-conversation screen that stays until you dismiss it

On Pro, Max, and Team plans, if your ~/.claude/settings.json sets a defaultMode other than auto and no other settings file sets one, your sessions keep starting in that mode. Claude Code asks once, in the terminal or in the VS Code extension, whether to change the setting to auto mode. If you decline, your setting stays as it is.

Start in a different permission mode

You can set the starting permission mode for one session, or as a default for every session on a machine, in a project, or in an organization. When more than one settings file sets permissions.defaultMode, settings precedence decides, so a project or managed value outranks ~/.claude/settings.json. To change the permission mode of a session that's already running, see Switch permission modes.

This example makes every terminal session on your machine start in Manual mode, whose config value is default. Save it in ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "default"
  }
}

The next session you start shows ⏸ manual mode on in the status bar.

Switch permission modes

Each interface has its own control for switching permission modes during a session and its own way of choosing the permission mode new sessions start in. Select your interface to see its controls.

claude --permission-mode plan

claude remote-control --permission-mode acceptEdits

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.

Each path also goes through the symlink check, so a write that resolves outside that scope isn't auto-approved either. Paths outside that scope, writes to protected paths, rm and rmdir removals targeting a critical path, and all other Bash commands except the built-in read-only set 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, and Remove-Item gets its own check. A positional argument that contains a quote character, such as the apostrophe in Set-Content .\notes.txt "It's done", still prompts even on in-scope paths, because Claude Code can't statically validate an argument whose quoted and unquoted readings differ. Pass the content through a named parameter such as -Value to avoid the prompt.

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. Except in interactive terminal sessions with bypass permissions available, edits stay blocked until you approve the plan.

What happens to a shell command during planning depends on the session, and the first of these cases that matches applies:

• Interactive terminal sessions with bypass permissions available: neither the classifier nor a prompt applies to planning commands. Skip all checks with bypassPermissions mode covers the few things that still prompt there.
• Auto mode available and the useAutoModeDuringPlan setting on, which it is by default: the classifier reviews shell commands other than critical-path removals instead of prompting you. Approved commands run, and rejected ones are blocked.
• Auto mode not available, or useAutoModeDuringPlan off: commands outside the built-in read-only set prompt for approval, including when the sandbox's auto-allow mode is enabled.

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 choose:

• Yes, and use auto mode: approve and start in auto mode. If auto mode isn't available to your session, for example because your organization turned it off, this option reads Yes, auto-accept edits. If you started the session with bypass permissions enabled, the option reads Yes, and switch to BYPASS PERMISSIONS (no further prompts) for this session instead.
• Yes, manually approve edits: approve and review each edit individually.
• No, keep planning: stay in plan mode and tell Claude what to change.

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, the list gains a first option that approves the plan and clears the planning context.

Accepting a plan also gives the session a generated title based on the plan, unless you've already named the session.

Set plan mode as the default

To make plan mode the default for a project's terminal sessions, set defaultMode to plan in .claude/settings.json, placed as the example under Start in a different permission mode shows. Conversations the VS Code extension starts don't read project settings for the starting permission mode. There, set claudeCode.initialPermissionMode to plan in your VS Code user settings instead.

Eliminate permission prompts with auto mode

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.

With Claude Code v2.1.283 or later, auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions on every plan and provider. On earlier versions, it's the built-in starting permission mode only on Pro, Max, and Team plans.

The classifier also reviews each message Claude sends to another agent with SendMessage, whether plain text or a structured agent team message, before Claude Code delivers it, both in auto mode and in plan mode while the classifier reviews commands; the send review requires Claude Code v2.1.222 or later.

By default, the classifier doesn't review rm and rmdir removals targeting a critical path, such as rm -rf / or rm -rf ~. Critical paths covers what happens to them in each permission mode.

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 in a mode that still prompts you, set the Proactive output style instead.

Auto mode is available only when your account meets all of these requirements:

• Plan: All plans.
• Organization: on Team and Enterprise, auto mode is available by default. Administrators can turn it off for the organization by setting permissions.disableAutoMode to "disable" in managed settings.
• Model: on the Anthropic API and Claude Platform on AWS, Claude Opus 4.6 or later, Sonnet 4.6 or later, or a Fable model. On Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, and signed-in Claude apps gateway sessions, only Claude Sonnet 5, Opus 4.7 or later, and the Fable models. 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, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, and signed-in Claude apps gateway sessions.

If Claude Code reports auto mode as unavailable, first check these requirements and whether any settings file sets disableAutoMode. Anthropic may also have turned auto mode off server-side, or the server may have rejected auto mode for your account. A session that received either answer keeps auto mode off until the session ends, so start a new session later.

A separate message that names a model and says auto mode "cannot determine the safety" of an action means a classifier request failed. That failure is usually transient, but on Amazon Bedrock it can repeat until your account can invoke the named model. See the error reference for the causes and what to do.

If you set defaultMode: "auto" in settings and a terminal session starts in Manual mode with no error, the setting is likely in .claude/settings.json or .claude/settings.local.json. auto doesn't take effect from those files. Move it to ~/.claude/settings.json. For a conversation the VS Code extension started, check the extension's own list in Switch permission modes instead.

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 is available by default. With Claude Code v2.1.283 or later, it's also the built-in starting permission mode for interactive terminal and VS Code sessions. To choose the starting permission mode yourself, set permissions.defaultMode as Start in a different permission mode describes, or pick a permission mode from the VS Code extension's mode indicator.

Only Claude Sonnet 5, Opus 4.7 or later, and the Fable models are supported on these providers. On any other model, the session starts in Manual instead.

To prevent developers from using auto mode, set disableAutoMode to "disable" in managed settings. This removes auto from the Shift+Tab cycle, and a session started with --permission-mode auto starts in Manual instead. A session already running in auto mode leaves it when the setting reaches that session from an admin-deployed source, and shows auto mode disabled by settings. Before v2.1.251, a running session kept auto mode until it ended.

In v2.1.158 through v2.1.206, auto mode was off on these providers until you set CLAUDE_CODE_ENABLE_AUTO_MODE=1, and Claude Code ignored defaultMode: "auto" on these providers unless the variable was also set. The variable is still accepted for compatibility and has no effect from v2.1.207 onward.

Server-side classifier review

In auto mode, Claude Code can ask the server to check the actions that the decision order sends for review, as part of the session's model requests, in place of sending its own classifier requests. These sessions ask:

• A direct connection to the Anthropic API: in an interactive terminal session, on every claude.ai plan and on accounts that use the Claude API, as Anthropic rolls it out. Requires Claude Code v2.1.271 or later on Pro, Max, and Team plans, and v2.1.278 or later on Enterprise plans and Claude API accounts. From v2.1.282, a session that doesn't fetch feature flags, for example because you turned telemetry off, asks the server by default in any kind of session.
• A cloud provider, or an LLM gateway or proxy: on Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, and Microsoft Foundry, and whenever you point ANTHROPIC_BASE_URL at an LLM gateway or proxy, whatever your plan. Asking by default requires Claude Code v2.1.278 or later.
• A signed-in Claude apps gateway session: requires Claude Code v2.1.280 or later

Where the server reviews the actions, its verdicts decide them. Two other outcomes are possible:

• The server doesn't review the session: a response completes with no review results, or the server answers that it doesn't review this session. The most common causes are an LLM gateway or proxy that drops the request for review or the results, and a platform, region, or credential that doesn't have server-side checks yet. Claude Code falls back to its own classifier requests. Once that fallback holds for the rest of the session, it shows a notice about classifier request charges on accounts where those requests are billed.
• The server gives no verdict for an action: Claude Code denies the action rather than run it unreviewed. On any connection, this happens when the response ends before the review results arrive or the results arrive in a form Claude Code can't read. An LLM gateway or proxy that cuts responses short or rewrites the results can cause either. On a direct connection to the Anthropic API, it also happens when the server's check fails for the action, for example by timing out. The server returned no safety verdict covers the denial message, what happens when denials repeat, and what to do.

To skip asking the server and always use Claude Code's own classifier requests, set CLAUDE_CODE_AUTO_MODE_SERVER=0. On a direct connection to the Anthropic API, the variable requires Claude Code v2.1.281 or later. Setting it to 1 there turns server review on in a session that doesn't have it yet, such as a -p or Agent SDK session, unless you've also set CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1. If you set CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 and leave CLAUDE_CODE_AUTO_MODE_SERVER unset, Claude Code also stops asking the server, except as Disable pre-release capabilities describes.

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
• Committing or pushing a change that would send secrets or sensitive data outside the repository when it runs, or widen what a deploy exposes. This covers a CI workflow or deploy configuration that passes a secret to a destination that doesn't already receive it, a script or setup step that reads a secret store and sends the data out, and a config change that widens what a deploy publishes, such as a registry, visibility, artifact, or sourcemap setting. The check applies on any branch, applies even when the repository is public, and fires when the change is committed or pushed, whether or not that commit or push triggers the pipeline; clearing it requires naming the execution effect, not only the commit or push. Before v2.1.211, this check was scoped to the default branch instead: a push there was blocked when it carried sensitive content, changes concealed or misdescribed relative to what you asked for, content ported in from outside the repository, or routed around a review you asked for
• 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. Live personal data from an API response in a PR or issue body, such as an email address, an account or organization identifier, or a usage metric, requires you to name those details and the recipient regardless of the repository's visibility or trust boundary. That check requires Claude Code v2.1.203 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 or personal or entrusted data to a repository known to be public, or pushing confidential material there that isn't part of that repository's own work. A dotfiles repository's own subject matter is the one exception for personal or entrusted data, and content from a private repository reaching any public surface is blocked the same way; both refinements require Claude Code v2.1.203 or later. Before v2.1.203, personal data was grouped with confidential material and blocked only when it wasn'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

Claude Code v2.1.203 and later also block these by default:

• Content from a sensitive local store, or from a file whose name, path, or type marks it as sensitive, entering a commit, a push, PR or issue text, a gist or paste, or a package publish, unless you named both the source and the destination. Session transcripts and conversation logs, credential and configuration dot-folders such as SSH keys, cloud credentials, browser profiles, and shell history, and user-data exports all count, and the repository being private doesn't clear it

Claude Code v2.1.205 and later also block these by default:

• Writing to Claude Code session transcripts, the .jsonl history files under ~/.claude/projects/ or your configured config directory, whether directly or through a shell command. The rule also covers the metadata lines Claude Code appends to each transcript entry for its own checks. Reading a transcript isn't blocked

• A recursive forced delete such as rm -rf "$VAR" or Remove-Item -Recurse -Force $dir whose target is a shell variable that isn't assigned anywhere in the conversation the classifier sees, or a glob rooted at such a variable. The value came only from earlier command output, which the classifier never receives, so the classifier can't verify the deletion target against the other deletion rules. The block clears when you name the exact path being deleted, or when Claude re-runs the delete with the resolved literal path written into the command. Deletes whose target the classifier can resolve aren't affected.

  A glob directly under the variable, as in rm -rf "$VAR"/*, is a critical path instead. Remove-Item targets that are a bare * or end in /* or \* never reach the classifier: Claude Code denies them outright.

Claude Code v2.1.257 and later also block these by default:

• Requesting credentials from the cloud instance-metadata endpoint, such as 169.254.169.254, or explicitly authenticating a cloud, cluster, or registry call with the machine's own service-account or node identity
• Reaching a public host by a route other than a direct request, such as a tunnel, a reverse shell, or a resolver or proxy configuration rewritten to point outside
• Reading credentials that belong to the host rather than to your task, such as node certificates or the node's container-registry auth
• Connecting to or scanning sibling containers, pods, or VMs that Claude didn't start, or the node beneath the container

If Claude Code runs somewhere that is meant to allow one of these, describe that setup in a Host containment entry in autoMode.environment.

Claude Code v2.1.261 and later also block these by default:

• Posting or writing a link to a public paste, diagram, or data-sharing service in a message, PR or issue text, a document, or anywhere else the link will be opened or fetched, when the URL itself carries the content being shared, unless you named that service

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 any branch of the repository you're working in, including the default branch. A non-default branch whose name marks it as a deploy or publication target, such as production or gh-pages, isn't covered: the classifier judges a push there on its own terms. The push's content is still checked against the other rules, permissions.deny rules can still block push commands as written in every mode, and the remote's own branch protection still applies. Before v2.1.211, only pushes to the branch you started on, branches Claude created, and routine pushes to the default branch were allowed by default, and before v2.1.203 any direct push to the default branch was blocked

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

Sandboxed commands don't get network access by default. Claude names the hosts a command needs on the command itself, the classifier reviews them with the command, and an approved list opens those hosts for that one command alone. Per-command allowed domains covers what a list can and can't open and what happens when a command reaches for an unlisted host.

Run claude auto-mode defaults to print the full rule lists as JSON. If routine actions get blocked, an administrator can add trusted repos, buckets, and services via the autoMode.environment setting: see Configure auto mode.

Pushing to any branch of the repository you're working in and creating a pull request that matches your request run without a prompt, unless the push or pull request falls under the blocked list, such as secrets or sensitive data leaving the repository, or a pull request that targets a different repository or organization. To require a human checkpoint before these commands while staying in auto mode, add permissions.ask rules, which match the command as written: see Common boundaries.

The first read outside the working directories

While permissions.blockReadsOutsideWorkingDirectories is off, file reads run without a prompt in auto mode, including reads outside the working directories. The first time Claude uses the Read, Grep, or Glob tool on a path outside them, Claude Code asks you whether to keep allowing those reads.

The prompt doesn't appear in non-interactive -p runs or background sessions; reads there run as before.

Whatever you answer, Claude keeps working:

• Keep allowing: the read runs, later reads outside the working directories run as before, and Claude Code records your answer so the prompt doesn't appear again
• Block from now on: the read is refused, and Claude Code sets permissions.blockReadsOutsideWorkingDirectories to true in your user settings, which makes the file tools refuse such reads in every later session and every permission mode. To let Claude read such a path later, add its directory with /add-dir or remove the setting.
• Ask again next time: the read is refused, and the next read outside the working directories prompts again

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.

Approvals you state in conversation

If you tell Claude that a blocked action is allowed, the classifier reads that as your approval and can clear the block. How you worded it decides whether the action runs, and how far the approval reaches:

• Name the action and its specifics: your message has to name the action and the specific thing that makes it dangerous, such as the branch of a force push. Naming the verb alone clears nothing, so "you can force-push" leaves the block in place.
• Expect it to cover one action: an approval covers the destructive action you named, so a later action is blocked again unless you granted the approval as standing. To stop approving a routine pattern one action at a time, add it to autoMode.allow.
• Some blocks stay in place: the classifier's precedence order sets out which blocks your approval can reach. To run a step it won't clear, leave auto mode and answer the permission prompt.

When auto mode falls back

When auto mode can't approve your session's actions, what happens depends on the case:

• A blocked action: Claude Code shows a notification and lists the action in /permissions under the Recently denied tab, where you can press r to retry it with a manual approval. When the classifier produces no verdict on the action, because a safety check separate from auto mode refused the classifier's own request or its response didn't parse, Claude Code denies the action without the notification or the Recently denied entry.
• Repeated blocks: 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. Claude Code doesn't count a denial toward either threshold when a safety check separate from auto mode refuses the classifier's own request; the linked entry covers how Claude Code handles those denials.
• Sessions that can't prompt: a non-interactive -p run without a --permission-prompt-tool has no prompt to fall back to. When repeated blocks reach a threshold, the action doesn't run and Claude keeps working. The same applies when a safety check separate from auto mode refuses the classifier's request. Claude Code doesn't stop the run in either case.
• No verdict from the server: under server-side classifier review, Claude Code denies an action the server gives no verdict for, and stops the turn after ten responses in a row with no verdict. See The server returned no safety verdict.
• A mode switch during a check: if you switch permission modes while a classifier check is pending, Claude Code discards a verdict the new mode wouldn't have requested rather than applying it: you're prompted for approval instead, or the action is auto-denied in dontAsk mode.

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.

1. Actions matching your [allow, ask, or deny rules](/docs/en/permissions#manage-permissions) resolve immediately, with these exceptions:
   * Writes to [protected paths](#protected-paths) route to the classifier even when an allow rule matches
   * No allow rule approves `rm` and `rmdir` removals targeting a [critical path](#critical-paths)
   * MCP tools marked [`requiresUserInteraction`](/docs/en/mcp#require-approval-for-a-specific-tool) prompt you directly even when an allow rule matches, and so do connector tools [your organization set to `ask`](/docs/en/mcp#organization-controls-on-connector-tools) in sessions where that setting reaches Claude Code
   * A shell command that carries [per-command allowed domains](/docs/en/sandboxing#per-command-allowed-domains-in-auto-mode) also routes to the classifier even when an allow rule matches, because a rule approves the command, not its hosts
   * Ask rules that match on a command's content, such as `Bash(git push *)`, fall back to a permission prompt
   * A write that the [symlink check](/docs/en/permissions#symlinks) resolves to a protected path prompts you when the path Claude requested isn't itself protected
2. Read-only actions and file edits in your working directory are auto-approved, except writes to [protected paths](#protected-paths) and [the first read outside the working directories](#first-read-outside-the-working-directories), which prompts you
   * In a session with [server-side classifier review](#server-side-classifier-review), read-only and [sandboxed](/docs/en/sandboxing#sandbox-modes) shell commands wait for that review and are blocked if it flags them
   * A write inside your working directory that the [symlink check](/docs/en/permissions#symlinks) resolves to a location outside it prompts you
3. Everything else goes to the classifier, apart from [critical-path removals](#critical-paths) under their default handling. The connector tools and `requiresUserInteraction` MCP tools that prompt you directly in step 1 never reach the classifier either, so neither an org-required approval nor a consent step is auto-approved
4. If the classifier blocks, Claude receives the reason and tries an alternative. In most sessions the reason names the rule the classifier matched, such as `[Data Exfiltration]`, rather than giving a written explanation; see [Review denials](/docs/en/auto-mode-config#review-denials)

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
* [`Monitor`](/docs/en/tools-reference#monitor-tool) allow rules, because Claude Code runs Monitor commands through the shell

Narrow rules like `Bash(npm test)` stay in effect. Claude Code restores the dropped rules when you leave auto mode. Before v2.1.236, Claude Code left `Monitor` allow rules in effect in auto mode, so a rule that matched the whole tool approved Monitor commands without classifier review.

Claude Code also runs `git status` itself before a command that would discard uncommitted work, such as `git reset --hard` or `rm -rf`, and shows the classifier whether staged, modified, or untracked work is present. Claude Code reports untracked files in that check even when the repository's git configuration sets `status.showUntrackedFiles=no`.

In the classifier requests sent by Claude Code itself, the classifier sees user messages, tool calls other than read-only lookups such as file reads and searches, and your CLAUDE.md content. Tool results are stripped from those requests, so hostile content in a file or web page can't manipulate the classifier directly.

You can annotate a call's result with a [PostToolUse hook's `classifierContext` field](/docs/en/hooks#annotate-a-result-for-the-auto-mode-classifier), which the classifier reads as application-provided context. The field requires Claude Code v2.1.236 or later.

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](https://claude.com/blog/auto-mode) and the [engineering deep dive](https://www.anthropic.com/engineering/claude-code-auto-mode).

claude --permission-mode dontAsk

claude --permission-mode bypassPermissions

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons