Claude Code 2.1.311 adds an env var that skips even the last dangerous-command safeguard
Claude Code 2.1.311 (October 26) added CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1: `rm -rf ~` runs with no prompt in bypassPermissions mode.

Claude Code, Anthropic’s terminal-based coding agent, picked up a new environment variable in version 2.1.311, published to npm on October 26, 2026 at 19:47 UTC: CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS. The official permission-modes documentation has a dedicated section stating that setting it to 1 lets rm -rf ~ — a recursive delete of your home directory — run without any confirmation in bypassPermissions mode. The Register reported it first on October 28 (per IT之家’s translation), and the name is blunt enough that people initially took it for a joke; an Anthropic engineer has since confirmed it is not. The docs also set the boundary: only use it where the contents are disposable.
Key points
- Variable and version:
CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1requires Claude Code 2.1.311 or later (npm publish: October 26, 19:47 UTC). We compared binaries: 2.1.310 contains no trace of the string; 2.1.311 contains it 13 times. - Scope: it only lifts the critical-path check on
rm/rmdirin the Bash and Monitor tools, only in bypassPermissions mode, and it even passes through deletion commands the tool cannot fully parse. - The off-ramps outnumber the on-ramp: the docs list nine situations where it silently does nothing — from deny rules and PermissionRequest hooks to the VS Code panel and nested sessions. Any one of them restores the usual prompts.
Background
Claude Code’s existing “skip everything” flag, --dangerously-skip-permissions, is equivalent to bypassPermissions mode: tool calls stop asking one by one, but they are not unconditional. Deletion commands get a separate critical-path check — filesystem root, home directory, the working directory and its parents, mounted drives — and that check fires even in bypassPermissions mode. YOLO mode, until now, could wipe your project but not your home directory.
The new variable removes that last layer. Set against the rest of Anthropic’s autumn, the company is walking two lines at once: tightening — from October 22, most Claude apps made auto mode (automated approval) the default for new sessions, as our earlier report covered, with the caveat that its 89% block-rate figure applies to Claude Code only — and leaving back doors like this one for power users, with a name that does not pretend to be subtle.
The facts
The official permission-modes section (read October 29) lays out verifiable conditions:
| Item | Documented behavior |
|---|---|
| Variable and value | CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 |
| Version | Claude Code 2.1.311 or later |
| Where it is read | Launch environment only (your shell or the SDK’s env option); ignored in a settings file’s env block |
| Mode | bypassPermissions only; plan mode unaffected |
| What it lifts | Critical-path rm/rmdir checks in the Bash and Monitor tools, including unparseable commands |
| How to verify | A startup line such as is set, so dangerous rm commands can run without a prompt |
| Official warning | “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 suppression list runs to nine cases, a few of which are worth memorizing: a deny or ask rule covering Bash disables it for the whole session even if you delete the rule mid-session; sessions run from the VS Code chat panel or the desktop app never get it, terminal only; a claude launched from inside another session (say, through an agent’s Bash tool) does not get it either — and the docs add, verbatim, “Don’t rely on this nested-session limit as a security boundary.” If managed settings cannot be read, the prompts stay on. The three possible startup lines exist precisely to debug all this.
What others say
The Register broke the story on October 28; IT之家’s translation the next day carried Anthropic’s response: the feature requires deliberate opt-in and administrator-imposed restrictions still apply — it is not a blanket removal of safeguards. That matches the suppression list. Because the name reads like a parody and the 2.1.311 CHANGELOG entry does not mention it, parts of the community initially suspected a hoax; per IT之家, an Anthropic engineer replied that it is not a joke.
Developer write-ups followed within hours. AshikNesin’s October 28 TIL dubs it “real YOLO mode” and shows the two-line recipe (export the variable, then claude --permission-mode bypassPermissions), citing the official docs anchor. The community-maintained ericbuess/claude-code-docs mirror already carries the entry in its env-vars table, marked 2.1.311+ and “ignored in a settings env block.” Both agree with the official docs. Context from the same family: CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT (since 2.1.281) only removed the time limit on the confirmation prompt; this one removes the prompt itself.
Our take
For unattended runs inside a CI container or a throwaway VM, this is a fair trade: headless sessions have nobody to click confirm, and --dangerously-skip-permissions alone still stalls on deletions that need a human. The verification line is also restrained design — one startup line tells you whether the variable took effect, so you are never guessing about whether the guard is down.
But treat it as a container-only switch, not a convenience. Three reasons. First, it works only in bypassPermissions mode, while Anthropic is steering everyone toward auto mode — which at least has a classifier in the loop; this variable has nothing. Second, there is precedent for why that matters: in the LiteLLM wheel compromise we covered on October 22, attackers used compromised maintainer tokens to ship malicious code through a normal update — running untrusted code with this variable set is handing over your home directory. Third, the docs’ own phrasing — an environment “whose contents you can afford to lose” — is more honest than any review. Your laptop or a machine attached to production is not that environment. The real risk of a switch like this was never the feature; it is setting it once and forgetting it. The consolation is the long list of conditions that switch it back off — a single deny rule does the job.