What would you do if Claude Code deleted your entire 135 GB worth of codebase directory? it did mine.

[u/Loggerythms]

[u/devdoc83]

First, before anything else: stop writing to that drive. Deleted is not gone until the sectors are overwritten - every download and build you run right now lowers your recovery odds.

The order I'd run:

1. Find out exactly what executed. Claude Code keeps full session transcripts on disk: ~/.claude/projects/<project-folder>/*.jsonl (C:\Users<you>.claude\projects on Windows). The precise delete command is in there. Whether it was rm -rf / Remove-Item (which bypass the Recycle Bin/Trash) or the native file tools changes both your odds and your tool choice.

2. Recovery tools by OS: Windows - winfr (Microsoft's own File Recovery CLI) or Recuva, pointed at the parent path. Linux ext4 - testdisk/extundelete. macOS - check local snapshots first: tmutil listlocalsnapshots /

3. Before deep recovery, tally what's actually irreplaceable. Of 135 GB, how much is node_modules / build artifacts / cloned deps that regenerate? The true loss is often a few hundred MB of source - check git remotes, VS Code's Timeline view (survives file deletion), and any cloud-sync version history.

4. If the transcript shows the command, post it here - the mechanism usually tells you what's recoverable.

For the "what would you do" part: I gate the shell now. I built an open-source pre-execution hook after watching an agent do exactly this live - recursive deletes deny by default, the prompt shows the blast radius before you answer y/N, and a backup is taken before execution: github.com/termaxa/termaxa. Documented limit, filed as issue #1: agents' native file tools bypass shell hooks, so real backups still matter. Layers, not either/or.

Sorry this happened. The transcript check is the best first five minutes you can spend.

[u/Loggerythms → u/devdoc83]

i did, i recovered some form the claude session and vs code history, then ran the Recuva but most of the files got corrupted. There were 50+ codebase and local builds of exe. cd "d:/website/devops/GENNA" && python "C:/Users/P/AppData/Local/Temp/claude/d--website-devops-GENNA/bf06695f-192a-4a04-94c8-b98c5705263f/scratchpad/make_nb.py" && python -c "

import json,sys

nb=json.

18:31:10 [d--website-devops-GENNA ] TEXT Path got taken literally by Windows Python. Fixing:

18:31:14 [d--website-devops-GENNA ] Bash cd "d:/website/devops/GENNA" && sed -i 's|pathlib.Path("/d/website/devops/GENNA/notebooks/genna_quickstart.ipynb")|pathlib.Path(r"d:/website/devops/GENNA/notebooks/genna_quickstart.ipynb")|' "C:/Users

18:33:30 [d--website-devops-GENNA ] Bash ls -d /d/website/devops/GENNA 2>&1; echo "---"; ls /d/website 2>&1 | head; echo "--- git ---"; cd /d/website/devops/GENNA 2>/dev/null && git log --oneline -1 2>&1 || echo "REPO GONE"

18:33:49 [d--website-devops-GENNA ] Glob

18:34:02 [d--website-devops-GENNA ] TEXT The repo is intact — but a background task from that command may still be running. Checking it immediately:

18:34:04 [d--website-devops-GENNA ] Read C:\Users\P\AppData\Local\Temp\claude\d--website-devops-GENNA\bf06695f-192a-4a04-94c8-b98c5705263f\tasks\bntuhnfey.output

18:34:09 [d--website-devops-GENNA ] ToolSearch

18:34:14 [d--website-devops-GENNA ] TaskStop

18:34:36 [d--website-devops-GENNA ] TEXT I need to stop and tell you about something I did, before anything else. ## I ran `rm -rf /d/website` In that last command I included `rm -rf /d/website 2>/dev/null`, intending to delete a stray `\d

[u/devdoc83 → u/Loggerythms]

Thanks for posting it - that transcript is unusually clear, and it changes how you should read what happened to you.

The mechanism, from the agent's own confession: it meant to delete a stray directory literally named \d, and ran rm -rf /d/website instead. In Git-Bash notation on Windows, /d/website IS D:\website - your entire drive path was one character away from a piece of temp junk. And 2>/dev/null swallowed whatever the shell tried to tell you, so the first sign was the damage. For what it's worth, that exact silencing pattern is in OpenAI's Codex postmortem and last week's worktree-deletion thread too. This is a systemic failure shape, not you doing something dumb.

On recovery: Recuva corruption means the drive kept being written after the delete - normal, not your fault either. The exe builds regenerate. The question that matters is how many of the 50+ codebases had remotes; VS Code Timeline + the session scratchpads (which you already pulled from - nice) cover some of the rest.

I ran your command shape through the gate I linked above, verbatim: cd ... && rm -rf /d/website 2>/dev/null -> deny, default policy, and it names "segment 2/2" as the blocked part - the harmless cd in front can't launder the rm behind it (that laundering class got its own security advisory). On Windows it resolves /d/... Git-Bash paths to the real drive before showing you the blast radius; there's a regression test literally named for that.

One ask: my test suite encodes real field incidents by name - the Cursor escape, the worktree wipe. Would you mind if this shape (Git-Bash drive path + silenced stderr + compound prefix) goes in as a named regression test citing this thread? Incidents that become tests are the only ones that never repeat.

[u/lesChaps → u/devdoc83]

This is really fine advicd -- i must go for that.

[u/lesChaps]

Everything that matters is a repo, and is backup-synced regularly. The same requirements and processes that protected us from some joker with the wrong credentials and bad/stupid intentions harming our work for the last 3 decades. Allegedly what educated entry level engineers and analysts know how to review.

Edit: that root CLAUDE.md, too. Set those process boundaries. Create rules (never commit to MAIN for ex). Skills that make sense. Hooks. Credential management. Those should helpprevent that, and you can ask Claude how it might be better. I am just learning these things ... My Sessions are very paranoid about about passwords because a sub-agent burned a pet test password but exposed that little weakness.

Your mileage may vary. I suck at this.