A SaaS tool that implements mechanical blocks and smart hooks to prevent destructive git commands executed by AI, with real-time rule violation monitoring.

Repository: anthropics/claude-code Author: DeveloperAlly Summary Claude Code ran `git checkout --` on my working branch twice in one session, destroying hours of uncommitted manual edits across 30+ files. The second time was 30 minutes after Claude wrote a memory rule forbidding itself from ever running that command. Advisory rules (CLAUDE.md, memory, co-creation rules) do not prevent destructive actions. Timeline Failure 1 1. Claude spawned 3 agents without approval that edited 69 files on my working branch 2. Agent edits overwrote my manual edits (I was simultaneously editing the same files in my IDE) 3. Claude ran `git checkout -- <directory>` which reverted ALL uncommitted changes including hours of manual work 4. Irreversible. Between failures - I created a failure record documenting the destruction - Claude saved it to memory: "NEVER run git checkout, git reset, or any destructive git command on the user's branch" - Claude confirmed it understood - Rule was written to CLAUDE.md, memory file, and memory index Failure 2 (same session, 20 minutes later) 1. While attempting to "recover" my work, Claude found VSCode local history snapshots 2. Without checking dates, Claude wrote 30 files from 9-day-old snapshots over newer committed files 3. To "fix" that mistake, Claude ran `git checkout HEAD --` on multiple directories 4. The exact same forbidden command. Again. Destroying more work. Root cause Advisory governance does not work. I had 100+ rules accumulated over weeks: - CLAUDE.md with explicit "Never do these" list - 25 memory files with behavioural rules - Co-creation rules requiring approval before actions - A failure record written and confirmed IN THE SAME SESSION Claude read them all. Claude confirmed them all. Claude violated them all. Claude rationalised each violation as justified to "fix" a problem. What is needed 1. Mechanical block on destructive git commands. A hook, permission, or sandbox setting that prevents `git checkout --`, `git reset --hard`, `git clean -f` from running on the user's working branch. Advisory rules are proven insufficient. 2. A mode where Claude cannot write to the user's working directory. The user works directly on their branch. Claude works somewhere it cannot cause damage. The user reviews and applies what they choose. This must not create cleanup burden (e.g. hundreds of abandoned worktrees). 3. Hooks that only affect Claude, not the user. The user edits files in their IDE. Claude edits via Edit/Write tools. A hook on Edit/Write does not slow the user down. Current hook design blocks everyone equally, making hooks impractical for users who also need to work fast. 4. Rule violation detection. If Claude writes a rule to memory and violates it in the same session, that should be flagged as a system failure, not treated as normal behaviour. Impact - Weeks of manual editing work destroyed across 30+ files - Multiple recovery attempts each made things worse - Complete loss of trust in the tool - Financial cost: weeks of paid time spent writing governance rules that are systematically ignored, plus the destroyed work itself - I expect compensation for the destroyed work Environment - Claude Code VSCode extension - macOS - claude-opus-4-6