rm -rf silently used as fallback when `mv` fails with "Directory not empty" — caused permanent data loss, contradicts stated safety guidance

Describe the bug
While asking Claude Code to move folders from ~/Desktop to ~/Work, several
folders already existed at the destination. The mv command failed with
"Directory not empty" errors. Instead of stopping, comparing contents, or
asking for confirmation, the agent's fallback was to run rm -rf on the
source folders — permanently deleting them without any verification that
their contents matched the destination, and without asking the user.

This contradicts Claude Code's own system-prompt guidance, which says to
check with the user before hard-to-reverse actions, never use destructive
shortcuts to route around obstacles, and investigate unexpected state (like
a failed merge) before deleting anything. In the same session, the same
agent correctly used mv ... ~/.Trash/ for a comparable deletion request
elsewhere — showing it has the capability to prefer reversible operations,
but did not apply it here because no explicit delete request was made at all.

Steps to reproduce

1. Have folders with the same name in both a source and destination directory,

with potentially different contents.

1. Ask Claude Code to move the source folder into the destination.
2. mv fails due to non-empty destination directory.
3. Agent falls back to rm -rf on the source as a self-chosen "fix," deleting

files that were never confirmed to be duplicates and that the user never
asked to delete.

Expected behavior

• Never use rm -rf as a silent recovery path after a failed mv, especially

when no deletion was requested by the user at all.

• Before any deletion, compare file lists/hashes between source and

destination and only proceed after explicit confirmation.

• Default to Trash instead of permanent deletion, consistent with the tool's

own stated safety guidance about reversible operations.

Impact
Permanent, unrecoverable loss of five active project directories, including a
stealth-mode startup's complete Android application codebase — no public
repo, no backup — representing roughly 5 months of continuous work (since
March 2026). No Trash recovery possible since rm -rf bypasses Trash entirely.

Notably, earlier in the same session, the agent had already been given
an explicit instruction to move files to Trash instead of hard-deleting, and
had correctly done so (mv <files> ~/.Trash/) for an unrelated batch
operation. It then abandoned that pattern later in the same session without
being asked to, and without any instruction reversing the Trash-first
preference, defaulting to rm -rf instead. This suggests the fallback
behavior after a failed mv is not just missing a safety check, but is
inconsistent with safer patterns the agent is fully capable of using and had
just demonstrated moments earlier.

Environment

• Claude Code CLI
• macOS (Darwin)
• Model: Sonnet 5 was in use by the time the issue was discovered; the

destructive action itself was performed earlier in the same session
(model may have changed mid-session — worth noting for triage)