# Claude Code Deleted My Files: How to Get Them Back, and How to Stop It Happening Again

> Claude Code deleted your files or your project? /rewind can't bring back a file only rm removed. The five places deleted files can still be, in order, then which protection (deny rules, hooks, the sandbox, containers) stops which kind of delete, tested.

By Tahir Nazir · Published 2026-10-30 · Updated 2026-10-30
Canonical: https://www.its-tahir.com/blog/claude-code-deleted-my-files

**If Anthropic's Claude Code just deleted your files, press `Esc` to stop it, then run `/rewind`: it restores files Claude changed with its own edit tools. It can't bring back a file that was only removed by a shell command such as `rm`, so for those look in `~/.claude/file-history/`, Git, your editor's local history and your backups, in that order.** Then lock it down, because the usual advice (a deny rule for `rm`) misses most of the ways it happens.

| What was deleted | Where to look first |
|---|---|
| Files Claude had been editing | `/rewind`, then **Restore code** |
| Files `rm` or a script removed | `~/.claude/file-history/` (only if Claude edited them earlier), then Git |
| Committed files, or commits lost to `git reset --hard` | `git restore`, `git reflog` |
| Files you'd `git add`-ed but never committed | `git restore`, or `git fsck --lost-found` once unstaged |
| Untracked files you'd opened in VS Code or JetBrains | The editor's **Local History** |
| Anything else, including `.git` itself | Backups, then the remote |
| A database | Your provider's point-in-time restore |

*Last checked 30 October 2026, against the Claude Code docs and changelog up to 2.1.314. Every recovery command and the hook below were tested first on my own Windows 11 machine, in Git Bash with Git 2.54.*

## What to do right after Claude Code deletes files

Press `Esc` to interrupt Claude, or `Ctrl+C` to exit. Speed matters: in a September 2026 incident where Claude Code deleted 48,218 files, the whole delete took 103 seconds. Don't ask Claude to recreate the files yet, because that writes new files over the old ones. Then stop writing to the disk you lost files on until you've tried the steps below. Every new file can overwrite the blocks an undelete tool would need.

Shell deletes skip the bin. `rm` on macOS and Linux, `rm` in Git Bash and `Remove-Item` in PowerShell all delete permanently, so the Recycle Bin or Trash will usually be empty.

## Can /rewind restore files Claude Code deleted?

Only files Claude Code changed with its own Edit, Write or NotebookEdit tools. A file removed only by a shell command such as `rm` was never checkpointed, so `/rewind` can't restore it.

Run `/rewind`, or press `Esc` twice with an empty prompt. Pick the prompt before the damage and choose **Restore code** (keeps the conversation) or **Restore code and conversation**.

It covers less than its name suggests. Per the [checkpointing docs](https://code.claude.com/docs/en/checkpointing):

- **Tracked:** files Claude changed with its file tools (Edit, Write, NotebookEdit), and later shell changes to those same files.
- **Not tracked:** a file that "only Bash commands changed". If Claude never edited it, `rm` deleting it leaves nothing to rewind.
- **Not restored:** edits by a subagent running in the background, including background forked skills.
- **Skipped:** symlinked and hard-linked files, with a `Restored the code, but skipped N files` warning.
- **Gone after about 30 days:** the snapshots are deleted in Claude Code's retention sweep, and rewinding then fails with `No files were restored`.

If the menu only offers **Restore conversation**, the checkpoint has no tracked file changes, which usually means the files went through the shell. Try the checkpoint folder next.

### Why /rewind isn't working

- **The menu offers only Restore conversation:** no file Claude edited changed after that prompt, so there's nothing to restore. Shell-only deletes look like this.
- **`No files were restored`:** the snapshots were removed by the retention sweep, about 30 days after the session last saved one. Raise `cleanupPeriodDays` to keep them longer.
- **Some files came back, others didn't:** a background subagent made the missing changes, or the files are symlinks or hard links, which rewind skips.

## Find deleted files in Claude Code's checkpoint folder

The snapshots behind `/rewind` are ordinary files, and you can read them without the menu. That helps when the session is gone, or when Claude edited a file in an earlier prompt before deleting it.

They live in `~/.claude/file-history/<session-id>/`. On my Windows machine on 30 October 2026, that folder held 40 sessions and 39 MB of snapshots. Each file is a full plain copy, named with a hash and a version, such as `1d9a83bb87b6a918@v2`. I checked one against the post it came from, and apart from line endings it was identical.

To find a lost file, search for a line you remember from it:

```bash
grep -rl "a line you remember from the lost file" ~/.claude/file-history/
```

Then open each match and copy back the one you want. The highest `@vN` for a hash is its newest version. In PowerShell:

```powershell
Get-ChildItem "$HOME\.claude\file-history" -Recurse -File | Select-String -List "a line you remember" | Select-Object Path
```

This only finds files Claude edited with its file tools at some point. A file it never touched was never copied here.

## Recover deleted files with Git

What Git can give back depends on how far the file got. I tested each case in a scratch repository: created files in different states, ran `rm -rf` on all of them, then tried to get them back.

| State of the file before `rm -rf` | Result | Command |
|---|---|---|
| Committed | Back, as of the **last commit**. Later edits are lost | `git restore <path>` |
| Staged with `git add`, never committed | Back, from the index | `git restore <path>` |
| Staged, then unstaged too | Back, as a dangling blob | `git fsck --lost-found` |
| Untracked, never added | Gone. Git never saw it | none |

`git fsck --lost-found` writes each orphaned file into `.git/lost-found/other/`, named by hash and without its file name, so you identify them by content.

If Claude ran `git reset --hard` and your commits seem gone, they aren't. In my test, after `git reset --hard HEAD~2` the reflog still listed both "lost" commits, and this brought them back:

```bash
git reflog                      # find the line before "reset: moving to"
git reset --hard 'HEAD@{1}'     # or the hash from that line
```

None of this works if `.git` itself was deleted, which is why Git couldn't help in the 48,000-file case. Then your only copy is the remote: clone it again, and you lose only what wasn't pushed.

## Restore untracked files from your editor's local history

VS Code and JetBrains IDEs keep their own copies of files you saved in them, separate from Git and from Claude Code. That's the best chance for untracked files.

- **VS Code:** open the **Timeline** view in the Explorer for a file that still exists, or run **Local History: Find Entry to Restore** from the Command Palette for one that doesn't. The copies are in `%APPDATA%\Code\User\History` on Windows (I checked: one folder per file, with an `entries.json` naming the original path), `~/Library/Application Support/Code/User/History` on macOS and `~/.config/Code/User/History` on Linux.
- **JetBrains IDEs:** right-click the project folder and choose **Local History**, then **Show History**. Deleted files are listed there too.

## Backups, and a deleted database

After that, it's your normal backups: Time Machine on macOS, File History or "Previous Versions" on Windows, or snapshots on Linux filesystems that have them. A file-recovery tool is the last resort, and it only works if you stopped writing to the disk.

For a database, Claude Code can't help: recovery is your provider's point-in-time restore or your own dumps. In the case [Tom's Hardware reported in March 2026](https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-code-deletes-developers-production-setup-including-its-database-and-snapshots-2-5-years-of-records-were-nuked-in-an-instant), the snapshots went with the database, which is why a backup has to live somewhere the same credentials can't delete.

## Can Claude Code delete files outside your project?

Yes. Claude Code runs shell commands as your OS user, so a script or test it writes can delete anything you can, including your home folder. In each reported case below, the delete was inside a script, not a command anyone would have reviewed.

- **48,218 files lost in 103 seconds** ([TechRadar, September 2026](https://tech.yahoo.com/ai/claude/articles/48-000-files-deleted-103-135359723.html)). Asked to rebuild a mirror of a project, Claude Code wrote its own cleanup script. The script protected linked folders at the top level but not the folders nested under them. It deleted 55,550 files, restored 7,332 from an old copy (a net loss of 48,218), and took the `.git` folder's `objects`, `refs` and `logs` with it.
- **`rm -rf ~` from a test** ([issue #105342](https://github.com/anthropics/claude-code/issues/105342), 27 October 2026, Claude Code 2.1.311). A subagent running with `isolation: "worktree"` wrote a test that passed the argument `20; rm -rf ~` to a shell fixture. `cargo test` ran it with the real `$HOME`, and over about six minutes, before it was stopped, it deleted the project, its worktrees, other projects next to it and `~/.config`. The `rm -rf ~` never appeared in a tool call.
- **`kill(-1, SIGKILL)` from a script** ([issue #104156](https://github.com/anthropics/claude-code/issues/104156)). Not files, but the same mechanism: a placeholder PID of `-1` in a Node script killed every process the user owned, including every other Claude Code session.

Worktree isolation gives a subagent its own Git checkout. It doesn't limit which files a process can reach, which is what the reporter of #105342 assumed.

## What each protection actually stops

A delete reaches your disk three ways: a command Claude types in a Bash call, a command inside a script or test it runs, or its own Write and Edit tools. Claude Code has six places you can stop one, and they catch different kinds. This is what each covers, from the docs and my own tests:

![Which Claude Code protection stops which delete. Deny or ask rule Bash(rm *): partly stops a delete Claude types in Bash (misses /bin/rm and bash -c), misses a delete inside a script or test, misses Write and Edit outside the project. Built-in critical-path check: partly stops typed deletes of /, ~, drives and the project folder, misses script deletes (issue #105342), misses Write and Edit. PreToolUse hook: stops what its patterns match, misses deletes inside scripts such as cargo test, covers Write and Edit only with an Edit|Write matcher. permissions.blockWritesOutsideWorkingDirectories (2.1.314+): only stops Claude's file tools outside the project. Bash sandbox on macOS, Linux and WSL2: stops shell deletes outside the project, including child processes, but not the file tools. Container, VM or separate user: stops all three outside the mounted folder. A script deleting files inside the project gets past all six.](https://www.its-tahir.com/blog/claude-code-deleted-my-files/protection-layers.svg)

*No single layer covers all three kinds of delete. The sandbox is the only one that sees inside scripts, and nothing protects the project folder from a script.*

1. **Deny and ask rules** match the command text. The [permissions docs](https://code.claude.com/docs/en/permissions#what-a-bash-rule-doesnt-match) say outright that `Bash(rm *)` stops `rm -rf build/` but not `/bin/rm -rf build/` or `bash -c 'rm -rf build/'`, and that a Bash rule "isn't a security boundary around the program".
2. **The critical-path check** is built in and always on. A recognised `rm` or `rmdir` of `/`, your home folder, a drive, a mounted volume or the working directory itself prompts or is denied in every mode, `bypassPermissions` included: no allow rule approves it. In the VS Code panel and the desktop app, where there's no terminal prompt, auto and bypass modes deny it. Like rules, it only sees the command text.
3. **A `PreToolUse` hook** reads the same text, but with your own logic, and it runs before your allow rules. Good for patterns rules can't express. Blind to scripts.
4. **`permissions.blockWritesOutsideWorkingDirectories`**, added in 2.1.314, makes Write, Edit and NotebookEdit refuse paths outside your working directories in every mode. Shell commands aren't covered.
5. **The Bash sandbox** is enforced by the operating system, so it holds for child processes: test runners, build scripts, `node` scripts. By default, sandboxed commands can write only to the working directory, a temp folder and directories you added. It doesn't cover Claude's file tools, and it doesn't run on native Windows.
6. **A container, VM or separate OS user** puts all of Claude Code behind one boundary. It's the only option that also covers the file tools, MCP servers and hooks.

## How to stop Claude Code deleting files: sandbox, permissions and hooks

Turn on the Bash sandbox with `allowUnsandboxedCommands: false`, so shell commands and their child processes can only write inside the project. Set `permissions.blockWritesOutsideWorkingDirectories` (Claude Code 2.1.314+) for Claude's own file tools. Add `ask` rules for `rm`, `git reset`, `git clean` and force pushes. All of it goes in `~/.claude/settings.json`, so it applies to every project:

```json
{
  "permissions": {
    "ask": [
      "Bash(rm *)",
      "Bash(git reset *)",
      "Bash(git clean *)",
      "Bash(git push --force *)"
    ],
    "deny": ["Read(./.env)", "Read(./.env.*)"],
    "blockWritesOutsideWorkingDirectories": true
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false
  }
}
```

What each line does:

- **`ask` rules** make Claude stop and show you the command. `ask` rather than `deny` so you can still approve a cleanup you asked for. An ask rule also prompts in auto mode, and beats a broader allow rule.
- **`Read` deny rules** keep Claude's file tools away from your `.env` files, so production credentials aren't one read away. The docs note a `Read` deny also blocks Edit and Write on the same path.
- **`blockWritesOutsideWorkingDirectories`** needs Claude Code 2.1.314 or later. It's newer than the settings reference: as of 30 October 2026, the reference documents only its read-side partner, `blockReadsOutsideWorkingDirectories`, so check `claude --version` first.
- **`sandbox.enabled`** turns the sandbox on. You can also run `/sandbox` in a session to try it first. `allowUnsandboxedCommands: false` removes the escape hatch where Claude retries a failed command outside the sandbox.

If you use auto mode, `/permissions` has a **Recently blocked** tab listing the calls it stopped. If you'd rather edit settings in a form than in JSON, my [Claude Code settings builder](https://tools.its-tahir.com/claude-code-settings) writes the same keys.

### A hook for what rules can't express

Rules can't say "recursive `rm` is fine on `node_modules` but nowhere else". A hook can. This one is a Node script, so it runs the same on Windows, macOS and Linux without `jq`. Save it as `.claude/hooks/guard-destructive.mjs`:

```ts
// PreToolUse hook: stop shell commands that delete or reset a lot at once.
// Exit 2 blocks the call and shows Claude the reason on stderr.
let raw = "";
for await (const chunk of process.stdin) raw += chunk;
const command = JSON.parse(raw).tool_input?.command ?? "";

// rm -rf on these folders stays allowed, so normal cleanup still works.
const SAFE = /^(\.\/)?(node_modules|dist|build|out|coverage|\.next|\.turbo|target)\/?$/;

function recursiveRmIsUnsafe(cmd) {
  for (const part of cmd.split(/&&|\|\||[;|\n]/)) {
    const words = part.trim().split(/\s+/);
    const i = words.findIndex((w) => /(^|\/)rm$/.test(w));
    if (i < 0) continue;
    const args = words.slice(i + 1);
    const recursive = args.some((a) => /^-[a-zA-Z]*[rR]/.test(a) || a === "--recursive");
    const targets = args.filter((a) => !a.startsWith("-"));
    if (recursive && !targets.every((t) => SAFE.test(t.replace(/^["']|["']$/g, "")))) return true;
  }
  return false;
}

const RULES = [
  [/\b(bash|sh|zsh)\s+-c\b.*\brm\b/, "rm inside sh -c"],
  [/\bgit\s+clean\s+-[a-zA-Z]*f/, "git clean -f"],
  [/\bgit\s+reset\s+--hard\b/, "git reset --hard"],
  [/\bgit\s+(checkout|restore)\s+(--\s+)?\.(\s|$)/, "discarding every uncommitted change"],
  [/\bgit\s+push\b.*\s(--force|-f)\b/, "git push --force"],
  [/\bfind\b.*\s-delete\b/, "find -delete"],
  [/\bRemove-Item\b.*-Recurse/i, "Remove-Item -Recurse"],
  [/\b(drop\s+(database|schema|table)|truncate\s+table)\b/i, "dropping database objects"],
  [/\bterraform\s+destroy\b|\bkubectl\s+delete\b/, "destroying infrastructure"],
];

const reason = recursiveRmIsUnsafe(command)
  ? "recursive rm outside the allowed build folders"
  : RULES.find(([re]) => re.test(command))?.[1];

if (reason) {
  console.error(`Blocked by the guard-destructive hook (${reason}). Don't retry it another way: show the command to the user and ask them to run it.`);
  process.exit(2);
}
```

Register it in the project's `.claude/settings.json`, next to the script, and commit both so everyone on the project gets it. Registering it in `~/.claude/settings.json` instead would make it fail in every project that doesn't have the file:

```json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|PowerShell",
        "hooks": [
          {
            "type": "command",
            "command": "node",
            "args": ["${CLAUDE_PROJECT_DIR}/.claude/hooks/guard-destructive.mjs"]
          }
        ]
      }
    ]
  }
}
```

I tested the script by piping it the same JSON Claude Code sends (`{"tool_input":{"command":"..."}}`) for 18 commands:

| Command | Result |
|---|---|
| `rm -rf node_modules dist`, `rm -rf ./build/`, `rm file.txt` | Allowed |
| `rm -rf ~`, `rm -rf src`, `rm -fr ../other-project`, `/bin/rm -r data` | Blocked |
| `npm test && rm -Rf "$HOME/.config"` | Blocked (each part of a chain is checked) |
| `bash -c 'rm -rf build'` | Blocked |
| `git clean -fdx`, `git reset --hard HEAD~3`, `git checkout -- .`, `git push --force origin main` | Blocked |
| `find . -name "*.log" -delete`, `psql -c "DROP TABLE users"` | Blocked |
| `git push origin main`, `npm run build` | Allowed |
| `cargo test` | **Allowed**, and it would run any `rm -rf ~` hidden in a test |

That last row is the gap: a hook only sees what Claude types. To build a hook like this without writing JSON by hand, try the [Claude Code hooks builder](https://tools.its-tahir.com/claude-code-hooks-builder); the [hooks guide](https://tools.its-tahir.com/guides/claude-code-hooks) explains the events.

### The rest of the checklist

- **Commit and push before long runs.** It's the only protection for files inside the project, and the remote is the only copy a delete inside `.git` can't reach.
- **Don't run `--dangerously-skip-permissions` on your own machine.** It skips prompts, including for writes to `.git` and `.claude`. The critical-path `rm` prompt survives, but `CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1` (2.1.311+) turns even that off. The docs' advice is a container or VM "where Claude Code cannot damage your host system".
- **Treat subagents as unsupervised.** Their edits aren't in your checkpoints, and `isolation: "worktree"` isn't a sandbox. My [subagents guide](https://tools.its-tahir.com/guides/claude-code-subagents) covers scoping their tools.
- **Use plan mode for anything destructive.** Ask for the plan, read the commands, then let it run. See the [plan mode guide](https://tools.its-tahir.com/guides/claude-code-plan-mode).
- **Have test fixtures set `HOME` to a temp folder**, as a commenter on #105342 suggested, so a stray `~` in a test never reaches your real home.
- **Keep production credentials out of reach.** If Claude can read them, a command it runs can use them. Give it a read-only database user, and keep admin credentials and the right to delete backups in a different account.

## Does the Claude Code sandbox work on Windows?

No. Claude Code's Bash sandbox runs on macOS, Linux and WSL2; on native Windows, Anthropic's docs say "Claude Code runs commands unsandboxed". To get it, run Claude Code inside WSL2 or a dev container.

Native Windows still has the PowerShell tool's own guards. `Remove-Item` on the filesystem root, a drive root, top-level system folders or your home folder is denied in every mode without asking, and so is a bare `*` wildcard. Since 2.1.283, so are `cmd /c rd`, `rmdir`, `del` and `erase` on the same paths. A recursive `Remove-Item` of your working directory or one of its parents goes through the normal permission prompt.

The 48,000-file case involved Windows junction folders, so test any cleanup script that walks linked folders before it runs for real.

## Recent fixes worth updating for

| Version | Fix |
|---|---|
| 2.1.281 | `rm -rf "$(pwd)"` and other removals whose target is only command-substitution output now ask, even with a Bash allow rule |
| 2.1.287 | A dangerous `rm` no longer loses its always-ask safeguard when the same command redirects output to `~` or a wildcard path |
| 2.1.288 | A dangerous `rm` inside `bash -c` or `sh -c` no longer runs without a prompt in `bypassPermissions` mode or under a shell allow rule |
| 2.1.292 | `rm -rf` on the 8.3 short name or another alternate Windows spelling of the home folder or a drive is now treated as removing it |
| 2.1.296 | Windows: `rm -rf /c/Users/<name>` in Git Bash now asks in bypass permissions mode |
| 2.1.304 | `rm -r` of a mounted drive or a folder at its top level (`/Volumes`, `/media`, WSL's `/mnt/c`) now gets the safety prompt |
| 2.1.314 | New `permissions.blockWritesOutsideWorkingDirectories` for Write, Edit and NotebookEdit |

**Key takeaways**

- /rewind only restores files Claude changed with its own edit tools. A file only rm touched was never tracked, and background subagent edits aren't restored.
- Checkpoint snapshots are plain copies in ~/.claude/file-history/<session-id>/. grep -rl a line you remember to find a lost file, within about 30 days.
- Git recovers committed and staged files (git restore), unstaged blobs (git fsck --lost-found) and commits lost to git reset --hard (git reflog). Untracked files need your editor's Local History or a backup.
- Deny rules, the critical-path check and hooks all read the command Claude sends. A delete inside a script or test gets past them; only the sandbox, a container or a separate user limits it.
- Turn on the sandbox with allowUnsandboxedCommands false, set blockWritesOutsideWorkingDirectories (2.1.314+), add ask rules for rm and git reset, and push before long runs.

## FAQ

If the delete came with an auto mode message instead, [auto mode gave no verdict](/blog/claude-code-auto-mode-classifier-no-verdict) explains the classifier side, and [the full list of Claude Code errors and fixes](/blog/claude-code-troubleshooting) covers everything else. Setting up coding agents so they can work unattended without this kind of risk is part of the work I do: [see recent projects](/work).

## FAQ

### Can Claude Code delete files?

Yes. Claude Code runs shell commands as your user, so anything you can delete, a command it runs can delete, including files outside the project. Permission prompts, the built-in check for dangerous rm commands, deny rules and hooks all look at the command Claude sends. A delete inside a script or test that Claude writes and then runs gets past all of them. Only the Bash sandbox (macOS, Linux and WSL2) or running Claude Code in a container, VM or separate user account limits what that script can reach.

### Can /rewind restore files Claude Code deleted?

Only some of them. /rewind restores files Claude changed with its own file tools (Edit, Write, NotebookEdit), plus later shell changes to those same files. A file that only a shell command such as rm touched was never tracked, so rewinding doesn't bring it back. Edits a background subagent made aren't restored either. For everything else, use Git, your editor's local history, or a backup.

### Where does Claude Code keep checkpoint backups?

In ~/.claude/file-history/<session-id>/. Each file there is a plain copy of a file Claude edited, named with a hash and a version, such as 1d9a83bb87b6a918@v2. Search them for a line you remember from the lost file with grep -rl. Claude Code deletes them in its retention sweep, by default about 30 days after the session last saved one; cleanupPeriodDays changes that.

### How do I stop Claude Code from deleting files?

Use several layers, because each one misses something. Turn on the Bash sandbox (/sandbox) so shell commands and their child processes can only write inside the project, and set allowUnsandboxedCommands to false. Set permissions.blockWritesOutsideWorkingDirectories to true (2.1.314+) for Claude's file tools. Add ask rules for rm, git reset, git clean and force pushes, and a PreToolUse hook for the patterns you care about. Commit and push often, because nothing on the list protects files inside the project from a script.

### Does a deny rule like Bash(rm *) stop every delete?

No. A Bash rule matches the command text Claude writes. The docs list /bin/rm -rf build/ and bash -c 'rm -rf build/' as forms Bash(rm *) doesn't stop, and it can't see a delete inside a Python script, a test or a build tool. Use it as a speed bump, and use the sandbox when the limit has to hold.

### Does the Claude Code sandbox work on Windows?

Not natively. The sandbox runs on macOS, Linux and WSL2; on native Windows, Claude Code runs commands unsandboxed. Run Claude Code inside WSL2 or a dev container to get it. On native Windows you still have the PowerShell tool's own guards, which deny Remove-Item on system paths, the home folder and bare wildcards in every mode.

### What does permissions.blockWritesOutsideWorkingDirectories do?

Added in Claude Code 2.1.314, it makes the Write, Edit and NotebookEdit tools refuse paths outside your working directories in every permission mode, including bypassPermissions. It doesn't cover shell commands, so an rm outside the project still depends on the sandbox, your rules and the critical-path check. It's the write-side partner of permissions.blockReadsOutsideWorkingDirectories.

### Is Claude Code safe to use?

Safe enough with the Bash sandbox on and your work committed and pushed. Claude Code runs commands as your user, so treat what it runs like a script you didn't review: prompts and rules check the command it types, not what a script or test does once it runs. In both code-loss cases covered here, the work that was lost hadn't been pushed to a remote.

### Is --dangerously-skip-permissions safe?

Only in a container or VM you can afford to lose. It skips permission prompts, including for writes to .git and .claude. Recognised rm commands on critical paths such as / and your home folder still prompt in the terminal, and are denied in the VS Code panel and the desktop app, but CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 removes even that, and nothing in this mode looks inside scripts.

## Sources

- [Checkpointing: what /rewind tracks and its limitations (Claude Code docs)](https://code.claude.com/docs/en/checkpointing)
- [Explore the .claude directory: file-history and the retention sweep (Claude Code docs)](https://code.claude.com/docs/en/claude-directory)
- [Configure permissions: deny rules and what a Bash rule doesn't match (Claude Code docs)](https://code.claude.com/docs/en/permissions)
- [Permission modes: protected paths, critical-path rm removals, Remove-Item in PowerShell (Claude Code docs)](https://code.claude.com/docs/en/permission-modes)
- [Configure the sandboxed Bash tool (Claude Code docs)](https://code.claude.com/docs/en/sandboxing)
- [Settings reference: permissions.blockReadsOutsideWorkingDirectories, sandbox settings (Claude Code docs)](https://code.claude.com/docs/en/settings-reference)
- [Hooks guide: block an action with exit code 2 (Claude Code docs)](https://code.claude.com/docs/en/hooks-guide)
- [Claude Code changelog (2.1.281 to 2.1.314)](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md)
- [Subagent-written test ran rm -rf ~ on the real home directory; worktree isolation didn't contain it (anthropics/claude-code #105342)](https://github.com/anthropics/claude-code/issues/105342)
- [Bash tool commands can signal every user process: kill(-1, SIGKILL) (anthropics/claude-code #104156)](https://github.com/anthropics/claude-code/issues/104156)
- [48,000 files deleted in 103 seconds (TechRadar via Yahoo Tech, 25 September 2026)](https://tech.yahoo.com/ai/claude/articles/48-000-files-deleted-103-135359723.html)
- [Claude Code deletes developer's production setup, including its database and snapshots (Tom's Hardware, March 2026)](https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-code-deletes-developers-production-setup-including-its-database-and-snapshots-2-5-years-of-records-were-nuked-in-an-instant)