‘--dangerously-skip-permissions still won’t let rm -rf through’: what’s actually proven, and how to protect your machine

A Claude Code engineer announced CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS, an env var that turns off the safety net against rm -rf ~. It first appeared in a post and in npm 2.1.311; the official docs now describe it. Checklist for --dangerously-skip-permissions.

Security · Yoseph Franco · October 27, 2026 · 10 min read · Leer en español

Abstract illustration of a terminal running rm -rf beside a warning triangle and a cracked shield

In this article

If you run Claude Code with --dangerously-skip-permissions, you probably assume one of two things: either the mode approves literally everything, or no matter what, an rm -rf on your home directory will never run. Both are wrong, and as of yesterday there's one more reason to revisit them.

Update, October 27, 2026: CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS is now in the official Claude Code docs, on the environment variables page and in permission modes. It requires Claude Code v2.1.311 or later. Set to 1, it runs Bash rm and rmdir commands that target critical paths with no prompt, only in bypassPermissions mode itself, not in plan mode or any other mode. It applies only to what the critical-path check flags in the Bash and Monitor tools, including commands Claude Code cannot fully parse. Claude Code reads it from the launch environment only and ignores it in a settings file's env block. At startup it prints a line that says one of these: "is set, so dangerous rm commands can run without a prompt", "has no effect in this session", or "has no effect while the Windows registry cannot be read for managed settings". Official warning: "With this variable set, you lose a safety prompt for destructive deletes: a command such as rm -rf ~ can run without asking you. Set it only in an isolated environment whose contents you can afford to lose."

The docs show this generic launch on macOS, Linux, or WSL. Set the variable in that shell, then start Claude Code from there:

export CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

On Monday, October 26 at 19:09 UTC, Daisy Hollman, who describes herself on X as working on Claude Code at Anthropic, posted that --dangerously-skip-permissions "doesn't actually approve EVERYTHING": it still blocks obvious things like rm -rf ~. She added that that day's release lets you turn the protection off with a new env var: CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1.

Two notes up front. First, the variable first appeared in that post on October 26 and in npm 2.1.311. When this note went up (October 27, 11:45 UTC), neither the official docs nor the public changelog listed it yet. Later the same day the docs added it. The public changelog still does not mention the name: the 2.1.311 section is silent, and searching the file for EVEN_MORE returns nothing. Second, I did not test what the variable does. I did run one check of my own on the published package, covered below. What the variable does, in the update above, comes from the official docs. The rest of this note comes from the official docs and the changelog.

What the post says, according to Daisy Hollman

The full text: "Fun fact: --dangerously-skip-permissions doesn't actually approve EVERYTHING—we still block some obvious things like rm -rf ~. But today's release will let you disable this if you really want, by setting a new env var CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1".

Her bio says views are her own. When someone replied that they hoped it wasn't a joke, she answered: "Not a joke!" When I checked, the post had about 190,000 impressions and 1,900 likes.

### From the post and npm to the official docs

Status: documented on October 27, 2026. Version 2.1.311 of @anthropic-ai/claude-code was published to npm on October 26 at 19:47 UTC, about 38 minutes after the post. That was the first published package where the name shows up. The environment variables page and the permission modes page now describe it. The 2.1.311 section of the official CHANGELOG still does not mention the variable, and searching the whole file for EVEN_MORE returns nothing. The settings page still does not name it; the other two pages say a settings env block is ignored.

### My own check on the package

Status: my own check, not documentation. I downloaded the Linux x64 binary for version 2.1.311 from npm and searched it. The string CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS shows up several times, right next to other variables that tune the dangerous-rm prompt. It does not appear in the 2.1.310 binary. So the name shipped in 2.1.311. That check does not say what it does. The docs now do, and I still have not run it.

What is documented: the rm -rf safety net

This is the prompt the variable turns off in bypassPermissions mode. Per the permission modes docs:

bypassPermissions, the mode --dangerously-skip-permissions turns on, "disables permission prompts and safety checks", and the docs recommend it only for "isolated containers and VMs".
Even so, some actions are never auto-approved in any mode. One of them is what the docs call critical-path removals: rm and rmdir commands aimed at a critical path. No allow rule and no PreToolUse hook returning "allow" approves them.
Critical paths include the filesystem root, top-level directories like /usr or /etc, your home directory, your working directory and its parents, plus traps like rm -rf "$DIR"/*, which becomes a wipe from root if the variable is empty.
In bypassPermissions, in the terminal, Claude Code asks you to confirm with a two-minute countdown. If nobody answers, it denies the command and tells Claude what to do instead. After three unanswered prompts in a session, it denies further ones immediately.

So the post says "block", while the docs describe a prompt that ends in a denial if you don't answer. In practice the outcome is similar. The difference matters when someone is watching the terminal and hits "yes" on autopilot.

The twist: the safety net was never a sandbox

The docs say it plainly: the check "can miss some commands, so it doesn't replace an operating-system control such as sandboxing." A command the check misses gets no special handling, so bypassPermissions approves it without asking. And the check only looks at rm and rmdir; other approved commands can delete critical paths too.

The changelog shows that net being patched release after release. The new variable doesn't switch off something airtight. It switches off something that already had gaps and was still being tightened.

Receipts

Before you grant access

One email a week on what I test around access, accounts and agents, plus the measured list-cost table (list USD, not the amount billed). It is not a downloadable checklist.

Proven vs claimed vs myth

| Claim | Status | Why | | :- | :- | :- | | --dangerously-skip-permissions approves everything | False | The docs list actions no mode auto-approves, including critical-path removals | | deny rules still work in bypass mode | Proven | Docs: "Deny rules block in every mode, including bypassPermissions" | | There's a variable that turns off the rm -rf ~ prompt in bypassPermissions | Documented | The permission-modes page says so, for Claude Code v2.1.311 or later, and only in that mode. It first appeared in the Oct 26 post and in the 2.1.311 binary. The changelog still has no entry | | The safety net protects you from any deletion | False | The docs say it can miss commands and only covers rm and rmdir | | A container solves everything | False | The dev container guide warns that in bypass mode a container doesn't stop exfiltration of anything inside it, including Claude Code's credentials in ~/.claude | | Claude Code refuses bypass mode as root | Proven | On Linux and macOS it rejects --dangerously-skip-permissions under root or sudo, except inside a recognized sandbox |

Checklist: running --dangerously-skip-permissions without handing over your machine

The idea is simple: if you're switching off a safety net, put a different floor under it. The snippets are generic; adapt them to your project.

1. Never on your daily machine. The docs limit this mode to containers, VMs, or dev containers. If you don't have one set up, use auto mode or the Bash sandbox instead of bypass.

2. A container with an unprivileged user. Claude Code already refuses bypass as root. Pin it yourself anyway:

bash docker run --rm -it \ --user 1000:1000 \ -v "$PWD":/workspace -w /workspace \ your-image-with-claude-code \ claude --dangerously-skip-permissions

Mount only the project folder. No -v "$HOME":....

3. No mounted credentials. No ~/.ssh, no ~/.aws, no cloud credential files. The dev container guide recommends repo-scoped or short-lived tokens passed in as environment variables.

4. An egress allowlist, not open network. Claude Code has to reach its API, so cutting the network entirely doesn't work. The reference container ships an init-firewall.sh script that restricts outbound traffic. For Bash commands, the sandbox takes a domain list:

json { "sandbox": { "enabled": true, "allowUnsandboxedCommands": false, "network": { "allowedDomains": ["github.com", "*.npmjs.org"] } } }

allowUnsandboxedCommands: false disables the retry-outside-the-sandbox escape hatch, which bypass mode would otherwise approve silently.

5. Work in a worktree or from a clean commit. Before you let the agent loose, make sure git status is clean and commit. Better yet, use a separate branch with the worktree flag:

bash git status # nothing uncommitted claude --worktree refactor-task

Note that a worktree isolates git changes, not your disk. rm -rf is still rm -rf.

6. deny rules in settings.json. They apply even in bypass mode. Syntax per the permissions docs:

json { "permissions": { "deny": [ "Bash(rm -rf *)", "Bash(rm -fr *)", "Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)" ] } }

Documented limit: a Bash rule matches the command text. Bash(rm *) stops rm -rf build/ but not /bin/rm -rf build/ or bash -c 'rm -rf build/'. It's a speed bump, not a wall.

7. A PreToolUse hook that blocks rm -rf. The hooks guide uses exactly this case: a script that exits with code 2 denies the call and feeds its stderr back to Claude. In .claude/settings.json:

json { "hooks": { "PreToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-rm-rf.sh" } ] } ] } }

And the script at .claude/hooks/block-rm-rf.sh (needs jq and execute permission):

bash #!/bin/bash COMMAND=$(jq -r '.tool_input.command // empty') if echo "$COMMAND" | grep -Eq '(^|[^[:alnum:]_])rm[[:space:]]+-[[:alpha:]]*[rR]'; then echo "Blocked: recursive rm is not allowed in this session" >&2 exit 2 fi exit 0

Same limit as the rules: it reads text. A Python script that deletes files sails right past it.

8. Backups the agent can't reach. Push to a remote before you start and keep disk backups outside the container's reach. When everything else fails, that's what saves your afternoon.

9. If you run a team, turn bypass off. Setting permissions.disableBypassPermissionsMode to "disable" in managed settings makes Claude Code reject --dangerously-skip-permissions.

10. Don't flip the new variable out of curiosity. The official warning says: "Set it only in an isolated environment whose contents you can afford to lose." If you really need it, use it inside a throwaway VM, like the user who replied to Daisy saying they spin up a fresh VM per task. Outside of that, there's no good reason to remove the last net you have.

Bottom line

The news isn't that Anthropic now lets you switch off the rm -rf ~ protection. The news is that a lot of people learned yesterday that the protection existed, and almost nobody knew it has documented gaps. If your safety with --dangerously-skip-permissions rested on Claude Code "not letting" an rm -rf through, it already rested on something the official docs tell you not to treat as a boundary. Real isolation lives in the container, the egress allowlist, the missing credentials, and the backups. The new variable just makes that harder to ignore.

FAQ

Does --dangerously-skip-permissions let rm -rf through? It depends on the target. Per the docs, an rm or rmdir aimed at a critical path (root, home, working directory) prompts in the terminal and is denied if nobody answers within two minutes. An rm -rf on any other folder, or one the check doesn't recognize, runs without asking.

What does CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS do? Per the permission-modes docs, set to 1 in the launch environment it lets Bash and Monitor rm and rmdir commands that the critical-path check flags run with no prompt, only in bypassPermissions mode, not in plan mode. It requires Claude Code v2.1.311 or later, and a settings env block is ignored. It first appeared in Daisy Hollman's post and in npm 2.1.311. The public changelog still does not mention it. I have not tested its behavior.

Do permissions.deny rules work in bypass mode? Yes. The docs say deny rules block in every mode, including bypassPermissions. But they match command text, so variants like /bin/rm or bash -c '...' can slip past.

Is a Docker container enough? It helps a lot, but not on its own. The docs warn that in bypass mode a container doesn't stop exfiltration of what's inside, including Claude Code's credentials. Add an unprivileged user, an egress allowlist, no mounted credentials, and backups.

Can I stop my team from using --dangerously-skip-permissions? Yes: set permissions.disableBypassPermissionsMode to "disable" in managed settings.

‘--dangerously-skip-permissions still won’t let rm -rf through’: what’s actually proven, and how to protect your machine

What the post says, according to Daisy Hollman

What is documented: the rm -rf safety net

The twist: the safety net was never a sandbox

Receipts

Before you grant access

Proven vs claimed vs myth

Checklist: running --dangerously-skip-permissions without handing over your machine

Bottom line

FAQ

Sources

Keep reading

Before you ask an AI to audit your code: is your account at risk?

What an AI Agent Sees When You Share a Card or Password

Before you grant access