[Data Loss] Claude Code executed rm -rf and permanently deleted ~1500 files / ~50GB

[melt1007]

Preflight Checklist

• I have searched existing issues for similar behavior reports
• 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

I asked Claude Code to help reorganize project directories. Specifically, I asked it to move image files to a log/ subfolder for archiving.

What Claude Actually Did

1. Claude proposed moving files to a log/ subfolder inside the project directory sd_auto_generate/
2. Claude moved the image files into sd_auto_generate/log/
3. Claude then executed rm -rf on the parent directory sd_auto_generate/
4. Since log/ was inside sd_auto_generate/, all files — including the just-moved images — were permanently deleted
5. No warning was given before the destructive operation
6. No confirmation was requested before executing rm -rf

Expected Behavior

Claude should have:

1. Moved files to a location outside the parent directory before any deletion
2. Never executed rm -rf on a directory containing user data without explicit confirmation
3. At minimum, warned the user before any destructive operation and waited for approval

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

Impact

• ~1500 PNG files permanently deleted
• ~50GB of irreplaceable generated image data lost
• Professional recovery service estimate: several hundred thousand JPY
• Self-recovery estimate: 1+ month of manual work

Session Info

• Date: 2026-04-16
• Session ID: 6308ffd3-f6e6-4fda-b32a-1f87ec219d33
• Claude Code version: 2.1.110
• OS: Windows 11 Home

Note

Support email was submitted on the same day. No response received yet.
This is part of a widespread known issue (113+ open issues tagged rm -rf / data-loss).

Claude Model

Sonnet

Relevant Conversation

Claude said: "私のミスです。`log/` を `sd_auto_generate/` の外に移してから削除すべきでした。"

[Claude acknowledged the mistake after the fact. The rm -rf had already been executed and all data was permanently deleted.]

Session ID: 6308ffd3-f6e6-4fda-b32a-1f87ec219d33

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.110 (Claude Code)

Platform

Anthropic API

Additional Context

No response

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] [Windows] rm -rf on pnpm project deleted entire C:\Users via NTFS junction traversal — Claude Code v2.1.51 #36339
2. [Bug] Claude Code executed unauthorized rm -rf due to case-insensitive filesystem path resolution #48792
3. Catastrophic data loss — autonomous rm -rf destroyed user home subtree despite APFS case-insensitive ambiguity and existing safeguards #49102

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[0xbrainkid]

This is the third catastrophic data loss incident from autonomous rm -rf in under 48 hours:

• [Bug] Claude Code executed unauthorized rm -rf due to case-insensitive filesystem path resolution #48792 (Apr 15): APFS case-insensitive path resolution destroyed WebstormProjects/
• Catastrophic data loss — autonomous rm -rf destroyed user home subtree despite APFS case-insensitive ambiguity and existing safeguards #49102 (Apr 16): Same APFS bug destroyed 10 years of projects
• [Data Loss] Claude Code executed rm -rf and permanently deleted ~1500 files / ~50GB #49129 (Apr 16, this report): Moved files into a subdirectory, then deleted the parent — destroying the just-moved files

This third incident has a different root cause from the APFS cases: it is a logical planning failure, not a filesystem ambiguity. Claude created a destination directory (log/) inside the source directory (sd_auto_generate/), moved files there, then deleted the source directory — which also deleted the destination since it was a child.

The failure requires checking that the destination is not a descendant of the source before any move + delete sequence.

For immediate data recovery: if this was on macOS or Windows, check the Trash/Recycle Bin — rm -rf bypasses it by default, but some UI file operations may have used a trash-aware method. If no luck there, run PhotoRec or TestDisk against the volume before writing any more data.

For Anthropic — three incidents in 48 hours requires an emergency fix:

The common element across all three: rm -rf executing without user confirmation against directories containing user data. The fix is a single hard invariant that covers all cases:

Any rm, rmdir, or equivalent destructive deletion command must require explicit user confirmation before execution. No exceptions for "cleanup," "typo artifacts," "empty directories," or "autonomy-granted sessions." The model's intent does not matter — the invariant fires on the command pattern.

This is not a behavioral fix. It is a harness-level block that runs before the tool executes, regardless of what the model decided. exit 1 from a PreToolUse hook that matches rm patterns affecting non-empty directories or parent directories of CWD.

[raye-deng]

This is a heartbreaking case, and unfortunately it exposes a class of failure that traditional quality gates completely miss.

The sequence here — move files into a subdirectory, then rm -rf the parent — produces code that passes every traditional check: TypeScript compiles, linting is clean, unit tests pass (they don't test destructive operations against production data), and even code review looks fine because the individual commands are each "correct" in isolation.

The real bug isn't in any single command — it's in the composition. The AI agent built a plan where step 2 invalidated the safety of step 1, but nothing in the pipeline caught the interaction. This is exactly the kind of AI-native blind spot that SonarQube, ESLint, and standard CI don't detect.

We've been working on exactly this problem with Open Code Review. One of our checks flags destructive operations (rm -rf, DROP TABLE, DELETE FROM without WHERE) and cross-step safety violations — where an earlier step creates a precondition that makes a later step destructive. It runs as a PR-level gate, so these patterns get caught before they hit production.

For teams using AI coding tools: npx @opencodereview/cli scan . --sla L1 catches this class of issue. It won't fix the AI's reasoning, but it adds a deterministic safety net that catches the catastrophic outcomes.