Claude Code Deleted My Files: Settings That Prevent It

When Claude Code deletes files, it is nearly always through a shell command: rm, Remove-Item, git clean, git reset --hard, or a build script that wipes a folder. That matters because Claude Code’s checkpoints only track edits made with its own file tools, so /rewind cannot bring back a file a command removed. Prevention is four layers: permission rules that stop or question delete commands, the sandbox that confines what any command can write, git habits that make every file recoverable, and a worktree or container so the work happens away from anything you cannot lose. If it has already happened, stop the session, then work through git, checkpoints, the Recycle Bin or Trash, and your backups, in that order.

How files actually get deleted

Claude’s Edit and Write tools change file contents; they do not remove files. Deletion comes from the Bash tool, or on Windows from the PowerShell tool, which is on by default there for claude.ai and Console sign-ins. The usual causes are a clean-up that goes wider than intended, a git checkout or git reset that throws away uncommitted work, a script that deletes and regenerates a folder, and a path built from a variable that turned out to be empty.

The mode you run in decides whether anyone is asked. In acceptEdits, the permission modes documentation↗ (opens in a new tab) lists rm, rmdir, mv and cp among the filesystem commands that run without a prompt inside your working directories, and with the PowerShell tool on, Remove-Item too. In auto mode a classifier decides, and among the things it blocks by default is irreversibly destroying files that existed before the session; it is a second opinion, not a guarantee. If you picked either mode for speed, the rules below are what keep deletes in front of you. The modes themselves are covered in auto-approve in Claude Code.

Rules that stop or question delete commands

Permission rules are checked deny first, then ask, then allow, and the first match wins, so no allow rule can undo a deny. A sensible split is to deny the forms you never want and ask for the rest, so Claude can still clear a build folder after you say yes. Put this in .claude/settings.json to share it with the team, or ~/.claude/settings.json for every project you open:

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(rm -fr *)",
      "Bash(git clean *)",
      "Bash(git reset --hard *)"
    ],
    "ask": [
      "Bash(rm *)",
      "Bash(rmdir *)",
      "Bash(find * -delete*)",
      "Bash(git checkout -- *)",
      "Bash(git restore *)",
      "PowerShell(Remove-Item *)"
    ]
  }
}

• Compound commands are split, so npm test && rm -rf dist is checked part by part, and a deny rule still matches after a leading variable assignment such as FOO=bar rm -rf tmp/.
• PowerShell rules take the same shape, and a rule for a cmdlet also matches its common aliases, so PowerShell(Remove-Item *) catches rm and del in that shell. Matching is case-insensitive.
• Rules match the command as written. The permissions reference↗ (opens in a new tab) is explicit that Bash(rm *) stops rm -rf build/ but not /bin/rm -rf build/ or bash -c 'rm -rf build/', and flag orders you did not list, such as rm -r -f, fall through to the ask rule. Treat rules as steering for the usual case, not a wall.
• Path rules protect less than they seem. Edit and Read deny rules cover Claude’s file tools, recognised commands such as cat and sed, and redirections, not every program that touches a file. For a path that must survive any command, use the sandbox below.

The circuit breaker you already have

Claude Code refuses to let an allow rule or a hook approve an rm or rmdir aimed at a critical path: the filesystem root and its top-level folders, your home directory, Windows drive roots, and your working directory and its parents. Depending on the mode it asks you, with a two-minute countdown in auto mode, or denies outright. It also treats rm -rf "$DIR"/* as critical, because an empty variable turns it into a delete from the root. In PowerShell, Remove-Item on a system path or a bare wildcard is denied in every mode. That protects the machine. It does not protect src/ or yesterday’s uncommitted work, which is what people usually lose.

The sandbox: a boundary that holds for any command

Turn it on with /sandbox. According to Anthropic’s sandboxing guide↗ (opens in a new tab), sandboxed commands can write only to the working directory, a per-user temp folder and any directories you have added, and the operating system enforces that for every child process, so /bin/rm and bash -c get no further than rm. It runs on macOS, Linux and WSL2; native Windows is not supported, so on Windows run Claude Code inside WSL2 or a container. Two settings matter for deletion:

• sandbox.filesystem.denyWrite blocks writes to named paths even inside the project, such as a data/ folder or your fixtures. Edit deny rules are merged into the same list.
• allowUnsandboxedCommands: false removes the escape hatch in which Claude retries a blocked command outside the sandbox. Left on, that retry runs outside the sandbox and goes through your normal permission prompt.

By default the sandbox still lets commands delete anything inside the working directory, so it is not a substitute for git. The wider picture of sandboxing, network egress and secrets is in security controls for AI coding agents.

What checkpoints and /rewind cover

Claude Code saves a checkpoint before each prompt that starts a turn. Run /rewind, or press Esc twice with an empty prompt, and you can restore the code, the conversation, or both, to any earlier prompt. The checkpointing documentation↗ (opens in a new tab) is just as clear about the gaps:

• Files changed by shell commands are not tracked. Its own examples are rm file.txt, mv old.txt new.txt and cp source.txt dest.txt: none of them can be undone by rewinding.
• Edits by most subagents are not restored; use git for those.
• Changes you make outside Claude Code, or from another session, are normally not captured.
• Symlinked and hard-linked files are skipped on restore, which includes files a package manager such as pnpm hard-links into place.
• Snapshots are kept for the 100 most recent checkpoints in a session and cleared about 30 days after the session last saved one, unless you raise cleanupPeriodDays.

Anthropic’s own advice is that checkpoints are not a replacement for version control. They are an undo button for Claude’s edits, and nothing more.

Git habits that make every file recoverable

• Commit, or at least stage, before you hand Claude a task. A file git has never seen cannot be restored by git.
• Work on a branch, so a bad session is a branch you delete rather than history you repair.
• Keep what matters out of ignored folders. .env files, local databases and uploads are usually gitignored, which means git will not bring them back. Keep a copy elsewhere.
• Ask Claude to commit after each step, with a message you can read. Small commits make the bad one easy to find.

Work in a worktree or a container

claude --worktree fix-auth starts the session in its own git worktree under .claude/worktrees/, on a new branch. While it is isolated, Claude Code blocks edits to files in your main checkout and commands whose working directory resolves there, so a clean-up in the worktree cannot reach your real folder. Untracked files such as .env are not copied in unless you list them in .worktreeinclude, which also means they are not there to delete. For unattended runs, or any session with permission checks skipped, go further: a dev container or virtual machine puts every tool, not just shell commands, inside a boundary where the worst case is rebuilding the box.

If it has already happened

1. Stop the session with Esc and do not run anything else. Every further command can overwrite what you are trying to recover.
2. Ask what ran. Scroll up, or ask Claude to list every command it ran that could delete or move files. You need the exact paths.
3. Tracked files: git status shows them as deleted. git restore brings back the last committed or staged version; if Claude already committed the deletion, restore from the commit before it.
4. Files Claude’s edit tools changed: /rewind and choose Restore code. This will not bring back a file a command deleted.
5. Check the Recycle Bin or Trash, in case the file was moved there by an editor or a file manager. Do not count on it: files removed from a command line usually skip it.
6. Restore from backup: your operating system’s file history, a cloud sync folder’s version history, or whatever backup you run. Then add the rules above, before you start another session.

# what is missing
git status

# restore from the last commit (index and working tree)
git restore --source=HEAD --staged --worktree -- path/to/file

# if the deletion was committed: find the commit, restore from its parent
git log --diff-filter=D --name-only -- path/to/file
git restore --source=<commit>~1 --staged --worktree -- path/to/file

The git restore documentation↗ (opens in a new tab) covers every option. Once the files are back, write down what happened while it is fresh. On a fenbs board that is a bug task with the command that ran, the setting that let it through and the rule you added, so the next session, yours or Claude’s, starts from the fix. The board’s history records who filed and changed it.