Claude Code Permission Modes for Unattended Work

Permission mode barely matters when you are sitting at the terminal. It matters enormously when you are not. A session driven from your phone, hosting a channel, or left running overnight will stop dead at the first permission prompt and wait for an answer you are not there to give.

The line worth memorising: claude remote-control --permission-mode acceptEdits. Set the starting mode when you launch the host, rather than discovering the problem from a train.

Changing 14 August 2026: auto mode becomes the default for new sessions on Pro, Max and Team plans. See what changes and how to keep Manual.

The six modes

ModeRuns without askingSuited to
default (shown as Manual)Reads onlySensitive work you are watching
acceptEditsReads, file edits, common filesystem commandsIterating on code you review afterwards
planReads, plus classifier-approved commands where auto is availableExploring before changing anything
autoEverything, with a classifier checking each actionLong unattended tasks
dontAskOnly pre-approved toolsCI and locked-down scripts
bypassPermissionsEverything, no checksIsolated containers and VMs only

A naming quirk: the mode that reviews every action is labelled Manual in the CLI, VS Code, JetBrains and Desktop, but its config value is default. From v2.1.200 the CLI also accepts manual as an alias.

Switching between them

Shift+Tab cycles default, acceptEdits, plan. The others are not in that cycle by default. dontAsk never appears and must be set with a flag. bypassPermissions only joins the cycle if you started the session with it enabled.

claude --permission-mode plan
claude --permission-mode dontAsk
claude remote-control --permission-mode acceptEdits

As a persistent default, set it in a settings file:

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

What acceptEdits actually covers

More than the name suggests. Alongside file edits it auto-approves mkdir, touch, rm, rmdir, mv, cp and sed, including when wrapped in timeout, nice or nohup. Approval only applies to paths inside your working directory or additionalDirectories. Anything outside that, and every other Bash command beyond the read-only set, still prompts.

For remote work this is the pragmatic middle ground: Claude edits freely, you review the diff later, and most prompts disappear.

Auto mode, and why it is not a free pass

Auto mode runs a separate classifier model over each action before it executes, blocking anything that escalates beyond your request, targets infrastructure it does not recognise, or looks driven by hostile content Claude just read. It is available on all plans, though it needs a recent model and can be disabled by administrators.

Blocked by default, among many others: curl | bash, production deploys and migrations, force push, mass deletion on cloud storage, git reset --hard, terraform destroy, printing a live credential into the transcript, and opening a tunnel that exposes a local service to the internet.

Allowed by default: local file operations in your working directory, installing declared dependencies, read-only HTTP, and pushing to branches of the repository you are working in.

The behaviour that catches people out. If the classifier blocks three actions in a row, or twenty in a session, auto mode pauses and Claude Code goes back to prompting. Those thresholds are not configurable. So auto mode is not a guarantee that an unattended session never stalls, it just makes stalling much less likely.

You can also state boundaries in conversation. Telling Claude “do not push” makes the classifier block matching actions even where the defaults would allow them. One caveat: boundaries are re-read from the transcript each time, so context compaction can lose one. For a hard guarantee use a deny rule instead.

dontAsk, the mode built for never waiting

dontAsk auto-denies anything that would otherwise prompt. Claude runs only what matches your permissions.allow rules and the read-only command set. The session never waits for input, which is exactly what you want in CI.

The trade-off is obvious once stated: instead of stalling, the work silently fails. For an unattended remote session that is often worse than a pause, so reach for auto first and keep dontAsk for pipelines where you have enumerated what Claude may do.

bypassPermissions, and when not to

This one disables prompts and safety checks entirely, including writes to protected paths. The documentation is blunt that it belongs only in isolated containers and VMs, and it offers no protection against prompt injection.

  • You cannot enter it from a session that did not start with it enabled.
  • Claude Code refuses to start in this mode as root or under sudo on Linux and macOS.
  • The first interactive session shows a warning dialog you must accept once.
  • rm -rf / and rm -rf ~ still prompt, as a circuit breaker against model error.
  • Cloud sessions ignore defaultMode: "bypassPermissions" from settings files, so a repository cannot start a cloud session in it.

Protected paths

A small set of paths is never auto-approved outside bypass mode, which stops Claude corrupting repository state or its own configuration. Directories include .git, .vscode, .idea, .husky, .devcontainer and .claude. Files include .gitconfig, the shell rc files, .npmrc, .mcp.json and .claude.json.

Worth knowing: an allow rule in settings does not pre-approve these. The safety check runs before allow rules are evaluated.

What you cannot set from your phone

The app restricts modes, and the restrictions differ by session type.

SessionOffered in the appUnavailable
Cloud sessionAccept edits, Plan, AutoBypass permissions
Remote ControlManual, Accept edits, PlanBypass permissions, and Auto

So the mode you would most want for a long unattended remote session, auto, cannot be selected from the phone at all. Set it on the host before you leave. The dropdown does reflect the mode the local session is actually in, and updates when you change it in the terminal, with one exception: a session never reports bypass mode to claude.ai.

Choosing for work you will not be watching

  • Short task, you will glance at it: acceptEdits.
  • Long task, genuinely unattended: auto, set on the host before you leave.
  • Pipeline with a known tool list: dontAsk.
  • Anything on your real machine: not bypassPermissions.

Related: running on an always-on machine, and channels, where an unanswered prompt stalls the session in exactly the same way.