Reliability

3 Settings That Stop Claude From Wrecking Prod

5 minute readUpdated June 2026Explore more

TL;DR

One wrong command can wipe hours of work. Three settings stop Claude from ever wrecking prod: allowlist the tools it is permitted to run, deny the destructive ones outright (rm -rf, force-push, hard reset), and require approval before it writes. Set them once and you can move fast without the fear.

Why guardrails, not vigilance

Trusting yourself to catch every dangerous command in the moment does not scale - you will eventually approve one on autopilot. The fix is to make the dangerous ones impossible, not to watch harder. Permissions turn 'please be careful' into a wall the tool cannot walk through.

Setting 1: allowlist what it can run

Default to letting Claude run only the tools and commands you have named. Everything else asks first. This flips the model from 'anything unless blocked' to 'nothing unless allowed' - the safer default for anything near production.

Setting 2: deny the destructive ones outright

Some commands have no safe unattended use. Deny them explicitly so no prompt, mode, or mistake can run them: recursive deletes, force pushes, hard resets, and anything that drops data. A deny rule beats an allow rule when they overlap, so this holds even in permissive modes.

json{
  "permissions": {
    "allow": [
      "Read",
      "Edit",
      "Bash(npm run test:*)",
      "Bash(git status:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(git reset --hard:*)"
    ]
  }
}

Setting 3: require approval on writes

Reading is cheap and safe; writing changes the world. Keep writes - edits, commits, deploys - behind an approval so you see the diff before it lands. You can loosen this per project once you trust the setup, but start strict, especially anywhere with a real prod.

Put it together

  1. 1Allowlist the specific tools and commands your work actually needs.
  2. 2Deny the destructive commands explicitly - they never run unattended.
  3. 3Require approval on writes so nothing lands without you seeing it.
  4. 4Pair it with a PreToolUse hook if you want a scripted guard on top of the rules.

Common questions

  • Will locking permissions down slow me to a crawl?

    No - it removes the fear that slows you down. You allowlist the commands you actually use, so day-to-day work flows; only the rare, dangerous ones get stopped. Most people move faster once they stop double-checking every action by hand.

  • What if I allow a command and also deny it?

    Deny wins. That is by design - it means your blocks on destructive commands hold even when your allowlist is broad, so you cannot accidentally re-enable something dangerous by loosening a rule elsewhere.

  • Which commands should I always deny?

    The ones with no safe unattended use: recursive deletes (rm -rf), force pushes, hard resets, and anything that drops a database or overwrites data you cannot get back. If a mistake there is unrecoverable, it belongs on the deny list.

  • Is this different from just using plan mode?

    Yes, and they pair well. Plan mode makes Claude think before acting; permissions decide what it is even allowed to do. Plan mode is judgment, permissions are the hard limit - use both for anything near production.

Want the guardrails config, ready to paste in?

Get 650+ plug-and-play skills, MCPs & prompts, plus 5,000+ builders - $9/mo, cancel anytime.

Join the Club