How to Stop Claude Code Asking for Permission

Those permission prompts feel like friction, especially on the tenth time you approve the same harmless git status. But they exist for a good reason, and the goal isn't to switch them off — it's to teach Claude Code exactly which actions it can take silently and which still deserve a human glance. This guide walks through how to stop Claude Code asking for permission in graduated steps, safest first, so you keep the guardrails that matter while losing the noise that doesn't. The permission model works the same whichever model you're currently running — Claude Opus 4.8, Sonnet 4.6, or Haiku 4.5 — and the 4 approaches below take about 10 minutes to set up once.

If you're brand new to the tool, our explainer on what Claude Code is gives you the bigger picture before you start tuning its behavior.

Why Claude Code asks for permission in the first place

Claude Code is an agent that runs in your terminal with real access to your machine. It can read and edit files, run shell commands, call MCP servers, and touch anything your user account can. That power is the whole point — and it's also why the permission prompt exists.

By default, before Claude Code runs a command or edits a file, it pauses and asks you to approve. Read-only, non-destructive actions (viewing files, searching code, planning) generally run without a prompt, while anything that changes state — writing a file, running npm install, deleting something — triggers a confirmation. It's a guardrail against an agent doing something you didn't intend: overwriting the wrong file, running a destructive command, or pushing code before you've reviewed it.

The prompts are annoying precisely because they're doing their job. So the smart move to stop Claude Code asking for permission isn't to rip the guardrail out — it's to tell Claude Code, precisely, which actions you've already decided are safe. That's what Claude Code permissions are for.

The safe ways to stop Claude Code asking for permission

There are four practical levers to stop Claude Code asking for permission, and they line up neatly from safest to riskiest:

1. Approve for the session — say "always allow" when a prompt appears for a command you trust.
2. Write permission rules in settings.json — codify your allow, ask, and deny lists.
3. Trust the project folder — vouch for one working directory, not your whole machine.
4. Skip permissions entirely — the --dangerously-skip-permissions flag, sandbox only.

Work down the list: exhaust the gentle options before you even consider the aggressive ones, and you'll rarely need the last one at all.

Option 1: Approve for the session (safest, start here)

The gentlest way to reduce prompts is to handle them as they come up. When Claude Code asks to run a command or edit a file, most prompts offer more than a plain yes/no — one option is usually along the lines of "Yes, and always allow this command" (or "don't ask again for this tool"). Choosing that approves the action for the rest of the session and, in many cases, writes a matching rule into your settings so it persists.

This session-by-session approach is the recommended way to build up your Claude Code permissions organically, and it's usually enough to stop Claude Code asking for permission on your day-to-day commands. You approve a safe, repetitive command once — git status, your test runner, a linter — and it stops asking. You never grant blanket trust; you grant it one specific pattern at a time, right when you can see the exact command in front of you.

You can review everything you've approved with the in-session /permissions command (sometimes aliased /allowed-tools), which opens an interactive view of your active allow, ask, and deny rules. It's a good habit to glance at that list occasionally and prune anything too broad.

Option 2: Configure permission rules in settings.json

Once you know which commands you always trust, codify them. Claude Code reads a settings.json file with a permissions object containing allow, ask, and deny lists. User-wide settings live at ~/.claude/settings.json; project-shared settings live at .claude/settings.json inside the repo; and personal, uncommitted overrides go in .claude/settings.local.json. If you're unsure which of those three files a given rule should go in, our practical guide to Claude Code settings and settings.json walks through how the scopes override one another.

The three rule types map to three behaviors, and the way they interact is the key to using an allowlist tools setup safely:

Rules are evaluated in order of precedence: deny first, then ask, then allow, and the first match wins. That means a deny rule always beats a broader allow rule — a crucial safety property. You can allow a whole category of commands and still carve out the dangerous ones with an explicit deny.

Here's a small, illustrative snippet. Treat it as a starting shape, not gospel — the exact schema evolves, so confirm against the official docs before relying on it:

{
  "permissions": {
    "allow": [
      "Read",
      "Edit",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(npm run test:*)"
    ],
    "ask": [
      "Bash(git push:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(curl:*)"
    ],
    "defaultMode": "default"
  }
}

A few things worth understanding about the matching. Patterns like Bash(npm run test:*) use a prefix with a wildcard, so they match npm run test, npm run test:unit, and so on — but not an unrelated command. Broad tool names like Read and Edit allow that whole class of action. The deny entries above make sure a reckless delete or an arbitrary network call still gets stopped even if your allowlist is generous elsewhere. Keep your deny patterns narrow, though: a rule that blocks writes to a path you actually work in shows up later as a confusing Claude Code error editing file rather than an obvious permission message.

This is where you get the biggest win in your effort to stop Claude Code asking for permission: a well-tuned allow list handles the 90% of routine, safe actions silently, while ask and deny keep a tight leash on the rest. Because the project file can be committed, your whole team inherits the same Claude Code permissions — which pairs nicely with a good CLAUDE.md configuration file for consistent agent behavior across the repo.

Be extra deliberate about deny rules when you use MCP servers or delegate work to subagents, since those expand what the agent can reach beyond your local shell.

Option 3: Trust a project or folder

Claude Code also tracks whether you trust a given directory. The first time you run it in a new folder, it typically asks you to confirm you trust that codebase before it will act freely there. Marking a project as trusted reduces the repeated "are you sure" friction for that working directory specifically.

This is scoped trust, not global trust — you're vouching for one folder, not every folder on your machine. Keep it that way. Don't reflexively trust directories you cloned from the internet without reading them first; a repo can carry instructions or hooks that influence what the agent tries to do. Trust the projects you own and understand.

Option 4: The nuclear option — --dangerously-skip-permissions

There is a flag that turns off the prompts entirely: claude --dangerously-skip-permissions, nicknamed "YOLO mode." It does what the name warns — it skips permission prompts so Claude Code reads, writes, and runs commands without stopping to ask. Some people alias it (alias yolo='claude --dangerously-skip-permissions') or set "defaultMode": "bypassPermissions" in settings to make it the default. If that mode isn't even selectable for you, our explanation of why bypass permissions is greyed out covers the usual causes, from a managed admin policy to running as root.

It is genuinely useful in the right place, and genuinely dangerous in the wrong one. The right place is a sandboxed, disposable environment: a container, a VM, or a throwaway clone where a bad command can't hurt anything that matters. The wrong place is your main machine, a repo with production credentials, a folder full of personal files, or anywhere a destructive command could cause real loss. An agent moving fast with no prompts and a bad instruction is exactly how people end up in a situation like Claude Code deleting a database.

If you do use it, stack up your own safety net: work inside a container or VM, commit to git first so everything is recoverable, keep backups, and never point it at secrets. Anthropic has also introduced a safer "auto mode" that aims to cut interruptions without fully removing the guardrails — a better middle ground than the raw skip flag for many workflows. Newer versions also keep certain hard stops (like rm -rf /) and honor deny rules even when prompts are skipped, but you should never rely on those as your only defense.

The honest recommendation: prefer scoped allowlists over the blanket skip. A tuned settings.json gets you most of the quiet, with almost none of the exposure. Reach for --dangerously-skip-permissions only when you've deliberately isolated the environment — the unattended Ralph loop technique that circulates in the community is the classic example, and it depends entirely on being sandboxed to be defensible at all.

Putting it together: a safe order of operations

Start by letting Claude Code prompt you normally, and use "always allow" for the safe, repetitive commands as they appear. Every few sessions, open /permissions and promote the patterns you trust into your project settings.json allow list, while adding deny rules for anything you never want run. Keep folder trust scoped to projects you own. And save the skip flag for a sandbox.

Done in that order, you'll stop Claude Code asking for permission for everything routine while keeping firm control over the actions that genuinely warrant a second look. If security is a priority for your team, it's worth pairing this with a periodic Claude Code security review so your permission rules and your codebase stay aligned.

The prompts were never the enemy — untuned prompts were. Tune them, and Claude Code gets quiet and safe at the same time.

Tempted to turn approvals off entirely? Read dangerously skip permissions first — it belongs in a throwaway sandbox, never on real work.

For the full picture behind these prompts, Claude Code permissions explains the allow/ask/deny rules, the six modes, and how deny always wins across every settings file.