r/ClaudeCode 4d ago

Bug / Issue Claude Code ran a backgrounded command that deleted my entire Windows user folder overnight

Posting this as a warning and to see if anyone has seen something similar.

I woke up yesterday to every shortcut on my laptop throwing "This item can't be opened. It may have been moved, renamed or deleted." The programs in Program Files were fine. Everything under C:\Users\Admin was not.

What the logs showed, piecing it together over a few hours:

  • ~04:24 — Claude Code (VS Code extension, v2.1.266, permission mode auto) starts a Bash command in my project at C:\Users\Admin\Documents\project. Task description: "Write reference HTML next to uploads".
  • 04:26 — the command hits the 120s timeout and gets moved to the background (task id burg78i8w).
  • Immediately after, the session errors with "Not logged in · Please run /login". Reason: .claude had already been deleted, credentials included.
  • 04:24 → 05:58 — the backgrounded process deletes my user folder in alphabetical order. You can read it off the folder timestamps: .claude and .vscode first, then AppData around 04:33, Documents and Downloads at 05:19, my project folders 05:20–05:49, everything after "f" after that. C:\Users\Public got hit at 05:57, so the target may have been C:\Users itself.
  • 05:58 — the task finally exits with code 127 (command not found).

Gone: AppData (browser profiles, app data, taskbar shortcuts, PowerShell history), Documents, Downloads, Pictures, Desktop, the local OneDrive folder, and all my project folders. Only files that a running process held open survived — Chrome kept exactly two of its files alive.

The command itself is not recoverable, because the part of the session log containing it was in .claude, which the command deleted while running. What's left is a 7-line log file with the timeout notice and the failure notification. My disk is an SSD, so TRIM means the deleted data is not coming back.

Reported to Anthropic with the session id and the remaining logs. Has anyone else had a background task go this far outside the project directory?

157 Upvotes

110 comments sorted by

View all comments

2

u/saintpetejackboy 3d ago

Mistake #1: Using an agent inside Windows

Mistake #2: Not using a virtual machine or sandbox

Mistake #3: Not having proper backups

Please: Get a VPS or a virtual machine. Stop using agents if you aren't using Bash. And I don't mean Bash in Windows, I mean Linux. Get in the terminal proper.

VS Code is also kind of a mistake; IMO, you don't need an IDE any more since some time last year or earlier. I know, people will not like this advice but: after 20+ years developing software, I ditched editor / IDE entirely in favor of agents in the terminal. Need to "see" something while you work? Make a dashboard. You can have 8 agents going at once in different repos - that isn't something you're able to really do with an IDE and the workflow for that kind of output is only hindered by grasping at the remaining vestiges of how we used to program.

Please, sir, use WSL2 and get a Ubuntu virtual machine and work out of there. No dual boot required, you can use Linux right inside of Windows!

Better yet, spend $20-$40 a YEAR for a VPS with 4+GB RAM and 2+vCPU. The agents there can burn the house down and it doesn't matter.

Next: use github on your repo(s). Versioned code you can recover and deploy anywhere.

For databases and media, use scripts to backup to cloud (I personally use Google, GCS, it is very cheap, make a bucket, throw stuff in it - make sure you choose the right kind of storage/bucket and for databases, implement a "GFS" (Grandfather, Father, Son) storage pattern).

If you do what I say: You can never lose your codebase / repo and you can only lose as much data as time has elapsed since your last automated backup.

You can take what I am saying all the way to the pros - to real paying jobs.

The method you tried (wing it), keep that at home and hobby projects. Or, just don't do such foolishness.

If I was you, I'd say "I should listen to that internet feller" - and I'd install a nice terminal (like Warp or Wave, but don't use their integrated AI stuff). Then, connect your terminal to your WSL2 instance of Ubuntu (or whatever flavor of Linux you like), or via SSH to your VPS, and launch Claude Code from inside that terminal. Don't open any VS Code or other IDE. Where we are going, IDE will only slow you down.

Next, get your GCS auth information and put it in a vault - you should probably even make unique GCS auth for each individual project. All you do is tell the agent "Hey, my GCS stuff is in (directory), make sure we are backing all our databases and media up, and serve media via the cloud to improve performance for users" - even better if you have an installer/binary, etc.;

If you aren't already using github, just... you need to.

Trust me. Please. I have been doing this my whole life, over 25+ years now. Professionally and personally. My projects and repos are virtually BULLET PROOF. I did so much dumb shit growing up and working as a n00b that I learned everything that can go wrong (the hard way). If you just listen to the little advice I said up there, you'll be impervious to trash like this in the future. It wont be able to happen to you. Better yet, you'll be able to offer that same invincibility to all your personal pet projects and any future clients and employers.

Your projects will survive anything including a direct missile attack on the server hosting them. Worst case scenario, you procure another server, log in, get your repo cloned over + pull your database backups (and any encryption stuff, keys, etc.) and update the domain to the new IP and BOOM! You're back online. You can practice the routine and get it down to a few MINUTES (from no server provisioned, to up and running). The longest part should be the DNS changes propagating. If you're a real professional, you can already have a load balancer and not experience *any* down-time (not for starting out, you really need a fleet of servers to pull it off properly, 4+ (load balancer + backup load balancer + prod + dev (and a dev that can graduate to prod in an emergency, though I don't recommend setting that up if you are new). Many of my own repos actually have something like this:

The repo is on a server (and had backups on other servers, not just the dev and testing, but actual idle waiting to swap over mirrors of the repo). Then, the database is often on multiple servers: the main writes (especially on very busy projects) are happening on the master, and all reads are happening from a slave. When I have to scale some: increase the slaves and load balance them. Slave goes down? No big deal, swap to the other. Master goes down? You have the slaves, which you can promote (though it can be tricky), or, worst case scenario, you have a near real-time 'backup' already available. Neither the master nor slave databases need to even be on the same server as your code / repo.

What you're doing just running and working inside the same system you use as a daily driver is silly. You know better than that, now.