Claude Code's New Switch Removes the Last Deletion Prompt — Use It Only in a Throwaway Sandbox

On October 27, Anthropic added a switch to Claude Code whose name reads like a warning label: set the environment variable CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS to 1, and the agent will no longer stop to ask before running deletion commands. The news first came from a social media post by Daisy Hollman, a member of Anthropic's technical staff, and was reported by The Register the same day. This is not a change to default behavior, and it is not an ordinary feature release. It is closer to a public statement: Anthropic is willing to hand users the last remaining brake, on the condition that they genuinely understand what they are doing.

First, the facts, stated precisely. The switch appears in Claude Code v2.1.311 and applies to deletion commands such as rm and rmdir. In her post, Hollman first corrected a common misunderstanding: "Fun fact: --dangerously-skip-permissions doesn't actually approve EVERYTHING – we still block some obvious things like rm -rf ~." Then she described the change: "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." Because the variable name is so extreme, some of the first people to see it assumed it was a joke. Hollman replied: "Not a joke! I hope this helps, and I hope the variable name is memorable."

First, the permission ladder: which rung is this switch on?

To understand why this switch deserves its own article, you need Claude Code's permission ladder. As The Register lays it out, Claude Code has several permission modes: default, acceptEdits, plan, auto, dontAsk, and bypassPermissions. Auto mode nominally allows almost everything but still runs safety checks in the background, and it became the default in August. bypassPermissions also nominally allows everything, but without those checks; it is enabled by the command-line flag --dangerously-skip-permissions, which first appeared in Claude Code v1.0.18 on June 9, 2025.

The key point is that even at the bypassPermissions level, there were exceptions. Deletion commands such as rm and rmdir were never auto-approved; they still triggered a confirmation prompt. That prompt was the "obvious things" defense Hollman referred to: it did not guard ordinary file edits, but actions that are hard to undo once executed. The new environment variable is scoped exactly to that last prompt. In other words, it does not jump from "ask about everything" to "ask about nothing." It moves from "only deletions still ask" to "not even deletions ask." Users who do nothing will notice no change; only those who actively set the variable enter fully unsupervised deletion mode.

Why would anyone want this switch?

The demand is real, and it is easy to understand. An agent running unattended most dreads getting stuck on a confirmation dialog in the middle of the night: a batch cleanup, a build-artifact rotation, a test-environment reset — if any step involves deletion, the whole run stops and waits for a human to click approve. For a sandbox designed to be thrown away, that prompt is pure friction. Anthropic's choice is to hand the decision to the user rather than welding the prompt shut for everyone. That logic is consistent with the reason --dangerously-skip-permissions exists at all: the tool is conservative by default, but leaves an exit for people who clearly know what they are doing.

But "someone needs it" and "you can turn it on casually" are two different things. The danger of a deletion command is not the command itself, but the way it combines with an agent's uncertainty. A model can misunderstand the scope of a task, build a path incorrectly, or run a command in the wrong directory. A human typing rm -rf hesitates first; an agent does not hesitate, it executes. The confirmation prompt existed precisely to keep a human intervention opportunity between a model's mistake and a disaster. Turning it off removes that opportunity as well. The Register's report also notes that there are already numerous accounts of agents issuing destructive commands and causing data loss. This is not a theoretical risk.

Who should absolutely not touch it

Here is the blunt version: if you run Claude Code on your main development machine, do not enable this switch. If your working directory contains anything you cannot afford to lose, do not enable it. If you have not yet figured out which directories in your project must never be deleted, do not enable it. The two "dangerously" words in the variable name are not rhetoric; they are literal. The only sensible use case is an environment that can be destroyed and rebuilt at any time — a disposable container or virtual machine — where losing the data costs nothing, and where your real data is not even reachable.

One scenario deserves extra caution: writing this switch into long-lived shell configuration, CI scripts, or team-shared environment templates. A one-off sandbox experiment and a permanent default are completely different things. The first is a risk you consciously take for one task; the second passes that risk on to every future person and every automatically triggered run, most of whom will have no idea it is there. Environment variables get copied, inherited, and forgotten, and by the time something goes wrong, nobody remembers when it was added. If you genuinely need it for a workflow, confine it to that single task's scope and remove it afterward. Do not let it become part of the infrastructure.

If you must use it: five hard rules

First, use it only in a throwaway environment. Containers, virtual machines, and temporary sandboxes are all fine, provided that a mistake costs you only that task's output — not your code repository, your photos, your keys, or your customers' data. Second, snapshot before you run. Confirm that your backups and snapshots are available, recent, and actually restorable — not merely something you assume exists. Third, tighten the working directory. Let the agent operate only inside an explicitly bounded directory, and do not hand it free rein over your entire home directory. Fourth, respect the upper layers of control. The Register notes that managed settings and other restrictions may still apply, which means enterprise administrators still have a final means of constraint; do not assume one environment variable overrides all governance, and do not probe that boundary on a managed device. Fifth, review the deletion log after the run. Unsupervised does not mean unreviewed, and checking what was actually deleted is the cheapest way to spot a gap between what the model understood and what you meant.

The second rule is the one most often overlooked. Many people understand "sandbox" as "isolated, therefore safe," but isolation protects against damage to the outside, not against data loss inside the sandbox. If the agent deletes a real directory you mounted into the sandbox, isolation will not help. Mount relationships, volume mappings, and working-directory boundaries are what actually determine the blast radius. Before enabling this switch, draw those boundaries clearly, and only then talk about efficiency.

A transparency gap worth noting

The Register also records a telling detail: this change does not appear in the v2.1.311 changelog. That is part of why some readers initially suspected a joke. A company that markets itself on safety adding a switch that removes a safety confirmation from its flagship coding tool, without documenting it in the changelog, is worth questioning. There are many possible explanations — a fast release cadence, an oversight in the log, or a deliberate decision to keep a power-user option low-profile. Whatever the reason, the result is the same: users cannot discover this switch from the changelog alone; they need a social media post and press coverage. For a change involving deletion permissions, that is not good disclosure.

That gap carries a practical lesson for every user: do not treat the changelog as your only source of information, and do not treat a social media post as formal documentation. If you plan to rely on this switch in a production workflow, first test its behavior in your own environment, on disposable data, and confirm that it works as described for your version and your way of running the tool. Anthropic may add formal documentation later; until then, anything beyond Hollman's own words should be treated as unverified.

What this really says

Zoom out, and this switch is a snapshot of the October coding-agent race: every vendor is competing over who can make agents more autonomous and less interruptive. Fewer confirmations mean smoother automation — and fewer chances to catch mistakes. Anthropic's approach makes the choice conspicuously visible: the variable name itself is a warning, so nobody who copies that configuration line can pretend they did not see the risk. That is an honest design, at least in the sense that it hides nothing. But honesty is not the same as safety, and even the scariest name cannot stop copy-and-paste.

For ordinary developers, the right response is neither to rush to enable it nor to panic. Default behavior has not changed; your Claude Code works today exactly as it did yesterday. This switch only affects people who go looking for it and set it deliberately. And for those who genuinely need unsupervised deletion flows, it is a tool worth evaluating seriously — provided the evaluation happens in a sandbox, not on a machine holding real data. The more autonomous agents become, the more important human-defined boundaries are. This switch does not change that rule; it pushes it to a more extreme position. Once the last confirmation is gone, the only safety measures left are the boundaries you drew in advance.

From one flag to one variable: Anthropic's consistent pattern of concession

Laid out as a timeline, this change did not come out of nowhere. In June 2025, the --dangerously-skip-permissions flag first appeared, and the bypassPermissions mode it enabled already told users: if confirmation dialogs annoy you, you can switch them all off at once. In August 2026, auto mode became the default — nominally allowing almost everything, but with safety checks still running behind the scenes. On October 27, the new variable removed the last remaining exception inside bypassPermissions mode. Across all three steps, the direction never changed: defaults get smoother, extreme options get more thorough, and every concession comes with an increasingly blunt name.

That naming strategy is itself worth examining. --dangerously-skip-permissions was already blunt; the new variable adds an EVEN_MORE_DANGEROUSLY on top, as if shouting the warning twice. Anthropic clearly knows this switch will be screenshotted, forwarded, and quoted out of context, so it chose to put the warning inside the name, making it impossible for anyone copying the configuration to claim they missed the risk. It is a clever communication strategy, but it has an obvious ceiling: a name can only warn the first person who sees it, not the second or third person who inherits it. Once a configuration line enters a script, a document, a tutorial, or a team template, the warning in its name quickly depreciates into boilerplate nobody reads closely anymore. Real safety never depended on a scary name; it depends on boundaries and defaults, and this switch is precisely a case of handing the default line of defense away voluntarily.

There is another angle that is easy to miss: the existence of this switch signals that Anthropic now treats "fully unsupervised" as a mode of operation worth officially supporting, rather than a hack. In the past, running unsupervised often meant working around confirmations yourself or accepting that a run would stall overnight; now there is an explicit, named option. That is good news for teams running batch jobs in sandboxes, because they no longer need semi-official workarounds to keep automation going. But for ordinary users, the signal can be misread: the fact that an official option exists does not mean the vendor recommends it for you. The key qualifier in Hollman's own words is "if you really want" — if you really want it. That qualifier is the correct posture for the whole affair: an exit prepared for a small number of well-defined scenarios, not a new default for everyone.

How accidental deletion usually happens: three common failure modes

The first is the wrong directory. The "current project" the agent understands and the "current project" you have in mind are not necessarily the same directory; one path-construction error or one symlink-resolution difference can land a cleanup command in the wrong place. A human typing a deletion command glances at the path first; an agent has no such habit, and its confidence in a path comes from context, which can be wrong. The second is scope creep. A command meant to delete a few temporary files can quietly expand its reach through wildcards, recursive flags, or variable expansion. Command-line history is full of such "almost right" stories, and agents doing batch operations are especially prone to treating "close enough" as "exactly right." The third is misleading content. Files, logs, or web pages the agent reads may contain problematic instructions or misleading descriptions, and once the model follows them, a deletion command can appear in a task where it never belonged. These three modes share one trait: none of them requires the model to "intend" harm. A single ordinary misunderstanding is enough to turn a deletion command into a disaster.

That is why the phrase "the last confirmation" matters so much. It is not an ordinary dialog box; it is the only check on the entire permission ladder that is specifically aimed at irreversible actions. A bad file edit can be fixed, broken code can be rolled back, but deletion rarely has a cheap undo. Backups and version control help, of course, but both come with prerequisites: backups must be recent, complete, and actually restorable; version control only covers tracked files, not the untracked local data, downloads, and personal files that never entered a repository. Turning off deletion confirmation gives up the buffer between "blocked beforehand" and "cheaply recoverable afterward," leaving only the quality of the backups you prepared in advance.

For vibe coding enthusiasts, this point deserves to be made separately. Many people run agents on their main machine while prototyping, with code, keys, personal files, and half-sorted materials mixed together in the working directory, and with permissions opened wide because "getting it running comes first." That habit combined with this new switch is the most dangerous combination of all: you are not experimenting in a sandbox, you are experimenting in your real life. The correct order in the prototyping phase is the reverse — tighten permissions first, fence off important directories from the workspace, decide in advance what would hurt to lose, and only then talk about speed. A switch will not make your prototype run faster; it will only make one mistake more expensive.

What team leads should do now

If you lead a team, the question is not whether you personally use this switch, but whether someone on your team might start using it without others knowing. Step one is to state a position in writing: in your team's agent-usage guidelines, say clearly that this variable is permitted only in disposable sandbox tasks, and never in shared configuration, CI templates, or onboarding documents. Step two is to check the current state: search shared scripts and environment templates for configurations of this kind, and while you are at it, check whether anyone has made --dangerously-skip-permissions a default launch argument. Step three is to use management controls as a backstop. The Register notes that managed settings and other restrictions may still apply; administrators should confirm that those controls genuinely cover deletion-type operations in their organization, rather than assuming they do by default.

Step four is to turn this into a concrete exercise rather than a mass email. In a disposable environment, let team members actually watch what an agent in fully permissive mode deletes, how fast it deletes, and what the logs retain. Many people only grasp what "unsupervised" really means when they see deletion happening at machine speed. Step five is to agree on a review routine: any batch job run in permissive mode gets a post-run look at its deletion record, confirming that the deleted scope matches the task's goal. The review does not need to be heavy, but it must exist, because it is your last chance to catch a gap in the model's understanding.

Finally, a more fundamental judgment. Vendors will keep offering smoother, more autonomous options — competition guarantees it, and it will not stop. Your job is not to reject every new option, nor to accept them all, but to draw a clear boundary for each concession. For this switch, the boundary is easy to draw: only in disposable environments, only within a single task's scope, and only with verified backups in place. Drawn clearly, it is a useful efficiency tool; left undrawn, it is an accident waiting to happen. The thing genuinely worth remembering from October 27 is not the very long variable name, but the reminder behind it: when the agent stops asking you, you need to be more certain than ever about what it must never be allowed to touch.