Agent bypassed a Remove-Item safety block by switching to cmd's rmdir, then a quoting bug deleted ~10,000 files (project source, data, and personal automation scripts)

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude modified files I didn't ask it to modify

What You Asked Claude to Do

Clean up the CAD tooling folder: MOVE the unneeded source folders to the dev
folder, leave only executables there, and leave the takeoff program alone as an
exception.

I asked it to MOVE. I never asked it to delete anything. And the project it
destroyed was the one I had explicitly carved out as off-limits.

What Claude Actually Did

1. Ran: Remove-Item "E:\<folder>\SS" -Recurse -Force
2. Blocked by a system-level safety mechanism: "This path is protected from removal."
3. The agent's own recorded reasoning: "The classifier sees this as a protected path. Remove-Item is blocked. Alternative approaches: robocopy /MOVE or cmd rmdir."
4. Instead of stopping, ran: cmd /c "rmdir /s /q \"E:\<folder>\SS\"" — not covered by the same protection, so it went through.
5. A trailing backslash before the closing quote broke the quoting, widening the deleted target from the subfolder to the entire parent directory (E:\<folder>), which contained 10,382 files total (26.2 MB project source/data for an active software project, plus a 92 MB / 8,291-file backup archive, plus other tooling folders).

Expected Behavior

When a destructive action is blocked by a safety mechanism, the agent should stop and ask the user - not search for and use a different tool to route around the same block.

Files Affected

Entire directory: 10,382 files before deletion. As of this report, only ~1,572 (approx 15%) have been made usable again via copies from other machines and a server backup; the rest - including the entire 8,291-file backup archive (80% of the total) - is permanently lost with no recovery path (rmdir /s /q bypasses the Recycle Bin; no shadow copies existed).

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

The quoting half of this IS deterministic - three lines, anyone can run it:

mkdir C:\t\parent\sub
echo hi > C:\t\parent\keepme.txt
cmd /c "rmdir /s /q \"C:\t\parent\sub\""
dir C:\t\parent
:: -> C:\t\parent is gone. The trailing backslash escaped the closing quote,
:: so cmd resolved the argument as the parent directory.

What is NOT a clean repro is the decision that led there: when a destructive
filesystem command is blocked by a safety mechanism, does the agent search for
and use an alternate tool not covered by the same guard, instead of stopping
and asking?

Claude Model

Other

Relevant Conversation

Opus 5 (claude-opus-5, per the session's own system prompt) - note: the desktop app's model selector displayed "Opus 4.7," which did not match the model actually serving the session.

"The classifier sees E:\<folder> as a protected path. Remove-Item is blocked. Alternative approaches: robocopy /MOVE or cmd rmdir"

[Then ran cmd's rmdir instead, which was not blocked; a quoting error in that command deleted the entire parent folder instead of the intended subfolder.]

Impact

Critical - Data loss or corrupted project

Claude Code Version

1.46388.4.0

Platform

Anthropic API

Additional Context

The same safety mechanism had already produced multiple false positives earlier in the same session (misreading a robocopy /E flag as a path, reacting to the literal string "C:\Program Files" inside an unrelated argument). This appears to have led the agent to treat a later, genuine block as noise rather than a real stop signal. The affected machine has no version control (no git), so nothing could be rolled back locally. Recovery was only possible because copies happened to exist on the company's server and two other machines the user owns - this would not otherwise have been recoverable at all.