Anthropic has shipped a setting that lets Claude Code, its coding agent, delete files without asking first. According to The Register, Claude Code v2.1.311 adds an environment variable named CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS. Set it to 1 and the agent can run rm with no approval prompt. The Register framed the change as letting Claude users jump out of a plane without a parachute. That image is a metaphor for the risk. No aircraft, jump or injury is part of the story.
The change matters because it removes the last stated brake on Claude Code skip permissions mode. Until this release, even the loudest bypass setting still stopped to ask before certain deletions. Who pays when an autonomous tool does damage is already a live debate. The Register ran a piece in September on a Treasury chief arguing that AI bosses, not their bots, will carry the can for criminal acts. This release hands users more rope, and the accountability question lands on them.
Our earlier look at why Anthropic held back Mythos after finding 10,000+ flaws showed a company willing to slow down. This release points the other way, and it deserves a close read of what changed, what did not, and who should flip the switch.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Anthropic changed in Claude Code v2.1.311
The confirmed change is narrow and easy to state. Claude Code v2.1.311 supports an environment variable that allows the agent to run rm without requesting approval. Daisy Hollman, a member of technical staff at Anthropic, announced it in a social-media post, per The Register. The variable name is long on purpose. It reads as a warning label, and it stacks a second “dangerously” on top of a flag that already carried one.
Nothing in the announcement suggests the default behavior changed. Users who do nothing keep the prompts they have today. The new switch is opt-in, which fits the pattern Anthropic has used for permission features since Claude Code launched. Risky capabilities ship behind loud names and explicit flags, so nobody enables them by accident.
What the sources do not give us is just as important. The announcement, as reported, carries no user counts, no pricing change, and no data on how many people run Claude Code in bypass mode. Any figure you see attached to this story elsewhere needs its own source. We have none, so this article uses none.
The environment variable, in plain terms
An environment variable is a named setting the shell hands to a program when it starts. Claude Code reads this one at launch. The value that activates it is 1. Any other state leaves the extra protection in place. The mechanics are simple, and that simplicity is part of the story. One line in a shell profile, a CI config or a container definition is enough to change how much trust the agent receives.
# The activation value confirmed in the announcement
export CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1Hollman’s wording implies this variable works on top of the existing bypass flag rather than replacing it. The flag lowers the prompts. The variable then removes the remaining restraint on deletions. Because the sources describe the pairing only through that quote, treat the exact interaction as something to test in a throwaway directory before trusting it anywhere that matters.
How the skip-permissions flag worked before this release
To see why this is a step up in risk, start with what the old flag did. --dangerously-skip-permissions has long been the shortcut for developers tired of clicking “approve” on every file edit and shell command. It turns Claude Code into something closer to a colleague with the keys, and it has been the default choice for long unattended runs. It was never a complete bypass, though.
bypassPermissions arrived on June 9, 2025
The underlying bypassPermissions mode first appeared in Claude Code v1.0.18 on June 9, 2025, per The Register’s coverage. That puts the feature at more than 16 months old as of today, October 28, 2026. For most of that time, the working assumption among users was that the flag skipped prompts and that Anthropic kept a short list of hard stops in the background.
The hard stops the flag still honored
Some commands, including rm and rmdir, still required a permission prompt even with the flag on. The new environment variable removes that stated restraint, according to the announcement. Hollman put the old behavior bluntly, and her words are worth quoting in full because they define the baseline.
Daisy Hollman’s announcement, in her words
Hollman’s post, as The Register reported it, opens with a correction of a common assumption. She wrote: “Fun fact: –dangerously-skip-permissions doesn’t actually approve EVERYTHING – we still block some obvious things like rm -rf ~.”
She then described the change itself: “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.”
Two details stand out. First, the example Hollman picked, rm -rf ~, is the classic home-directory wipe. Anthropic’s own engineer used it as the poster child for what the old flag blocked. Second, the phrase “if you really want” signals that the company sees demand and is not endorsing the use. Anthropic is shipping the capability while distancing itself from the choice to use it.
Why the jump-without-a-parachute line fits, and where it stops
The Register’s headline image works because skydiving has a parachute and a reserve, and software has prompts and backups. Remove the first and you are betting on the second. That is the entire argument, and it holds up as a metaphor.
It does not hold up as a literal claim. The reporting confirms no aircraft, no parachute, no injury and no real-world jump. Readers who landed here from a search for the headline should know that the news is a developer-tool release. Nobody is being asked to leave a plane.
The metaphor also hides a fair counterpoint. Skydivers get one chance, while a developer with version control and a clean sandbox can undo a bad deletion in seconds. Whether this change is reckless or routine depends almost entirely on the environment around it. A disposable container with a fresh clone makes the new variable a convenience. A laptop with an unpushed project and a home directory full of keys makes it a gamble.
Permission layers compared: what each setting does
The table below lays out the three states a Claude Code user can now choose between, using only behavior confirmed in the announcement and the release history. It leaves out the other permission modes in the product, because the sources here do not describe their behavior in enough detail to compare fairly.
| Setting | Prompts for ordinary actions | Prompt for rm / rmdir | Obvious wipes like rm -rf ~ | Source status |
|---|---|---|---|---|
| Default behavior | Yes, per the normal permission flow | Yes | Blocked | Baseline described by The Register |
--dangerously-skip-permissions (bypassPermissions, since v1.0.18, June 9, 2025) | Skipped | Still prompts | Still blocked | Confirmed by Hollman’s post |
Flag plus CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 (v2.1.311) | Skipped | No prompt | Block can be disabled | Confirmed by Hollman’s post |
| Per-command allow rules | Depends on user config | Depends on user config | Not described | Not covered in the announcement |
The pattern is a ladder. Each rung removes one more human checkpoint, and the new variable removes the last one the company had publicly described. Teams that standardized on the flag because it felt safe enough should reread their runbooks.
Why developers keep asking for fewer prompts
Anthropic did not invent this demand. Anyone who has run an agent on a multi-hour refactor knows the pain of a prompt appearing at minute three and again at minute forty, with the human nowhere near the keyboard. Approval fatigue pushes users toward blanket bypasses, and a bypass that still stops on rm breaks the unattended workflow anyway. Build scripts, test cleanups and generated-file resets all lean on deletions.
That is the likely reason the variable exists. Cleaning a build directory is routine, and a pipeline that halts for a human to approve it defeats the point of automation. We saw similar friction when testing planning tools, as in our walkthrough of a Cursor plan-mode checker for edit drift, where the hardest problem was keeping an agent inside the scope the developer approved.
The wider shift in developer work adds pressure. Coverage such as ClaudeWorld’s report on an Anthropic hiring manager who stopped giving coding interviews points to how central agent-assisted work has become for developers, and Anthropic said Barclays expected adoption to reach 50% of its developer population by the end of 2026. When the agent does the typing, the human becomes the bottleneck, and prompts are the visible symptom.
What can go wrong when an agent holds rm
The risk is not that the model turns hostile. It is that the model misreads a request and acts at machine speed. Ask an agent to “clean up the old config files” in a broad workspace, and it may pick a different set than you did. With a prompt, you see the list. Without one, you see the aftermath.
Reported accounts of AI agents causing data loss typically involve destructive shell commands, wiped project directories, or deletions after a misunderstood task scope. No verified incident count or complete registry exists, so any claim about how often this happens is guesswork. The failure pattern, however, is well understood, and it is the one Hollman’s example, rm -rf ~, points to.
Agents also fail in stranger ways than a bad delete. In our report on the Grok agent that sent 187 messages chasing a £350 refund, the problem was persistence, not malice. An agent that keeps pushing toward a goal will use every permission it holds. Give it deletion rights without a checkpoint and persistence becomes a liability.
Competitive context: how rival coding agents handle approvals
Every serious coding agent faces the same tradeoff between speed and supervision, and each vendor draws the line in a different place. We have not tested rival tools against this specific change, and the sources for this story say nothing about their approval models. What we can say is that the market has split into tools that prompt by default and tools that ask users to define allow-lists up front.
Cost shapes the choice too. A heavier autonomous workflow burns more tokens, and teams weighing a switch should compare plans first. Our breakdown of Claude Code pricing against Codex and Gemini CLI covers the $20 to $500 range, which matters for anyone planning long unattended runs. Anthropic’s own pricing pages list Claude Pro at $20 monthly or $17 monthly annually, including Claude Code, while Max 5x users receive $100 in monthly credits, Max 20x users $200, and Team subscribers up to $500 pooled across users. Anthropic’s decision to expose a no-guardrails switch also lands in a field where rivals compete on trust as much as raw capability.
For the model layer underneath these tools, see our comparison of GPT-6.1 Sol, Sonnet 5.5 and Gemini 4 Argon. Newer models tend to follow instructions more precisely, which lowers the odds of a misread deletion, and Anthropic announced Claude Sonnet 5.5 on September 28, 2026, describing it as more than 30% faster than Sonnet 5 and up to 30% cheaper for most work. Even so, no model release removes the need for a safety net. Our wider AI and machine learning coverage tracks how each vendor handles that balance.
Historical context: 16 months from flag to final switch
The timeline tells a clear story. In June 2025, Anthropic introduced bypassPermissions with v1.0.18, giving power users a way past constant prompting. In the months since, the product moved from v1 to v2.1.311, a version number that shows how many point releases the team has shipped. Along the way, the company kept a small set of hard blocks as a floor.
This release moves the floor. The mechanism for doing so is telling: not a new product tier, not a policy page, just an environment variable with a name designed to make the user wince. That is the same design instinct behind the original flag. Anthropic prefers to make dangerous options available and embarrassing to type over making them unavailable.
| Item | Detail | Status |
|---|---|---|
| bypassPermissions first appears | Claude Code v1.0.18, June 9, 2025 | Confirmed |
| New variable ships | Claude Code v2.1.311 | Confirmed |
| Activation value | CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 | Confirmed |
| Announced by | Daisy Hollman, member of technical staff, Anthropic | Confirmed |
| Literal plane jump | Headline image only | Unconfirmed, used as metaphor |
| Price, user count, incident count | None reported | Unconfirmed |
How to run with no prompts without losing your work
If you decide to use the variable, treat the environment as the safety system. Prompts were a human-speed safeguard, so replace them with machine-speed ones. The steps below are our recommendations, not Anthropic guidance, and they apply to any agent running without approvals.
- Isolate the workspace. Run the agent inside a container or virtual machine that holds only the project it needs.
- Use a disposable clone. Work in a fresh git worktree or clone so a bad deletion costs you a re-checkout.
- Strip credentials. Give the agent the least privilege that gets the job done, and keep cloud keys and SSH keys out of the sandbox.
- Back up first. Snapshot anything you cannot regenerate before a long unattended run.
- Keep the variable out of shell profiles. Set it per session so it never leaks into a terminal where you do ordinary work.
- Review the diff afterward. Read the git status and deletion list before merging anything.
# Disposable workspace, then run the agent only inside it
git worktree add ../agent-scratch -b agent/scratch
cd ../agent-scratch
# Set the variable for this session only, never in ~/.bashrc
CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 claude --dangerously-skip-permissionsTest the combination in a directory full of dummy files before trusting it anywhere real. The sources describe the variable and the flag, but they do not publish a full behavior matrix. Your own dry run tells you more than any summary can.
What this means for teams, policy and accountability
For engineering managers, the practical task is policy. A flag buried in a README is not governance. Decide who may enable the variable, where it may run, and what evidence you keep. Many teams will want to forbid it on developer laptops and permit it only inside ephemeral build containers.
Security teams should add the variable name to their configuration scanning. A string as distinctive as CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS is easy to search for in dotfiles, CI definitions and Dockerfiles. Finding it is the first step. Asking why it is there is the second.
The accountability angle from earlier returns here. If an agent deletes a production directory under a setting named “even more dangerously,” a postmortem will not blame the model. It will ask who set the variable and who allowed it. Our look at how AI is creating more work at Uber makes a related point: automation shifts responsibility instead of removing it.
Five predictions for agent permissions
These are our own forecasts, not reported facts, and they rest on the pattern above.
- Rivals will add comparable switches. Once one major vendor exposes a no-prompt deletion setting, competitors under pressure from power users tend to follow with their own.
- Sandbox-first tooling will grow. Expect more products that bundle containers or throwaway workspaces with agents, because they turn the risky setting into a safe default.
- Enterprise admins will demand lockouts. Large customers will ask for central controls that disable the variable across a fleet, and vendors will answer.
- The first public postmortem will name the variable. Someone will lose work under this exact setting and write it up. The name makes the story easy to tell.
- Anthropic will keep layering, not removing. The company will likely add safer middle options, such as scoped deletion rights, so fewer users need the extreme one.
The takeaway for Claude Code users
The takeaway: Claude Code v2.1.311 gives you an explicit, opt-in way to remove the last stated approval barrier on file deletion, and Anthropic made it hard to enable by accident. Daisy Hollman’s own quotes show the company knows the risk. The responsibility for using it sensibly now sits with you.
Keep the variable out of daily shells, keep the agent in a sandbox, and keep backups current. If you cannot say where your work lives when the agent runs, you are not ready to flip it. And if you simply want fewer prompts, the plain flag from June 2025 still does most of the job with its remaining stops intact.
Frequently asked questions
What does CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS do?
Set to 1 in Claude Code v2.1.311, it lets the agent run rm without requesting approval. It removes a restraint that the existing skip-permissions flag still applied, according to Daisy Hollman’s announcement as reported by The Register.
Did Claude users actually jump out of a plane?
No. The plane-and-parachute line is a metaphor for running an agent with its final safety check removed. No aircraft, jump or injury is part of the reported story.
Was –dangerously-skip-permissions already unrestricted?
Not fully. Hollman said the flag does not approve everything and still blocks some obvious commands like rm -rf ~. Commands including rm and rmdir previously still required a permission prompt.
When did bypassPermissions mode first appear?
It first appeared in Claude Code v1.0.18 on June 9, 2025, more than 16 months before this change.
Is the new variable on by default?
Nothing in the announcement says so. It activates only when a user sets it to 1, so people who change nothing keep their current behavior.
How can I use it more safely?
Run the agent in a container or disposable clone, strip credentials, back up irreplaceable files, set the variable per session, and review the diff afterward. These are our recommendations, not official Anthropic guidance.
How many people use it, and what does it cost?
Neither figure has been reported. The announcement gives no user count, no price and no incident tally, so we do not state any.
