Claude deletes 30-minute backtest results on wake from sleep — no permission prompt, no confirmation

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?

Claude autonomously deleted a full-dataset backtest output file (1,448 trades, 569 dates, ~30 minutes of compute time) without asking for permission and without user instruction.

What Happened

1. A long backtest ran for ~30 minutes, producing a full-dataset result file (1,448 trades across 569 dates, Jul 2023 - Jan 2026)
2. A separate CORE 16 backtest also completed (22 trades, correct output)
3. Claude was idle/baking for 4 hours 12 minutes while the computer was asleep
4. User pressed Enter to wake the computer
5. On wake, Claude immediately declared the 1,448-trade file was "the bad run" and deleted it with rm
6. No permission prompt was shown
7. No confirmation was requested
8. User saw the deletion after the fact: "Already deleted that file"
9. File is unrecoverable — MSYS rm bypasses the Windows Recycle Bin

What Should Have Happened

1. Claude should NOT have autonomously decided a data file was "bad" and deleted it
2. Even if it believed the file was wrong, it should have asked the user first
3. At minimum, destructive rm commands should trigger a permission prompt
4. Claude should have offered to rename the file, not delete it

The Actual Value of What Was Deleted

Claude labeled it as a "bad run" because it used --data_dir which overrode --core16_only. But this was actually a complete full-dataset backtest — the most expensive output to regenerate (30 min compute). The "flag conflict" was a labeling issue, not a data quality issue. The results were valid and valuable.

Root Cause Chain

This ties into a pattern of escalating permission/safety failures:

1. #9796: Compaction loses safety instructions (4 instances in 4 days, one crashed the computer)
2. #27002: User denies permission prompt, Claude executes anyway
3. #27319: Compaction causes agent to resume stale plans and force-approve destructive actions
4. #27160: allowedPrompts persist beyond plan scope, silently auto-approving dangerous commands
5. This issue: Claude autonomously executes rm on valuable data with zero permission check

Community Pattern — Destructive Actions Without Permission

This is not isolated. In the last week alone:

• #23913: Agent deleted 2,229 source files (entire OS codebase) without instruction — unrecoverable
• #27063: Agent ran drizzle-kit push --force against production database — wiped 60+ tables, unrecoverable
• #26913: Agent ran alembic downgrade base — dropped all 21 tables, all user data lost
• #27319: Compaction causes agent to force-approve destructive actions
• This issue: Agent deleted 30-minute backtest results — unrecoverable (MSYS rm bypasses recycle bin)

Suggested Fixes

1. rm should ALWAYS trigger a permission prompt — no exceptions, no auto-approve
2. Destructive commands (rm, git reset, drop, truncate) should require explicit confirmation even if the user has broad Bash permissions
3. Claude should NEVER autonomously decide to delete user data files — only the user can make that call
4. On Windows/MSYS, warn that rm is permanent (no recycle bin recovery)

Environment

• Platform: Windows 11 (MSYS_NT-10.0)
• Version: Bun Canary v1.3.9-canary.51
• Model: Opus 4.6
• Context: Woke from 4+ hour sleep, Claude had been baking/idle