Key takeaways

  • Allow rules such as Bash(npm run *) approve specific commands, and /permissions lets you manage them.
  • Permission modes like acceptEdits and auto reduce prompts, and bypassPermissions skips them.
  • Anthropic says to use bypassPermissions only in isolated environments, because it offers no protection against prompt injection or unintended actions.

To make Claude Code stop asking before it runs commands, you have three options: add allow rules for the commands you trust, switch to a more permissive permission mode, or skip permission prompts entirely with bypassPermissions. This guide to how to allow all commands in Claude Code follows Anthropic's permissions documentation and covers each option, from narrowest to widest, and what each one risks. Details are as of October 31, 2026.

What Claude Code asks about by default

In the default mode, which the CLI labels Manual, Claude Code prompts before it acts on most things. According to the docs, reads inside your working directory need no approval. Bash commands do, apart from a built-in set of read-only commands. File edits, web fetches and web searches prompt too.

When you answer a prompt with "Yes, and don't ask again", the approval is saved as a rule. For Bash commands and web domains the rule goes into .claude/settings.local.json at the root of the git repository and applies to future sessions there. File-edit approvals last only until the session ends.

How to allow commands with /permissions

Type /permissions in a session. The dialog lists every permission rule and the settings file it comes from, and you can add or remove rules there. Changes apply from Claude's next tool call, even in the middle of a turn.

There are three kinds of rule:

  • Allow rules let Claude use a tool without asking.
  • Ask rules always prompt.
  • Deny rules block the tool.

Rules are checked in the order deny, ask, allow, and the first match wins. A deny rule beats any allow rule, even a narrower one, and that holds across settings scopes. A user-level deny blocks a project-level allow.

Allow rule syntax for Bash and other tools

A rule is a tool name, or a tool name with a specifier in parentheses. To allow every use of a tool, write the name alone. Bash matches all Bash commands, and Bash(*) means the same thing. Read and WebFetch work the same way.

For narrower rules, use a * wildcard. It matches any text, including spaces:

Rule Matches
Bash(npm run build) Only npm run build
Bash(npm run *) npm run build, npm run test --watch and bare npm run
Bash(git commit *) Any git commit command
Bash(ls *) ls and ls -la, but not lsof

Put the * after the subcommand. The docs warn that Bash(git *) allows every git command, while Bash(git log *) allows only git log.

Here is a settings file that allows npm scripts and commits but blocks pushes:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Claude Code understands shell operators. A rule for safe-cmd * does not cover safe-cmd && other-cmd. Every part of a compound command must be allowed before it runs without a prompt.

Allow rules for MCP tools are limited too. A glob is accepted only after a literal server prefix, so mcp__puppeteer__* allows every tool from the puppeteer server. An unanchored allow glob such as "*" or "mcp__*" is skipped and approves nothing. There is no single allow rule that approves every tool.

Switch the permission mode

Modes change how much Claude Code asks without you writing rules. The names below are the config values from the permission modes page.

Mode What runs without asking
default (Manual) Reads only
acceptEdits Reads, file edits and common filesystem commands such as mkdir, mv, cp and rm inside the working directory
plan Reads and read-only exploration. Edits stay blocked until you approve a plan
auto Everything, with a background classifier checking each action
dontAsk Only reads and pre-approved tools. Anything that would prompt is denied
bypassPermissions Everything, with a few exceptions

During a session, press Shift+Tab to cycle through modes. dontAsk is not in the cycle and has to be set with a flag. To start in a mode, use claude --permission-mode acceptEdits, or set permissions.defaultMode in ~/.claude/settings.json.

Project settings in .claude/settings.json honor every defaultMode value except auto and bypassPermissions. Setting either there has no effect.

If your goal is fewer prompts, the docs point to auto mode before bypass. Its classifier reviews actions in the background instead of you. We cover turning it on in how to turn on auto mode in Claude Code.

How to skip all permission prompts

The widest option is bypassPermissions. Start a session with either flag:

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

The two are equivalent. You can't switch into this mode from a session that didn't start with it enabled. You can also set permissions.defaultMode to "bypassPermissions" in your user settings. The first time, Claude Code shows a confirmation dialog, and declining exits Claude Code.

Some limits apply, per the docs:

  • On Linux and macOS it is refused when Claude Code runs as root or under sudo.
  • Sessions started with --restricted refuse it.
  • Cloud sessions ignore a bypassPermissions default from settings files.
  • Explicit ask rules and recognized critical-path rm and rmdir removals still prompt or deny.
  • Deny rules still block in every mode.

The risks of skipping permission prompts

Anthropic is direct about this mode. The docs say to use it only in isolated environments such as containers, VMs or dev containers without internet access, where Claude Code can't damage your host system. They also say it offers no protection against prompt injection or unintended actions.

Two details are worth knowing. In bypassPermissions, writes to protected paths are allowed, and that list includes .git, .claude, .vscode, shell startup files such as .bashrc and .zshrc, and .mcp.json. And the docs describe permission rules as enforced by Claude Code, not by the model, so telling Claude in a prompt or in CLAUDE.md to be careful does not restrict what it is allowed to do.

Narrow allow rules cost less in risk. They also have gaps: a deny rule such as Bash(rm *) stops rm -rf build/ but not /bin/rm -rf build/ or bash -c 'rm -rf build/', so the docs say such rules are not a security boundary around a program. For hard limits, they point to sandboxing.

How to stop others from using bypass mode

Set permissions.disableBypassPermissionsMode to "disable" in any settings file. It is usually placed in managed settings, where users can't override it, but an individual can also set it in their own settings to lock themselves out of the mode. permissions.disableAutoMode does the same for auto mode.

Where to go next

Start with narrow allow rules for the commands you approve most often, such as test and build scripts, and keep deny rules for anything destructive. Move to acceptEdits or auto if prompts still slow you down. Keep bypassPermissions for disposable environments. The permissions page lists every key and rule form.

Frequently asked questions

How do I skip permissions in Claude Code?

Start Claude Code with claude --dangerously-skip-permissions or claude --permission-mode bypassPermissions. The two are equivalent, and you can't switch into the mode from a session that didn't start with it.

How do I change the permission mode in Claude Code?

Press Shift+Tab during a session to cycle modes, start with --permission-mode, or set permissions.defaultMode in ~/.claude/settings.json. The dontAsk mode is not in the cycle and needs the flag.

Is it safe to use --dangerously-skip-permissions?

Anthropic's docs say to use it only in isolated environments such as containers or VMs. They state that bypassPermissions offers no protection against prompt injection or unintended actions.

Can I allow every Bash command with one rule?

Yes. An allow rule of Bash or Bash(*) matches all Bash commands. Deny rules still take precedence over it.

Sources

  1. Configure permissionsAnthropic
  2. Permission modesAnthropic