How to Make Claude Code Stop Asking for Permission

The fast answer: add allow rules for the exact commands you keep re-approving to permissions.allow in a settings file, scoped to a command prefix rather than the whole Bash tool. That stops the prompts for your build, your test runner, and anything else you already trust, without opening up commands you have never seen. A settings file also has other levers: switch the whole session’s permission mode with Shift+Tab, or start with a mode already set. “Give it all permissions” is a real, named mode, and it is covered below, but it is the wrong default for most people: it turns off almost every safety check, not just the prompts.

The allowlist that actually stops the prompts

Open ~/.claude/settings.json (or .claude/settings.json in your project) and add rules for the commands you re-approve most:

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

The rule format is Tool or Tool(specifier), per the permissions reference. A bare Tool covers every use of that tool; a specifier narrows it. A trailing * (a space, then an asterisk) enables prefix matching: Bash(npm run test *) matches npm run test, npm run test --watch, and anything else that starts with npm run test, but not npm run testing or npm install. The space before the asterisk matters: Bash(ls*) with no space also matches lsof, which Bash(ls *) does not. :* at the end works the same as a trailing *. A bare tool name like Bash on its own, or Bash(*), matches every Bash command and removes the whole tool from approval checks when used as a deny rule, so scope to a command prefix instead of allowing the whole tool.

One thing worth knowing before you write rules for git status, ls, or grep: you do not need to. Claude Code recognizes a built-in set of read-only commands: ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd, and read-only forms of git. It runs them without a prompt in every permission mode already, and the set is not configurable. The one exception is a path fenced off by permissions.blockReadsOutsideWorkingDirectories. The commands worth allowlisting are the ones that write or execute something: a build, a test runner, a commit. Read the permission rule syntax reference for the full pattern grammar, including how shell operators like && and | are matched per subcommand rather than as one string.

Where the settings file lives, and which one wins

Claude Code reads four files, plus organization-managed settings:

Put your personal allowlist in ~/.claude/settings.json if you want it everywhere, or in the project’s .claude/settings.json if you want your whole team to stop hitting the same prompts. When the same key is set in more than one file, list values like permissions.allow are combined rather than one file replacing another; a plain value like defaultMode follows precedence, with managed settings outranking everything and .claude/settings.local.json outranking the committed .claude/settings.json. Full detail is in the settings reference.

The other keys under permissions

allow, deny and ask are the rule lists, but they are not the whole block. The rest are the ones a team reaches for once one person’s allowlist becomes everyone’s policy.

The last two only mean anything in managed settings: setting them in your own user file is a note to yourself, not a control. Full descriptions are in the settings reference.

The permission modes

A mode sets the session’s default answer to “does this need to ask me first.” Rules layer on top of whatever mode you are in.

Plan mode is worth using deliberately, not just as a stop on the way to something else. It has Claude read the codebase, run exploration commands, and write out a proposed change, but it blocks edits until you approve the plan. That matters because rework is expensive: catching a wrong assumption in a plan costs you a read; catching it after Claude has already rewritten six files costs you a revert. Approving a plan hands you a choice between switching to auto mode, accepting edits one at a time, or sending Claude back to keep planning.

auto mode is the one that removes the most prompts without you naming individual commands: a separate classifier model reviews each action and blocks things like credential exfiltration, production deploys, or force pushes by default, while routine work runs straight through. It is the built-in starting mode on Pro, Max, and Team plans as of recent versions, and it requires a supported model. See Choose a permission mode for the exact list of what the classifier blocks and allows by default, and how to add your own boundaries on top of it.

The full-bypass option, and when it is reasonable

bypassPermissions mode, entered with claude --permission-mode bypassPermissions or the shorthand --dangerously-skip-permissions, disables permission prompts and most safety checks so tool calls run immediately, including writes to paths every other mode protects. Use it inside a container, VM, or a throwaway worktree with nothing sensitive on disk, or in CI where the whole point is unattended execution; never on your main checkout with real credentials sitting in .env files or your shell history, because there is nothing left to stop a bad command once you are in this mode.

Non-interactive runs: this is where permissions actually bite

A headless claude -p run cannot show you a prompt. There is no terminal waiting for a keypress. So the default starting mode for -p is Manual on every plan, and anything that would need approval and has nobody to answer it gets denied rather than left hanging:

claude -p "run the test suite and fix any failures" \
  --allowedTools "Bash(npm test),Read,Edit"

--allowedTools (or --disallowedTools to deny) takes the same rule syntax as permissions.allow in a settings file. You can also set the whole run’s baseline with --permission-mode, the same values as the interactive modes: --permission-mode dontAsk for a locked-down CI job that should only ever touch what you named, or --permission-mode auto if you want the classifier reviewing actions instead of a fixed allowlist. If you are running scheduled or unattended and want to be explicit that nobody is watching, --permission-prompts none tells Claude Code not to wait on or retry anything that would otherwise need a human answer. For everything else about running Claude Code unattended, see our headless mode guide.

Keep the allowlist from going stale

An allowlist you build by hand tends to grow one entry at a time and never gets pruned. The useful habit is periodically checking which commands you keep approving by hand and promoting the safe, repeated ones into permissions.allow, rather than letting the same prompt interrupt you every session. A PreToolUse hook can also make an allow or deny decision programmatically, based on the actual command or file being touched, instead of a static pattern list; that is worth reaching for once your rules get complicated enough that a flat allowlist cannot express the distinction you want. See our hooks guide for how that wiring works.

The shiploop angle

shiploop’s background workers run non-interactively and never wait on a prompt: each is dispatched with --permission-mode bypassPermissions by default ($permflag, overridable via GOVERN_PERMISSION_MODE) and a fixed --tools allowlist rather than the full default tool set, so a worker only has the calls its job actually needs. That combination, an explicit permission mode plus a trimmed tool budget, is what makes fleets of unattended agents practical instead of something that silently hangs on the first unapproved call. It is a fit for headless, disposable worktrees, the same isolation this page recommends for bypassPermissions generally, not for an interactive session on a machine with real credentials.

Further reading: permission modes and settings are the two primary docs behind this page. See also our guides on token usage and worktrees, or browse all guides.

Last updated 2026-09-04.