What the switch does, in full

Anthropic's permission-mode documentation carries a section headed "Turn off the critical-path removal prompt in bypassPermissions mode." The instruction is one line: start Claude Code with CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 in its environment, on version 2.1.311 or later. The variable is read only from that launch environment. Put it in a settings file and Claude Code ignores it.

The scope is narrower than the name suggests, in three ways. It works only inside bypassPermissions mode, not in plan mode. The switch applies to critical-path removal checks in the Bash and Monitor tools, including certain commands Claude Code cannot fully parse. It is not a general override for every deletion mechanism or every permission handler. And the flagged set includes a category worth pausing on: commands Claude Code cannot fully parse, and therefore cannot rule out as dangerous removals, also run with no prompt once the variable is set.

The prompt being removed was itself a compromise

The critical-path prompt was never a yes-or-no gate. At a terminal in bypassPermissions mode, it asked for approval against a two-minute countdown. Let the countdown expire and the removal was denied, so an unattended session kept working. After three unanswered prompts, Claude Code stopped asking and denied critical-path removals outright. Away from the terminal, in the VS Code chat panel, the desktop app or a scripted run, the same removals were denied unless a hook allowed them.

Read that design and the new variable is easier to place. One plausible reason to provide this opt-out is unattended automation. If a build or test workflow depends on a critical-path removal that Claude Code denies, the workflow may fail or continue without completing its intended cleanup. The documentation establishes the denial behavior; the operational impact depends on how the workflow handles that denial. Anthropic's setup guidance pairs the bypass flag with a container, a virtual machine or its sandbox runtime, run as a non-root user on Linux and macOS. In a properly isolated, disposable environment with no sensitive host mounts or persistent data exposed, disabling this prompt may be a reasonable trade-off for unattended execution. A container or VM is not automatically safe merely because it can be recreated.

What still stands between the agent and the disk

Plenty. Anthropic documents several situations in which the variable does not control the decision. Permission hooks, prompt tools and callbacks can take ownership of the request; applicable deny or ask rules still apply; and certain session types do not inherit the variable. VS Code chat-panel and desktop-app sessions are also excluded. These cases do not all restore the same prompt—some delegate the decision, while others deny the operation. Background and agent-team sessions, and a Claude Code process started inside another session, are among the session types that start without the variable. Deny rules block in every mode, bypassPermissions included. PowerShell's Remove-Item gets its own checks, and two of its outcomes, removals of system paths and bare wildcard removals, are denials in every mode, with no prompt to switch off.

What changed is that one prompt inside the safety system gained an opt-out, while the organizational controls around it, managed settings, deny rules and hooks, were left standing. A team that wants unattended speed without unattended exposure has the tools to draw its own line: deny rules for the paths that matter, written before anyone reaches for the variable.

A name doing the work of a policy

There was no launch post. Hollman announced the change on social media, opened by correcting the assumption the loudest flag creates: it does not approve everything, and obvious cases like rm -rf ~ were still blocked. The new variable disables that block, she wrote, "if you really want." Asked whether the name was a joke, she answered "Not a joke!" and said she hoped it was memorable. Anthropic's documentation describes the switch, while the v2.1.311 changelog entry reviewed for this article does not mention it.

The name functions as a warning, not an enforcement mechanism. Its deliberately alarming wording may discourage casual use, but the remaining technical protections come from permission rules, handlers, managed settings and the environment in which Claude Code runs. A setting called ENABLE_UNATTENDED_DELETIONS would be pasted into a thousand configuration files and forgotten by lunch. A setting that makes its user type EVEN_MORE_DANGEROUSLY in capital letters is built to stay uncomfortable to use, and harder to enable casually, though still easy to copy into a persistent configuration without fully considering the consequences. Claude Code also prints a startup line when the variable is active, saying dangerous rm commands can run without a prompt: a string teams can search for in their scripts and logs. Environment variables, though, are set once and inherited quietly. The discomfort happens once, at typing time. The exposure lasts until somebody remembers to remove it.

Sources

  1. [1] Anthropic, Claude Code Docs, "Choose a permission mode" (official documentation: the variable's section, the critical-path prompt behaviour, the no-effect cases, the mode and setup tables)Read source
  2. [2] Anthropic, Claude Code changelog (v2.1.311 dated October 27, 2026)Read source
  3. [3] The Register, "Anthropic now lets Claude users jump out of plane without parachute," October 27, 2026 (Hollman's announcement and quotes; the flag's June 9, 2025 origin; the changelog's silence)Read source
  4. [4] Tech-Insider, "Claude Code Skip Permissions: v2.1.311 Lets rm Run," October 28, 2026 (detailed secondary account, consistent with the documentation on the load-bearing points)Read source
  5. [5] CryptoBriefing, "Anthropic adds environment variable that lets Claude Code skip final file-deletion prompt," October 27, 2026 (corroboration of the variable, version and framing)Read source