# Claude Code 2.1.311 Lets Users Skip rm Checks [2026]

> Source: <https://shattered.io/claude-code-2-1-311-even-more-dangerously-skip-permissions-2026/>
> Published: 2026-10-28 01:14:27+00:00

Anthropic shipped Claude Code v2.1.311 with a new environment variable that switches off the last permission check the tool still applies in skip-permissions mode, [according to a report published October 27, 2026 and updated October 28](https://article.wn.com/view/2026/10/27/Anthropic_now_lets_Claude_users_jump_out_of_plane_without_pa/). The setting is called `CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS`. Set it to 1 and Claude Code can run commands such as `rm` without asking you first.

The headline on that report says Anthropic “now lets Claude users jump out of plane without parachute.” No aircraft is involved. The report uses the image as a metaphor, and the parachute stands for the approval prompt that sits between an AI agent and your file system. Remove the prompt and you are on your own.

This analysis walks through what the release changed, what the Claude Code developer who announced it actually wrote, what remains unconfirmed, and what the change means for teams that already run coding agents with guard rails. If you build those rails yourself, our walkthrough on [using Cursor hooks to guard an agent](https://shattered.io/cursor-hooks-tutorial-guard-agent-12-steps-2026/) covers the same problem from the editor side.

Don't miss new tech stories on Google

Add Shattered once in the Google app and our stories show up in your news suggestions.

[Add now](https://www.google.com/preferences/source?hl=en&q=https%3A%2F%2Fshattered.io%2F)

## What Anthropic Shipped in Claude Code v2.1.311

The confirmed facts are short. Anthropic’s Claude Code, its terminal-based coding agent, reached version v2.1.311. That release supports a new environment variable named `CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS`. Setting it to `1` disables the remaining permission safeguard that the report describes, which lets Claude Code run commands like `rm` with no approval step.

Boris Cherny, identified in the report as a Claude Code developer, announced the change in his own words. He wrote that “today’s release” would let users disable the block, and he named the variable and its value. That phrasing ties the feature to the v2.1.311 build, so anyone on an older version will not see the variable take effect.

Two limits come with it. Managed settings, the controls that an organization pushes to its developers, may still impose restrictions. And some operations may continue to require permission prompts even with the variable set. The report does not list which operations those are, so teams should test rather than assume.

What the report leaves out matters just as much. It names no price change, no subscription tier, no user count, and no model tied to the feature. This is a behavior switch inside a developer tool, not a product launch. Readers expecting a new Claude model or a pricing move in the same announcement will not find one in the confirmed record.

## The Parachute Headline: Metaphor, Not Aviation

Headlines that borrow from extreme sports travel fast, and this one did. It compresses a fairly technical release note into an image anyone can picture. That is also why it deserves a plain-language correction. Nobody is jumping out of anything, and Anthropic has not announced any flight, stunt, or hardware product.

### What the metaphor stands for

A parachute is a safety device you hope you never need. An approval prompt plays a similar role in an agentic coding tool. Each time Claude Code wants to run a shell command, the prompt asks a human to confirm. Developers often find that tiresome, and a flag to skip it has existed for a while. The new variable removes the part of the safety net that the flag left in place.

### What the report does not say

The report does not claim that the variable is dangerous by default, that Anthropic recommends it, or that any user has lost data because of it. It also does not describe incidents. Cherny’s wording frames the option as something users can choose “if you really want,” which puts the decision with the developer and not with the tool.

## How CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS Works

An environment variable is a named value that a program reads from the shell that launches it. Claude Code checks for this one at startup. When it finds `CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1`, it stops applying the leftover block that the older skip-permissions option kept. The result, per the report, is that commands such as `rm` run without an approval prompt.

```
# Older behavior: some commands, such as rm -rf ~, are still blocked
claude --dangerously-skip-permissions

# New in v2.1.311: the variable Cherny described
export CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
```

The snippet shows the two settings side by side, not a recommended recipe. The report does not say whether the variable works alone or must be paired with the older flag, so check the release notes for v2.1.311 before wiring it into a script. An environment variable also behaves differently from a command-line flag. It can live in a CI job definition, a container image, or a wrapper script, which makes it easier to apply across many sessions and easier to forget about.

Managed settings add a second layer. The report says they may still impose limitations. In practice that means an administrator who locks down Claude Code for a company could keep restrictions in force even when an individual developer exports the variable. How far that protection reaches is not spelled out, and the answer will matter to security teams.

## What Boris Cherny Said

The report quotes Cherny directly, and his two statements carry most of the confirmed detail. The first one corrects a common assumption about the older option:

“Fun fact: `--dangerously-skip-permissions` doesn’t actually approve EVERYTHING”

He went on to say that Claude Code still blocks “some obvious things like rm -rf ~.” That command wipes a user’s home directory, and the block explains why many developers treated the old flag as less scary than its name suggested. The second statement announces the escape hatch:

“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 things stand out in the wording. The tone is casual, with a “fun fact” opener, which suggests the team sees this as a power-user option and not a headline feature. And the phrase “if you really want” signals that Anthropic expects most people to leave the default alone. Neither point is a policy statement, so treat them as the developer’s framing and not as company guidance.

## Confirmed Facts Versus Open Questions

A viral headline invites embellishment, so the table below separates what the report supports from what it does not. Every row in the “Confirmed” column traces back to the October 27 report and its October 28 update.

| Item | Status | What the report supports | 
|---|---|---|
| Product and version | Confirmed | Claude Code v2.1.311 from Anthropic | 
| New variable | Confirmed | `CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1` | 
| Effect of the variable | Confirmed | Disables the remaining safeguard so commands like `rm` run without approval | 
| Older flag behavior | Confirmed | Still blocked some commands, including `rm -rf ~` | 
| Managed settings | Confirmed, scope vague | May still impose limitations | 
| Remaining prompts | Confirmed, scope vague | Some operations may still require permission | 
| Literal aircraft or parachute event | Not confirmed | Headline metaphor only | 
| Price or subscription change | Not confirmed | Nothing reported | 
| User numbers | Not confirmed | Nothing reported | 
| Model tied to the feature | Not confirmed | Nothing reported | 

The “scope vague” rows deserve attention. Both the managed-settings carve-out and the leftover prompts are described with the word “may,” so no reader can say from the report alone where the new variable stops working. That uncertainty is the single biggest practical gap in the story.

## How Skip Permissions Behaved Before v2.1.311

Understanding the change requires a clear picture of the layers it touches. Claude Code starts in a mode where it asks before risky actions. Developers who found that slow could use the `--dangerously-skip-permissions` option. The report says that option never approved everything. A short list of obviously destructive commands stayed blocked, and `rm -rf ~` is the example Cherny gave.

| Layer | Approval behavior | Basis in the report | 
|---|---|---|
| Normal operation | Claude Code asks for approval before running commands | Implied by the contrast with the new variable | 
| `--dangerously-skip-permissions` | Skips most prompts, still blocks some commands such as `rm -rf ~` | Cherny’s “fun fact” statement | 
| `CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1` | Disables the remaining safeguard, so `rm` runs without asking | Cherny’s announcement and the report | 
| Managed settings | May still impose limits regardless of the variable | Report states the possibility | 
| Residual prompts | Some operations may still ask for permission | Report states the possibility | 

Seen as a ladder, the design looks deliberate. Each rung removes one more barrier and each one carries a louder name. The old flag already had “dangerously” in it. The new variable adds “even more.” Anthropic is using the name itself as a warning label, and that choice says something about how the team thinks about user attention.

## Why the Variable Name Is So Long

Software teams have long used awkward names to slow down risky options. A name that nobody would type by accident works as a speed bump. `CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS` is 50 characters of friction, and each word in it makes a point. The reader has to see “dangerously” and “skip permissions” before the variable takes effect.

One plausible reading, and it is my analysis and not something the report states, is that Anthropic chose an environment variable over a new command-line flag for a reason. Flags show up in shell history and in pasted examples. Variables usually sit in configuration files where a reviewer can spot them. That makes the setting easier to audit in a repository, which suits teams that want to ban it with a simple search.

The naming strategy has limits. A scary name stops casual use, but it does not stop someone who copies a line from a forum post into a CI job. Once a snippet circulates, the length of the name no longer matters. That is a human-factors problem more than a technical one, and it applies to every tool that ships a “yes to everything” switch.

## Who Will Switch It On

The report does not profile users, so this section is analysis. Three groups look most likely to reach for the variable. The first runs Claude Code inside disposable environments, such as a container or a virtual machine that gets thrown away after each task. In that setting a deleted directory costs nothing, and approval prompts only slow the work.

The second group runs unattended jobs. A pipeline that asks a human to click “approve” cannot finish at three in the morning. Automation teams therefore have a real reason to remove every prompt. The third group is solo developers who simply dislike interruptions and trust their backups. Developers who already self-host agents, as in our setup guides for [Cline](https://shattered.io/cline-ai-setup-vscode-cli-12-steps-2026/) and [OpenHands](https://shattered.io/openhands-local-setup-agent-canvas-ollama-12-steps-2026/), know how quickly approval fatigue sets in.

Casual users on a laptop holding their only copy of important files are the people the name is meant to scare off. Whether it does depends on how widely the variable spreads in tutorials and shared dotfiles over the coming weeks.

## Security Risks of Removing the Last Safeguard

An agent without prompts is only as safe as its inputs. A coding agent reads source files, issue text, web pages, and package metadata, and any of those can carry instructions written by someone else. The model decides what to run based on what it reads. With the final block gone, a bad decision turns into a deleted directory in one step, with no human glance in between.

### Prompt injection and untrusted content

Prompt injection is the best-known route. A malicious comment in a repository, or a crafted web page the agent fetches, can steer the model toward destructive commands. Teams that want to know how their own setups hold up can build a small harness, and our [prompt injection test lab](https://shattered.io/prompt-injection-test-lab-llm-harness-2026/) shows one way to do it. Run those tests before you remove prompts, not after.

### Supply chain and dependency pulls

The second route runs through dependencies. Agents install packages, and a poisoned package can run code on install. Our coverage of the [LiteLLM supply chain attack](https://shattered.io/litellm-supply-chain-attack-pypi-ovhcloud-cli-2026/) is a reminder that developer machines are a target. Pair an unattended agent with an unchecked install step and the failure no longer needs a clever prompt. It only needs one bad release.

Accountability is the quieter issue. In September, The Register ran a piece headlined [“Treasury chief says AI bosses, not their bots, will carry the can for criminal acts”](https://www.theregister.com/security/2026/09/21/treasury-chief-says-ai-bosses-not-their-bots-will-carry-the-can-for-criminal-acts/5297965). That story is about a different subject, but the principle travels well. When a person flips a switch that removes oversight, the person owns what follows, and so does the organization that allowed the switch.

## Market Impact and Competitive Context

The market effect of a settings change is small and hard to measure. The report names no pricing move, no new subscription, and no adoption figure, so any claim about revenue or share would be invented. What the release does show is how fast coding agents are moving from suggesting code to acting on a machine. Our comparison of [Codex and Claude Code](https://shattered.io/codex-vs-claude-code-stack-overflow-65-5-vs-29-5-2026/) tracks that race from the usage side.

Competition in this category now includes assistants built into editors and agents that run in a terminal. Buyers weigh price, model quality, and workflow fit, and our breakdown of [GitHub Copilot versus Claude Code](https://shattered.io/github-copilot-vs-claude-code-2026/) covers those trade-offs. Approval design is a newer axis. A tool that lets teams dial autonomy up in clear steps may appeal to platform engineers, while a tool that never lets them dial it up may frustrate power users.

This article does not rank rivals on approval design, because the report covers only Claude Code and no confirmed data exists here on how other tools compare. The fair reading is that every serious agent vendor faces the same tension between speed and safety, and each answers it with a different mix of prompts, sandboxes, and policy controls. Our [AI and machine learning coverage](https://shattered.io/ai-machine-learning/) follows those choices as they ship.

## Historical Context: From Suggestions to Unattended Agents

Early AI coding tools offered completions. You typed, the tool suggested, and you pressed tab. The next generation could edit several files, and the one after that could run shell commands. Each step handed the tool more power and raised the question of who approves what. Permission prompts were the first answer, because they were simple and put a human in the loop.

Prompts have a cost, though. After the fiftieth confirmation in an hour, most people click without reading. Security researchers call this approval fatigue, and it turns a safeguard into a ritual. Vendors responded with allow lists, policy files, and skip options, and Claude Code already had one of the last kind before this release. The new variable continues that trend by letting the user opt out of the final check.

Real-world agent reliability is still uneven. Our report on how [six AI agents failed a £350 train refund test](https://shattered.io/ai-agents-350-pound-train-refund-test-vals-ai-2026/) showed that agents can stumble on ordinary tasks. A model that struggles with a refund form can also misjudge a shell command, which is the case for keeping some guard in place even as vendors give users more freedom.

## Guardrails for Teams That Use the Variable

Anyone planning to use the variable should treat it as one control in a stack, not a standalone decision. The table below lists practical safeguards. These are my recommendations as an analyst, not instructions from Anthropic, and none of them come from the report.

| Control | Where to apply it | What it limits | 
|---|---|---|
| Disposable container or VM | Runtime environment | Keeps a bad command away from your real files | 
| Non-privileged user account | Operating system | Stops commands from touching system paths | 
| Scoped credentials | Secrets management | Limits what a hijacked session can reach | 
| Restricted network access | Container or firewall | Reduces data exfiltration and risky downloads | 
| Version-controlled working tree | Git | Makes deleted or changed files recoverable | 
| Managed settings | Claude Code policy | May still impose limits, per the report | 
| Search for the variable in CI review | Code review | Flags unapproved use in shared configs | 

### Sandbox first, variable second

The order of operations matters. Build the sandbox, confirm that it can be wiped, and only then export the variable. A developer who sets `CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1` in a shell profile on a daily-driver laptop has reversed that order. Keep the setting out of dotfiles that sync between machines, and keep it out of examples you share with colleagues.

Teams also need a written plan for when an agent does something wrong. Decide in advance who gets alerted, how you restore from backup, and how you rotate credentials the agent could reach. Our [incident response plan guide](https://shattered.io/incident-response-plan-12-steps-90-min-2026/) offers a template you can adapt for agent mishaps.

## Five Predictions for Agent Permissions

These forecasts are my analysis. None of them appears in the report, and none carries a date or number, because the confirmed record offers none.

1. **Copy-paste snippets will spread first.** Tutorials and shared setup scripts will include the variable within weeks, and some will drop it into places it does not belong.
2. **Security teams will add detection rules.** Expect scanners and code reviewers to flag the variable name in repositories and CI definitions, the same way they flag disabled TLS checks.
3. **Managed settings will gain attention.** Because the report says they can still limit behavior, enterprises will ask Anthropic to document exactly what an administrator can enforce.
4. **Rival tools will publish their own autonomy ladders.** Vendors that sell coding agents will explain, in clearer terms, which commands each mode blocks.
5. **One public incident will shape the debate.** A widely shared story of a wiped directory, real or alleged, will push the conversation from convenience toward containment.

The common thread is that autonomy and containment will grow together. Users who want agents to work unattended will demand stronger isolation, and vendors that supply it will win trust. The variable itself is a small switch, but the practices around it will decide whether it stays a niche option or becomes a source of embarrassing stories.

## FAQ

**Did Anthropic let people jump out of a plane without a parachute?**

No. The headline uses the image as a metaphor. The real change is a software setting in Claude Code v2.1.311 that removes a permission safeguard. No aircraft or physical event appears in the report.

**What does CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS do?**

Set to 1, it disables the remaining permission safeguard described in the report. Claude Code can then run commands such as `rm` without asking for approval.

**How is it different from –dangerously-skip-permissions?**

Per Boris Cherny, the older option did not approve everything and still blocked some obvious commands, including `rm -rf ~`. The new variable lets users disable that remaining block.

**Which Claude Code version includes the variable?**

Version v2.1.311. Cherny said “today’s release” supports it, and the report was published October 27, 2026 and updated October 28.

**Does the variable remove every prompt?**

Not necessarily. The report says managed settings may still impose limitations and that some operations may continue to require permission prompts. It does not list them.

**Did Anthropic change pricing or announce a new model with this release?**

The report mentions neither. No price, subscription change, user count, or model name is confirmed in connection with the feature.

**Should I turn it on?**

Only inside an environment you can afford to wipe, such as a disposable container. Cherny framed it as an option for people who “really want” it, and the name signals the same caution. Keep it away from machines that hold your only copy of important data.
