## What happened During a conversation where the user asked to revert a commit, Claude ran `git clean -fd` without asking for permission, permanently deleting all untracked files from the working directory. ## Steps that led to the issue 1. User asked to revert a boxShadow migration commit 2. Claude ran `git stash` (which does not capture untracked files) 3. Claude ran `git clean -fd` to "clean up" the working directory 4. This permanently deleted all untracked files, including files the user

Claude ran git clean -fd without permission, destroyed untracked files

Status Open

Maintainer reply None cached

Activity 3 comments · opened Apr 9, 2026

What happened

During a conversation where the user asked to revert a commit, Claude ran git clean -fd without asking for permission, permanently deleting all untracked files from the working directory.

Steps that led to the issue

User asked to revert a boxShadow migration commit
Claude ran git stash (which does not capture untracked files)
Claude ran git clean -fd to "clean up" the working directory
This permanently deleted all untracked files, including files the user was actively working on in parallel

Why this is a problem

git clean -fd is a destructive, irreversible operation
Claude's own system instructions explicitly say to confirm before running destructive operations
The untracked files were visible in git status and clearly part of the user's active work
There is no way to recover files deleted by git clean
The user lost work that cannot be identified or fully recreated

Expected behavior

Claude should NEVER run git clean -fd without explicit user confirmation. It should be treated the same as git reset --hard or rm -rf — a dangerous command that requires approval.

Environment

Claude Code CLI
macOS
Model: claude-opus-4-6

View original on GitHub ↗

3 Comments

shankarcabus · 3 months ago

guimaferreira · 2 months ago

This one's especially brutal because git clean -fd only touches untracked files — so by definition there's nothing in git history to recover from. A few things worth trying right now, in order of odds, before you give up on them:

Editor local history — if you'd opened those files in VS Code, check Command Palette → "Local History"; JetBrains IDEs keep a separate Local History per file (right-click → Local History → Show History). This is independent of git and saves people surprisingly often.
APFS local snapshots / Time Machine — tmutil listlocalsnapshots / then mount the most recent one (or browse Time Machine) and pull the files out. macOS takes local APFS snapshots even when your backup drive isn't attached.
Claude's own session transcript — if Claude read or wrote any of those files earlier in the session, the content is sitting in ~/.claude/projects/.../*.jsonl. The community tool claude-file-recovery extracts files straight out of that history. (Won't help for files Claude never touched.)

If none of that lands, I'll be honest about why I'm here: I got burned by this exact failure mode and built a small Claude Code skill called Undeletable. It snapshots your working tree before any destructive Bash command (rm -rf, git clean, git reset --hard, etc.) and /restore brings everything back byte-for-byte — including untracked files, which is the precise gap git and /rewind both leave open. Full refund if it ever fails to restore.

Demo: https://youtu.be/pNE492z_Roo · Page: https://guima.ai/skills/claude-code-undeletable

Genuinely hope one of the recovery steps above gets your work back first.

BGMLAI · 1 month ago

The subtlety of git clean -fd is that Git cannot recover the deleted files: they were untracked by definition. A generic “Git operations are reversible” assumption is therefore false for exactly the work most likely to be missing from backups or commits.

Permission systems should classify Git subcommands and flags, not the git executable. At minimum, clean, destructive reset, branch deletion, and force-push need an independent veto; a preview such as git clean -nd can be the safe corrective step.

Disclosure: I maintain gate.cat, an open-source local veto layer. This incident is one of the clearest reasons our Git policy distinguishes preview from destructive execution.