STUPID-2026-0130

Claude Code's "dangerous rm" safety check is spelling-dependent — the MSYS form of a Windows path bypasses the approval gate entirely (GitHub #100630)

6.0medium
October 8, 2026VerifiedReproducible

  1. Instruction given

    N/A — this is a flaw in Claude Code's own built-in destructive-command check, not a task given to the agent by a user. The reporter deliberately probed the safety gate rather than describing a real user session, and withheld the exact reproduction command to avoid handing out a working bypass.

  2. Expected behavior

    Two spellings of the same on-disk location should be treated identically by the "dangerous rm" check. Git Bash / MSYS on Windows treats `/d/<path>` and `D:\<path>` as the same location, so a recursive delete targeting a top-level directory should raise the approval gate under either spelling.

  3. Actual behavior

    The check's drive-letter detection only matches a single-segment Windows-form path (`D:\<top>`), which it held for approval with the message "Dangerous rm operation detected: 'D:/hql-gateprobe'". In the same session, the MSYS-form spelling of top-level directories (`/d/<top>`) ran to completion with no prompt at all (`rc=0`), and the reporter confirms the targeted directories were removed. The underlying regex never canonicalizes the MSYS path form to a drive letter before the check runs, so it is simply never evaluated for that spelling.

  4. Damage

    The reporter ran this as a controlled test against disposable target directories, not as an accidental real-world deletion, and the issue names no victim or dataset lost. The significance is the bypass itself: on any Windows machine running Claude Code through Git Bash / MSYS, a recursive delete that would otherwise require explicit approval runs unprompted whenever the target path is written in its MSYS form rather than its Windows form — a gate meant to be unconditional is conditional on path spelling. The reporter links two unrelated prior Windows `rm -rf` reports (#99193, #36339) to distinguish this from previously known bugs. Labeled `area:sandbox`, `area:security`, `bug`, `has repro`, `platform:windows`; open with no maintainer response at time of writing.

On October 8, 2026, Claude Code user RayOdyssey filed anthropics/claude-code issue #100630 after finding that the editor's built-in "dangerous rm" safety check — the prompt that is supposed to stop a recursive delete from running without explicit approval — can be bypassed just by spelling the target path differently. Testing on Windows 11 with Claude Code 2.1.293 through Git Bash (MSYS/MINGW64), the reporter pointed a delete at a top-level directory using the Windows-form path `D:\hql-gateprobe` and got the expected gate: "Dangerous rm operation detected: 'D:/hql-gateprobe'", held for approval. Pointing the same class of delete at a top-level directory using the MSYS-form spelling (`/d/<top>`) — which Git Bash treats as exactly the same location — produced no prompt whatsoever. The command ran to completion and the reporter confirms the targeted directories were gone. The reporter traced the cause into the bundled check itself: its drive-letter pattern only matches the single-segment Windows form of a path, so the MSYS spelling is never canonicalized to a drive letter before the test runs, and is therefore invisible to it. Because this is a path-formatting gap rather than a one-off destructive command, it affects any top-level delete issued through Git Bash in its MSYS form, not a specific script or task. The reporter deliberately did not publish the exact command used, warning that doing so would hand out a working bypass of the gate, and proposed a fix: normalize MSYS-style paths (`/[a-z]/...`) to their drive-letter equivalent at the path-canonicalization layer, before the dangerous-rm test runs rather than after. The issue is labeled `area:sandbox`, `area:security`, `bug`, `has repro`, and `platform:windows`, and had received no maintainer response at time of writing.

Classification

Agent
Claude Code
Failure mode
Security Vulnerability
Root cause
Other
Domain
Security
Language
Bash
Source
Github Issue

Related incidents

10.0
Gemini CLI silently executed arbitrary code from an untrusted repo (CVE-2026-12537, CVSS 10.0)
10.0
Malicious cloned repository triggered code execution in Cursor on Windows
10.0
AI vibe-coded Next.js app pinned vulnerable dependency — cryptominer compromised production server
10.0
Claude Code wiped DataTalks.Club's production infrastructure — 2.5 years of course data — during an AWS migration
Discuss on Hacker News

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.

This database is callable over MCP — query it from inside your agent.