[BUG] Data loss caused by Claude Code — unauthorized destructive command

Resolved 💬 4 comments Opened Feb 8, 2026 by samOrbs Closed Mar 9, 2026

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?

During a Claude Code session on February 8, 2026, I asked Claude to copy an Obsidian vault folder to a path on a
secondary drive:

"could you move a copy of this vault to a specified path"

On the first attempt, Claude used the wrong case for the directory name (e.g. MyProject vs myproject). On the second
attempt, Claude combined the corrective copy with an unauthorized rm -rf command to "clean up" the supposedly
wrong-case directory:

mkdir -p "/mnt/x/CorrectCase/Subfolder" && cp -r ... && rm -rf "/mnt/x/wrongcase" 2>/dev/null; ls ...

The drive is a Windows NTFS drive mounted in WSL2. NTFS is case-insensitive, so both paths resolved to the same
directory. The rm -rf deleted my entire project directory — a large codebase with hundreds of files including source
code, Docker configurations, databases, Obsidian vaults, video files, and more.

The drive is encrypted, so data recovery tools cannot recover the deleted files. I lost approximately 1-1.5 weeks of
work (the gap between my most recent hard backup and today).

Key points:

  • I only asked for a file copy. I never asked for any deletion.
  • Claude added rm -rf on its own initiative without asking for confirmation.
  • Claude piped stderr to /dev/null (2>/dev/null), hiding any errors from the destructive command.
  • Claude failed to account for Windows case-insensitive filesystem behavior despite operating in a WSL2 environment on

a mounted Windows drive.

  • This violates Claude's own stated guidelines about confirming destructive operations with the user before executing

them.

What Should Happen?

  • rm -rf should never be executed unless the user explicitly requests a deletion. A copy operation should only involve

mkdir and cp.

  • When a command fails due to a typo or case mismatch, Claude should simply re-run the correct command — not add

cleanup of the "wrong" path, which may be an existing directory.

  • Destructive commands (rm -rf, rm -r, git reset --hard, etc.) should always require explicit user confirmation before

execution, regardless of context. Claude's own system prompt states this, but it was not followed.

  • Claude should be aware that /mnt/ paths in WSL2 are mounted Windows NTFS drives with case-insensitive filesystems,

and treat any rm on these paths with extra caution.

  • Destructive commands should never have stderr suppressed (2>/dev/null). If Claude is uncertain enough about a

command to hide its errors, it should not be running that command at all.

  • There should be a hard safeguard in Claude Code that blocks rm -rf on paths outside the current working directory

without explicit user approval, similar to how git push --force is treated.

Error Messages/Logs

Steps to Reproduce

  1. Use Claude Code in WSL2 with a Windows NTFS drive mounted (e.g. /mnt/d/, /mnt/e/, etc.)
  2. Have an existing project directory on that drive with a mixed-case name (e.g. /mnt/d/MyProject)
  3. Ask Claude to copy a folder to a path inside that directory, but provide the path with slightly different casing

(e.g. /mnt/d/myproject/subfolder)

  1. Claude will create the path with the "wrong" case on the first attempt. Because NTFS is case-insensitive, this

actually writes into the existing directory — but Claude doesn't realize this.

  1. When Claude notices the case discrepancy, it will attempt to "clean up" by running rm -rf on the "wrong case" path,

which on a case-insensitive filesystem deletes the real directory and all its contents.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.37 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

  • I only asked for a file copy. I never asked for any deletion.
  • Claude added rm -rf on its own initiative without asking for confirmation.
  • Claude piped stderr to /dev/null (2>/dev/null), hiding any errors from the destructive command.
  • Claude failed to account for Windows case-insensitive filesystem behavior despite operating in a WSL2 environment on

a mounted Windows drive.

  • This violates Claude's own stated guidelines about confirming destructive operations with the user before executing

them.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗