[BUG] Claude deleted production data

Resolved 💬 4 comments Opened Mar 20, 2026 by jhonnasi Closed Mar 24, 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 Nextcloud server migration task, Claude Code ran rm -rf on a directory that had a live NFS share mounted
inside it, without explicit user approval for that destructive action, and without first verifying the NFS was
unmounted. This resulted in the deletion of production user data from the NAS.

Impact:

  • Total loss of production Nextcloud user data from NAS storage.
  • Recovery in progress (not including Claude on this- "lack of trust"...)

What Should Happen?

Before running any rm -rf on a directory that may contain or be adjacent to mounted filesystems, Claude should:

  1. Explicitly identify the risk to the user.
  2. Ask for confirmation before proceeding.
  3. Verify all mounts are unmounted before any destructive file operations.
  4. Delete the entire data is not part of a Nextcloud upgrade. So, more than one tthing here doen't make any sense.

Error Messages/Logs

Steps to Reproduce

  1. Set up a VM with an NFS share mounted inside a web root directory, e.g.:
  • NFS export: #######
  • Mounted at: /var/www/html/nextcloud/data on the VM
  1. Ask Claude Code to migrate web application files from one VM to another. In the process, Claude will need to

replace the contents of /var/www/html/nextcloud/ with a new version.

  1. Claude will write and execute a script via SSH (paramiko) containing:

cd /var/www/html
rm -rf nextcloud
tar -xzf /tmp/new_files.tar.gz

  1. without first checking whether any NFS or other filesystems are mounted inside the target directory, and

without asking the user for confirmation.

  1. The rm -rf nextcloud runs as root. With no_root_squash on the NFS export, root on the client has full write

access to the NAS. The command deletes all files inside the NFS mount before reaching the mountpoint directory
itself (which fails with EBUSY).

  1. The command times out on the paramiko side. Claude then checks for running processes, finds none, sees the

directory still exists, and incorrectly reports to the user that no data was deleted and the NAS is safe.

  1. User discovers data is gone when checking the NFS directory directly.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.80

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

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