Claude Code --dangerously-skip-permissions: what it skips and what still holds

The short answer

It’s safe in an isolated container or VM with nothing valuable inside, which is what Claude Code’s own docs say the mode is for.¹ On your laptop with production credentials in .env, it isn’t. If you use it anyway, the things that still protect you are deny rules, which block in every mode, explicit ask rules, which still prompt, and the short list of critical rm paths Claude Code never auto-approves. Write deny rules for the commands you never want run before you turn the prompts off.

What the flag does

--dangerously-skip-permissions is the same as --permission-mode bypassPermissions.³ In that mode Claude Code skips permission prompts, including for writes to protected paths such as .git and .claude.² Allow rules have no effect, because there’s nothing left to allow.¹

Its sibling, --allow-dangerously-skip-permissions, adds bypass mode to the Shift+Tab cycle without starting in it, so you can switch in for one task and back out.³ That’s usually the better habit.

What still holds in bypass mode

The deny row is the important one. Claude Code evaluates rules deny first, then ask, then allow, and ask and deny rules apply when any part of a compound command matches.² So cd app && npx prisma migrate reset --force hits a deny rule on prisma migrate reset even though it starts with cd.

The ask row is useful too, with a caution. Ask rules aren’t airtight: in claude-code#80868, ask rules for npx prisma migrate:* were in place, yet a compound command with a command substitution ran prisma migrate diff against production with no prompt, and the database was wiped and restored from a nightly backup. That session was in auto mode, not bypass, but the lesson carries over: a rule matches text, and text can be arranged around it.⁵

A deny list to write first

Put this in .claude/settings.json for the project, or your user settings, before you ever start a bypass session. Adjust the commands to your stack:

Code Data in JSON, the format software uses to pass records and settings.

{
  "permissions": {
    "deny": [
      "Bash(npx prisma migrate reset*)",
      "Bash(npx prisma db push --force-reset*)",
      "Bash(npx drizzle-kit push --force*)",
      "Bash(*rails db:drop*)",
      "Bash(*rails db:reset*)",
      "Bash(*manage.py flush*)",
      "Bash(php artisan migrate:fresh*)",
      "Bash(php artisan db:wipe*)",
      "Bash(terraform destroy*)",
      "Bash(terraform apply -destroy*)",
      "Bash(kubectl delete namespace*)",
      "Bash(kubectl delete pvc*)",
      "Bash(git push --force*)",
      "Read(.env)",
      "Read(.env.*)"
    ]
  }
}

A * in a Bash rule can stand anywhere and match any text.² The Read(.env) lines keep the agent from loading the connection strings that turn a bad command into a production incident.

Deny rules have the same weakness as any text match: make teardown or a script that wraps one of these commands won’t match. So they’re a floor, not a ceiling.

A hook as a second check

A PreToolUse hook sees the command before it runs, in bypass mode too.⁴ Deedglass’s shell guard is one such hook: it reads every part of a Bash command, compares each with a dated catalog of commands that destroy data, and answers ask, or deny with --deny.⁶ In a bypass session there’s no one to ask, so --deny is the setting that fits.

What it answers on a few commands, from runs of 0.13.0 on 2026-10-27:⁶

Two things to know before relying on it. The docs say plainly that deny rules block in bypass mode; they don’t spell out the same for a hook’s deny, and we haven’t tested it across Claude Code versions, so treat deny rules as the documented layer and the hook as an extra one. And the guard reads text, so a variable or a wrapper script passes untouched;⁶ if it can’t run, the command goes ahead unchecked.⁶

Exit code 2 from a PreToolUse hook blocks the tool call, and a decision of deny is returned to Claude with the reason.⁴

Turn it off for a team

If your organization shouldn’t use bypass mode at all, set permissions.disableBypassPermissionsMode to "disable". It works from any settings file but is most useful in managed settings, where users can’t override it.² Sessions started with --restricted refuse bypass mode regardless.³

Code Data in JSON, the format software uses to pass records and settings.

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Our post on managed settings for teams covers where that file lives on each platform.

When bypass mode is the right call

There are real uses: long refactors in a throwaway container, batch migrations of test fixtures, CI jobs on an ephemeral runner. The pattern that makes them safe is the same each time:

1. A container or VM with only the repository mounted.
2. No production credentials in the environment, not even read-only ones you’d regret leaking.
3. Network limits where you can. Claude Code’s sandbox settings cover files and network for Bash.
4. Deny rules for destructive commands anyway, because containers mount volumes.
5. A diff review before anything leaves the container.

Questions people ask

Do deny rules work with –dangerously-skip-permissions?

Yes. Claude Code’s docs say deny rules block in every mode, including bypassPermissions.¹

Does bypass mode still ask about anything?

Yes: tools matched by an explicit ask rule, tools that need user interaction, and recognized critical rm and rmdir removals are never auto-approved in any mode.¹

How do I stop people using bypass mode?

Set permissions.disableBypassPermissionsMode to "disable" in managed settings.²

The rule system in full is in Claude Code permissions: deny, ask and allow, a hand-written hook is in the 14-line hook post, and installing a guard in every agent at once is in the protect walkthrough.

To see what your agent setup can reach, run npx deedglass scan in the repository (what the grade means), or watch the checks in the playground.

Written with AI assistance and checked against our claims register.