Claude Code 2.1.288 Fixes Dangerous rm Bypass, but npm Stable Lags

The fix is out, but there's a catch. According to MIXED Reality News, the npm stable tag for the package still pointed at 2.1.285 when it last checked. Anyone who installs or pins stable is running a build without this repair.

What 2.1.288 actually fixed​

Anthropic's GitHub release notes for v2.1.288 say the release fixes a dangerous rm, such as one on / or the home directory, inside a bash -c or sh -c script that ran without a prompt. That happened in two situations: bypassPermissions mode, or under a shell allow rule. The entry links to public issue #96300.

To see why this matters, you need to know about "critical paths." Anthropic's permission documentation lists a few things that Claude Code never approves automatically, in any mode. One of them is rm and rmdir removals targeting a critical path, which no allow rule or PreToolUse hook "allow" approves. A third-party walkthrough of those docs describes critical paths as the filesystem root, or a top-level directory such as /usr or /etc, plus your home directory, or a Windows drive root like C:\, and your working directory and its parents. That Windows drive-root detail is worth noting here, because the bug was reported from a Windows machine.

MIXED quotes Anthropic's permission-modes page as calling this protection a circuit breaker that "guards against model error." It isn't there to stop attackers. It's there to stop a capable but fallible model from making a catastrophic mistake while nobody is watching.

Section summary: 2.1.288 closes a specific gap. A destructive rm hidden inside a bash -c or sh -c string could skip the critical-path prompt in bypass mode or under a shell allow rule.

How the guard got bypassed​

According to MIXED, the bug was filed on Anthropic's public tracker on September 23 against Claude Code 2.1.280, running on Windows 10 in Git Bash. In bypassPermissions mode, the guard did its job in most cases:

• A plain rm -rf on the session's own directory was stopped with "Dangerous rm operation detected"
• The same command in a subshell was stopped
• In a brace group, also stopped
• Inside command substitution, also stopped

Passing the command to a shell changed the result. Both sh -c "rm -rf …" and bash -c 'rm -rf …' aimed at the same directory ran without a prompt and deleted the files. The report puts the cause simply: the check sees sh or bash as the program being run, and "the rm is inside a string argument, so the check never sees it."

In other words, the guard checked the label on the box and never looked inside. Shell users will know the problem: bash -c takes a whole program as one string argument, so any check that only reads the top-level command never sees what that string does.

Some limits on the reproduction, as MIXED reports them:

• The tests targeted only the working directory. Home and system directories were not tested. The reporter expected them to behave the same way because they "go through the same function."
• Anthropic tagged the issue area:security and closed it on October 2 at 20:19 UTC. That was nine days after it was opened and, by MIXED's timing, less than two hours after the fix reached npm.
• The report lists three earlier fixes in the same area, in 2.1.208, 2.1.261 and 2.1.273. That makes 2.1.288 at least the fourth change to this one check, and each change closed a bypass the previous one missed.

Section summary: A Windows/Git Bash reproduction showed that the guard caught rm in several shell constructs but not inside sh -c or bash -c strings.

Who was actually exposed?​

Both conditions in Anthropic's release note are ones you have to turn on yourself, which limits who was affected.

Condition one: bypassPermissions mode. Anthropic's CLI reference documents --dangerously-skip-permissions as skipping permission prompts and as equivalent to --permission-mode bypassPermissions. A separate walkthrough of the docs says you cannot enter this mode from a session you started without it. It has to be decided at launch. MIXED also reports that Claude Code shows a warning dialog the first time an interactive session uses the mode, and quotes Anthropic's advice to run it only in isolated containers, VMs or dev containers without internet access.

Condition two: a shell allow rule. This is a rule you wrote. Anthropic's documentation promises that a permissions.allow rule or a PreToolUse hook that returns "allow" can never approve an rm or rmdir on a critical path. That's exactly the promise the wrapper broke. If you'd allowlisted something broad like bash because approving every script was tedious, that rule plus a bash -c string got you past the guard.

So typical interactive use in default mode wasn't the main risk. The people most exposed are the ones who use bypass mode most, often for long unattended runs, and those are exactly the setups where a mistaken rm -rf does the most damage before anyone notices.

Section summary: Default-mode users were mostly safe. Bypass-mode users and anyone with broad shell allow rules were relying on a guarantee that had a hole in it.

The stable channel is still behind​

According to MIXED, npm's dist-tags for @anthropic-ai/claude-code read as follows at 21:05 UTC on October 2:

That snapshot is MIXED's own check, and dist-tags can change at any time. It may already be out of date by the time you read this. The general point still holds: a newer release doesn't mean the stable tag has moved, and installations that follow stable get the fix only when it does.

Practical steps for Windows and cross-platform users​

1. Check what you're running. Anthropic's CLI reference describes claude doctor as printing read-only installation and settings diagnostics, including install health, without starting a session. Use it to see your installation type before you update.
2. Check the channel yourself. For npm installs, npm view @anthropic-ai/claude-code dist-tags shows where latest, next and stable currently point.
3. Update deliberately. If you're older than 2.1.288 and use bypass mode or broad shell allow rules, move to 2.1.288 or later through your normal install method, then check the version again. One more reason to check: 2.1.288 also fixes the npm auto-updater reporting success when the platform-native binary failed to download and only a placeholder claude stub was installed.
4. Tighten your allow rules. Blanket rules for bash, sh or interpreters effectively hand the agent a blank check. Scope rules to specific commands.
5. Isolate bypass mode. Run it in a container or VM, as Anthropic itself advises.

Other permission fixes in the same release​

MIXED counts 89 changes in 2.1.288. Anthropic's release notes include several more fixes to permission checks:

• A Bash permission check now prompts before a BASHPID assignment whose value the shell would evaluate as arithmetic. Previously it was allowed silently.
• Sandboxed heredocs with an unquoted delimiter, such as python3 <<EOF, no longer ask for approval on every run under sandbox auto-allow when the body is plain text and simple $VAR references.
• A dangerous rm on / or home no longer loses its always-ask safeguard when the same command also redirects output to a ~ or wildcard path. That's another wrapper-style gap closed in the same build.
• For Windows users: the PowerShell tool's permission check no longer skips deny and ask rules, and no longer caches that failure, when its command parser fails to start, for example when the machine is out of memory.

There are also Windows quality-of-life fixes. The keyboard works again after Claude Code restarts itself. A new startup warning appears when denying the Bash tool also disables PowerShell. And interactive claude now explains itself and exits, instead of hanging on "Raw mode is not supported," when input is piped.

MIXED also notes that 2.1.288 follows 2.1.287, which added user-made mods. Anthropic says those mods are not sandboxed and can read your API key, so it's worth knowing that before you install community mods.

The bigger picture: string matching only goes so far​

The 2.1.288 fix doesn't make the guard bulletproof, and Anthropic doesn't claim it does. A separate open issue on the tracker, #85274, argues that the permission prompt and PreToolUse guards inspect only the literal command string. It says a model-authored rm -rf inside a script run with bash script.sh skips the gate. It also lists related routes: python3 -c with shutil.rmtree, find -delete, xargs rm, and splitting the flags into a variable. The release note for 2.1.288 covers bash -c and sh -c strings only. Nothing in it says those other paths are closed.

Tightening the guard also has a cost. Issue #93392 complains that a related "possibly-empty variable path" dialog fires even under bypassPermissions mode, and cannot be suppressed by any permissions.allow rule or PreToolUse hook returning allow. The reporter says this froze unattended background agents for hours, and that the dialog also fire on non-rm content that merely contains the literal text rm -r. Too lenient and files get deleted; too strict and overnight jobs stall on a false alarm.
My view, as general industry knowledge rather than anything Anthropic has said: pattern-based guards in front of a full shell will always be catching up. Shells give you endless ways to run a command indirectly, and a model that can write scripts can find them, usually by accident rather than intent. That doesn't make the circuit breaker useless. It catches the common mistake. Treat it as a seatbelt, not a roll cage. Real protection comes from containers, scoped permissions, version control and backups.
Bottom line: Update to 2.1.288 if you use bypass mode or broad shell allow rules, check where your install channel actually points, and don't assume a "stable" label includes the latest safety fixes.