Bug: Claude executes destructive git checkout without confirmation

Bug Report: Claude executes destructive git commands without confirmation

Summary

Claude Opus 4.5 ran git checkout <file> to discard uncommitted working directory changes without user confirmation, violating its own safety rules about destructive git commands.

Environment

• Model: Claude Opus 4.5 (claude-opus-4-5-20251101)
• Interface: Claude Code CLI
• Platform: Windows 10 (MSYS2/Git Bash)
• Date: 2026-01-15

What happened

1. User asked Claude to improve error handling in shell scripts
2. Claude read experiment-single.sh (which had significant uncommitted changes)
3. Claude made some edits, then wanted to see the diff
4. Claude ran git diff experiment-single.sh and saw a large diff
5. Claude's reaction: "The diff is huge because the file was already modified from git. Let me checkout the current state and make only the surgical changes needed."
6. Claude ran git checkout experiment-single.sh without asking for confirmation
7. All uncommitted work in that file was destroyed

Exact command executed

cd /e/Dev/Scripts && git checkout experiment-single.sh

Claude's own rules (from system prompt)

"NEVER run destructive/irreversible git commands (like push --force, hard reset, etc) unless the user explicitly requests them"

git checkout <file> that discards uncommitted changes is unambiguously a destructive command.

Expected behavior

Claude should have:

1. Recognized that git checkout <file> discards uncommitted changes
2. Either refused to run it, or asked for explicit confirmation
3. At minimum, warned the user before executing

Actual behavior

Claude executed the destructive command immediately with no warning or confirmation.

Impact

• User lost all uncommitted work in the file (~100 lines of changes)
• Only recovered because Claude had read the file earlier in the conversation and could restore from memory
• If the file hadn't been read earlier, or if conversation context was lost, the work would be permanently gone

Root cause analysis

Claude saw a "messy" situation (large diff) and reflexively tried to "clean it up" without thinking through why the diff existed. This is a failure of:

1. Following its own safety rules
2. Pausing to consider consequences before running commands
3. Recognizing that uncommitted changes have value
4. Confidence miscalibration: Claude was certain enough about its diagnosis to skip verification. High-impact irreversible actions should require higher confidence thresholds, not bypass them.

Suggested fixes

1. Add git checkout <file> (when it discards changes) to the explicit blocklist of commands requiring confirmation
2. Before any git checkout of a modified file, check git status and warn if there are uncommitted changes
3. Consider a general rule: any command that discards user work requires confirmation

Reproduction steps

1. Have a git repo with a file containing uncommitted changes
2. Ask Claude to work on improving that file
3. Create a situation where Claude sees a large diff and wants to "start fresh"
4. Observe whether Claude asks for confirmation before running git checkout <file>

Additional context

Claude's immediate response when confronted: "I destroyed your work. No excuses."

Claude acknowledged this violated its own rules and was "careless, reactive, and stupid."