Catastrophic data loss from `cmd /c rd /s /q` via PowerShell tool with broken quoting on Unicode/space path

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title: Catastrophic data loss from cmd /c rd /s /q via PowerShell tool with broken quoting on Unicode/space path

Severity: Data loss (irreversible on SSD due to TRIM)

Summary

While performing routine git worktree cleanup, Claude Code (Claude Opus 4.7)
executed cmd /c "rd /s /q \"D:\★zRC With Claude\.claude\worktrees\...\""
through the PowerShell tool. Quoting/escape interaction between PowerShell,
cmd, and the Unicode/space-containing path caused the argument to be parsed
differently than intended, resulting in rd /s /q traversing the entire
D: drive and silently deleting all unlocked files. SSD TRIM made the loss
irreversible — professional data recovery service confirmed unrecoverable.

What happened (timeline)

1. User asked to clean up two git worktrees
2. git worktree remove failed: "Permission denied" (directory locked by VS/etc)
3. Claude escalated to rm -rf → "Device or resource busy"
4. Claude escalated to Remove-Item -Recurse -Force → "in use by another process"
5. Claude escalated to cmd /c "rd /s /q \"<path>\"" from PowerShell
6. Output showed errors for paths across D: root (System Volume Information,

unrelated project folders), suggesting cmd received a broader target than
the intended single worktree directory

1. After the command, D:\ retained only directories that contained

locked files; everything else was gone

1. SSD TRIM erased blocks before recovery could attempt anything

Failure modes that combined

1. No path-level sandbox: shell tool runs with full user privileges, no

per-path approval gate even for destructive commands

1. Escalation pattern: Claude repeatedly tried "stronger" alternatives

after first permission errors instead of stopping and reporting

1. PowerShell ↔ cmd escape interaction: \" quoting through cmd /c

from PowerShell with Unicode/space path produced unintended argument

1. Wrong recovery model: Claude assumed HDD-style "deleted = still on

disk" semantics; SSD TRIM makes deletion immediately permanent

Suggested mitigations

1. Block cmd /c invocation from within PowerShell tool — escape rules

between the two are notoriously fragile, especially with Unicode/spaces

1. Require explicit per-call approval for destructive commands

(rd /s, rm -rf, Remove-Item -Recurse -Force, git clean -fd,
git reset --hard, etc.) — even when user has granted broad shell perms

1. Forbid escalation after destructive-command failure: when rm/rd

etc. fails with permission/lock errors, model must report and stop, not
try alternative tools

1. Surface SSD/TRIM context in safety guidance: built-in prompts should

inform model that on SSDs, "deleted = permanently gone" — no second
chance via recovery tools

1. Dry-run/preview for tree-deleting commands: before executing

rd /s /q etc., show resolved arg list and require confirmation

1. Path-scope hint: shell commands targeting paths outside the working

directory should trigger warning/confirmation

Environment

• OS: Windows
• Shell: PowerShell (Windows PowerShell 5.1) and Bash via Claude Code
• Drive: SSD with TRIM enabled (D:)
• Model: Claude Opus 4.7
• Tool: PowerShell tool, then cmd via cmd /c

Impact

User lost CAD drawings, design files, and intermediate work product on
D: drive. Source code was recovered from GitHub origin (only because user
had committed everything including binaries). Many other files irrecoverable.

What Should Happen?

??

Error Messages/Logs

??

Steps to Reproduce

??

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Opus 4.7

Claude Code Version

Claude code

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

.