Fix Claude Code Approval Fatigue Without Skipping Permissions

You pointed Claude Code at real work, and now you're clicking "approve" on every file read, every command, every write. That defeats the whole point — you wanted to stop babysitting, not trade one kind of supervision for another. The obvious escape hatch, --dangerously-skip-permissions, hands the agent everything your user account can reach, which is a different problem wearing a shortcut's clothes.

Quick answer: To fix Claude Code approval fatigue without --dangerously-skip-permissions, pre-approve a scoped list of safe commands with allow-rules, run the agent inside a sandbox or container, allowlist only the MCP servers you trust, and keep the ask-gate on sensitive writes. The agent then runs unattended on the boring 95% while the risky 5% still stops for you.

What "dangerously skip permissions" actually turns off

The --dangerously-skip-permissions flag disables every approval prompt in Claude Code, letting the agent read, write, run shell commands, and hit the network without asking. It runs with the exact reach of your user account — your files, your credentials, your cloud CLIs that are already logged in.

The flag has a real use: throwaway work inside a locked-down container where there's nothing to lose. The danger is running it on your actual machine. Two failure modes matter here. The first is what Lasso Security calls "intent deviation" — the agent helpfully edits or deletes something you never asked it to touch, because it decided that was the tidy thing to do. The second is prompt injection: a poisoned file, web page, or tool response tells the agent to exfiltrate a secret or run a destructive command, and with permissions off there's nothing between that instruction and your system.

TrueFoundry and practitioner Pasquale Pillitteri both document the same conclusion in their Claude Code writeups: the skip flag trades a UX annoyance for a standing security hole, and the safer route is scoped allowedTools plus a deliberate permission mode. Anthropic's own post on the topic names "approval fatigue" as the exact problem sandboxing is designed to solve — read-only by default, with filesystem and network isolation, so most actions stop needing a prompt at all.

How to pre-approve the boring 95% with allow-rules

Approval fatigue comes from Claude asking about actions that were never risky in the first place — listing files, reading a config, running a test. You fix that by telling Claude Code once which commands are always fine, so it stops asking about them and only interrupts you for the stuff that can actually cause damage.

Claude Code keeps these decisions in a settings file (.claude/settings.json in your project, or the global one in your home directory). You maintain three buckets: an allow list that runs without asking, an ask list that always stops for you, and a deny list the agent can never touch.

Start with read-only and safe commands on the allow list

Put the actions that can't hurt you on the allow list first: reading files, listing directories, running your test suite, git status and git diff. In practice this is where most of the friction lives, and clearing it removes the bulk of the clicks.

A starting allow list for a typical business project looks like this:

{
  "permissions": {
    "allow": [
      "Read",
      "Bash(ls:*)",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)"
    ]
  }
}

Each entry is a scoped rule, not a blanket grant. Bash(git diff:*) approves git diff and its arguments — it does not approve git push, rm, or anything else. That specificity is the whole point: you're widening the lane for safe traffic, not opening the gate.

Keep sensitive writes and network calls on the ask list

Reserve the ask-gate for the small set of actions that change the outside world: pushing code, deleting files, sending email, hitting a payment or CRM API, running deploy commands. These are the 5% where a wrong move actually costs you, so they should still stop and wait for a human yes.

The deny list is your hard floor — commands the agent may never run under any mode, like rm -rf, git push --force, or reading a secrets file. A deny rule wins even if an allow rule would otherwise match, so it's your backstop against the agent talking itself into something clever.

Why the sandbox matters more than the rules

Allow-rules decide what the agent asks about; a sandbox decides how much damage is possible when something slips through anyway. Run Claude Code inside a container or Anthropic's native sandbox and the agent's filesystem and network access are boxed in — even a successful prompt-injection attack can't reach your real credentials or your production database, because they aren't in the box.

This is the piece most founders skip because it sounds like developer plumbing, and it's the one that lets you actually walk away. Sandboxing is what makes read-only-by-default safe: when the agent literally cannot touch anything outside its container, most of its actions no longer need a prompt, and approval fatigue collapses on its own. The rules and the sandbox work together — rules cut the number of prompts, the sandbox caps the blast radius of the prompts you didn't catch.

If you're running scheduled, unattended work like a nightly report or inbox triage through Claude Code Routines, the sandbox stops being optional. Nobody's watching a 2am run, so the container is the only thing standing between a bad instruction and your files.

Allowlist only the MCP servers you actually trust

Every MCP server you connect is a new door into the agent's world, so treat the connector list like a guest list, not a buffet. Connect the three or four tools you genuinely use — your calendar, your CRM, your docs — and leave the rest off. Extra servers don't just add risk; they inflate the agent's context and make it slower and dumber, and a single MCP tool output past roughly 10K tokens can start crowding out the actual work.

The trust question is concrete: an MCP server can read whatever you connect it to and can return instructions the agent will act on. A server you didn't vet is a prompt-injection vector by design. Add connectors through Settings → Connectors, add them one at a time, and confirm each one earns its place before the next goes on. If a tool only matters for one occasional task, connect it for that task and disconnect it after.

Manual approval vs. gated autonomy

The instinct when Claude Code gets annoying is a binary: either approve everything by hand or flip the skip flag and hope. The honest setup is neither — it's graduated autonomy where the gates stay on for the parts that matter.

The middle column exists for exactly one situation: a disposable container where nothing you care about is reachable. Everywhere else, the right-hand column is the version that lets you stop being the quality check without handing over the keys. This is the same graduation logic that works for support agents — StackAI's line that "the quickest way to lose customer trust is to push full autonomy too early" applies just as cleanly to letting an agent loose on your own machine.

Common pitfalls that reintroduce the risk

Most people who set up allow-rules still get bitten, usually by one of a handful of shortcuts that quietly undo the whole point.

Getting these rules right is fiddly the first time, which is why the Claude Community shares copy-paste settings templates — a starting .claude/settings.json, a sane MCP allowlist, and the deny list — so you can graduate an agent's autonomy without writing the config from scratch. If you'd rather have the whole thing set up and running inside your business in under 30 days, 6omb's agency does the build.

FAQ

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

The --dangerously-skip-permissions flag is safe only inside a disposable sandbox or container where the agent can't reach anything you'd mind losing — no real files, no logged-in credentials, no production access. On your actual machine it gives the agent the full reach of your user account, which is why TrueFoundry and other practitioners recommend scoped allowedTools and a deliberate permission mode instead.

How do I stop Claude Code from asking to approve every action?

You stop the constant prompts by adding safe, read-only commands to the allow list in your .claude/settings.json — file reads, directory listings, tests, git status — so Claude Code runs them without asking. Keep sensitive actions like pushes, deletes, and API calls on the ask list, and the interruptions drop to only the handful that can actually cost you something.

What's the difference between allow-rules and a sandbox?

Allow-rules decide which actions Claude Code performs without asking you, while a sandbox limits how much damage any action can do by boxing the agent's filesystem and network access. You want both: rules cut the number of approval prompts, and the sandbox caps the blast radius if a prompt-injection attack or a bad decision slips past the rules.

Do I need to be a developer to set up Claude Code permissions safely?

You don't need to write code to set up Claude Code permissions — the rules live in a plain settings file you edit once, and copy-paste templates get you a working allow list, MCP allowlist, and deny list without building it yourself. Running the agent inside a sandbox and connecting only trusted MCP servers through Settings → Connectors are both point-and-click steps a non-developer can follow.

Join the free Claude Community to grab the config templates and set up gated autonomy in an afternoon — so your agent runs the boring work unattended while the risky 5% still stops for you.