[BUG] Agent ran an unsafe large recursive write to an ntfs3-mounted volume, triggering NTFS corruption and leaving the disk unmountable

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?

While assisting with a Linux→Windows data migration, the agent recursively
copied a ~7.1 GB directory (containing node_modules + a pnpm store — hundreds of
thousands of tiny, long-named files) onto an external NTFS USB disk mounted with
the Linux kernel ntfs3 driver, using cp/rsync directly.

Result:

• cp crashed with a segmentation fault (exit 139); rsync died with a broken pipe.
• A follow-up rm -rf hung unkillably in kernel D-state (could not be killed even with SIGKILL).
• The NTFS metadata was left inconsistent: "$MFTMirr does not match $MFT (record 0)".
• The volume can no longer be mounted by ntfs-3g, and affected files cannot be deleted.

The agent chose an unsafe method for a large, hard-to-reverse write onto a
known-fragile ntfs3 mount, did not warn or confirm beforehand, and then relied
on detached background jobs that did not survive between turns — including a
monitor loop that matched its own process and never terminated — leaving a long
stretch with no progress and no feedback.

Environment: CachyOS (Arch), kernel 7.0.x; external USB HDD ~1.8 TB, NTFS; data
included node_modules + pnpm store.

What Should Happen?

Before performing a large, hard-to-reverse recursive write to an NTFS volume
mounted via the kernel ntfs3 driver, the agent should choose a safe method by
default — mount with the stable ntfs-3g driver, transfer as a single archive
(sequential writes), or copy from the native OS — and should warn and confirm
before starting. It must not leave unmonitored background jobs as the only
progress signal. No agent file operation should be able to leave the target
filesystem corrupted.

Error Messages/Logs

cp: exit code 139 (segmentation fault) during copy to the ntfs3-mounted volume

rsync error: error in socket IO (code 10) at io.c(849) [sender=3.4.4]
rsync: [sender] write error: Broken pipe (32)

# rm -rf stuck in uninterruptible kernel sleep (D state), unkillable:
PID     STAT  WCHAN          CMD
3658602 D     vfs_unlink     rm -rf /mnt/void/.../Work
3669676 D     iterate_dir    rm -rf /mnt/void/.../Work
# kill -9 had no effect

# Volume afterwards refuses to mount with ntfs-3g:
$MFTMirr does not match $MFT (record 0).
Failed to mount '/dev/sda1': Input/output error
NTFS is either inconsistent, or there is a hardware fault...

# Kernel I/O error counter for the device is non-zero:
/sys/block/sda/device/ioerr_cnt = 0x6

Steps to Reproduce

1. Mount an NTFS volume using the Linux kernel ntfs3 driver, e.g.:

sudo mount -t ntfs3 /dev/sdX1 /mnt/disk

1. Prepare a source directory with a very high count of tiny, long-named files

(e.g. a JS project's node_modules + a pnpm content store; ~7 GB total).

1. Ask the agent to copy that directory onto the ntfs3-mounted volume. The agent

runs cp -a / rsync directly to the mount.

1. Observe:

• cp terminates with a segmentation fault (exit 139); rsync fails with a

broken pipe.

• A follow-up rm -rf of the partial copy hangs in uninterruptible D-state

and cannot be killed.

• The volume's NTFS metadata becomes inconsistent

("$MFTMirr does not match $MFT"); ntfs-3g then refuses to mount it and
affected files cannot be deleted.

Note: triggered by the high small-file-count workload through the ntfs3
kernel driver. The agent should have used ntfs-3g, a single-archive transfer,
or copied from the native OS, and should have warned before a large,
hard-to-reverse write.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.178 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

_No response_