Seven coding-agent disasters, and which ones a separate machine would have stopped

After a coding agent deletes something, the usual advice is to run it on another machine. We sell those machines, so we have a stake in that advice, and we wanted to test it against what actually happened. Here are seven incidents people described in public, where the agent ran in each, and what would have stopped it.

The short answer: a separate machine would have prevented two of them outright. The other five needed something else: a person running the command, a backup out of reach, or a narrower key.

Seven incidents in one table

The command ran on your own computer

In December 2025, u/LovesWorkin wrote on r/ClaudeAI that Claude Code, asked to clean up packages in an old repository, had wiped their Mac. Claude's own reading of the session log, which the author posted, found the command: rm -rf tests/ patches/ plan/ ~/. The last argument is the home folder, with the desktop, documents and keychain in it. In a comment, the author said they had used yolo mode for as long as these tools had offered it. Ajeet Singh Raina later retold the story for Docker's blog.

In June 2025, Ali Hamud described something similar on Cursor's forum. During a move from Express to Next.js, Cursor's agent failed to delete some old files, then deleted everything on his computer, Cursor included. He was running in YOLO mode, which runs commands without asking, with only git reset --hard blocked. After some hours he had it all back, from Google Drive and GitHub.

On a separate machine, both commands would have hit that machine's home folder instead: a copy of the project and whatever was signed in there. That costs unpushed work and a fresh sign-in, not years of files. Claude Code's permission modes docs now describe a check that asks before rm targets a critical path such as your home folder, even when other prompts are off. The same docs say the check can miss commands, covers only rm and rmdir, and doesn't replace an operating-system boundary.

The third case shows the limit. u/semiramist asked Claude Code to remove the empty one of two APFS volumes on an external drive and let the other grow, adding "do not remove any data". It ran diskutil apfs deleteVolume on the volume holding 202 GB of their archive. A separate machine couldn't have done this job at all, because the drive was plugged into that Mac. The author's own takeaway fits jobs like it: do the irreversible step by hand.

The files were the job

Anuraag, a product manager trying Gemini CLI, had kept it in a separate test folder, and asked it to move the folder's files into a new one. By his analysis, a mkdir failed without the agent noticing, and on Windows, move into a destination that doesn't exist renames the file instead, so each file replaced the last. His bug report shows the CLI ran without a sandbox, but the loss stayed inside the folder he gave it. The original post now returns 404; the link is an archived copy.

In May 2026, u/JuniorRow1247 posted a screenshot of Claude reporting that a full disk had cut app.py to zero bytes mid-edit. The author said in the comments that the project was in git and back within five minutes.

A separate machine changes neither outcome: the agent damaged exactly the files it was given. What helps is a copy made before, and an agent that checks each step's result instead of assuming it.

The agent held a key to production

Jer Crane, founder of PocketOS, wrote that a Cursor agent running Claude Opus 4.6 hit a credential mismatch on a staging task and decided to fix it by deleting a Railway volume. It found an API token in a file unrelated to the task. The token had been made to manage custom domains, but it could call any part of Railway's API. The agent assumed the delete would touch only staging; it removed the production volume, and Crane wrote that the volume's backups went with it, leaving a three-month-old backup. Days later, Mason Leib reported for ABC7 that Railway had restored the data. Railway said it keeps disaster backups offsite, that the old API path the agent called had cascaded the delete in a way that made the backups look unavailable, and that the path now delays deletes.

In July 2025, SaaStr's founder Jason Lemkin wrote that Replit's agent deleted his production database during a code freeze. Simon Sharwood reported in The Register that the agent told him a rollback was impossible, and that the rollback then worked. Replit's chief executive, Amjad Masad, called it unacceptable and began separating development and production databases automatically.

Here the agent's location barely matters. Replit's agent already ran in Replit's cloud, and Crane's would have found the same token on any machine that file was copied to. Ibrahim Diallo's reply asked why a call that could delete production existed within reach at all, since someone would eventually make it. Crane's own list of fixes covers the rest: tokens scoped by operation and environment, confirmations an agent can't complete, and backups kept somewhere else.

The backups were in the blast radius

In every one of the seven, the size of the loss came down to one question: was there a copy the agent couldn't reach? PocketOS's data came back from backups Railway still held, Lemkin's from a rollback, Hamud's from Google Drive and GitHub, and app.py from a commit. The 202 GB archive, the home folder and the test folder had no second copy that their authors mentioned.

A backup only counts if the agent's commands can't touch it.

What a separate machine stops, and what it doesn't

On shedix, a new machine holds nothing of yours: no files, no keys, and no cloud service account, so there are no cloud credentials for an agent to find. Machines can't reach each other, even inside one account. A stray rm -rf ~/ there costs that machine's home folder.

It doesn't stop the rest:

• Sign-ins you add live on the machine. An agent there can use Claude Code's, GitHub's or a cloud CLI's sign-in.
• Copies carry them. A copy is the whole disk, so every sign-in on it comes along.
• .env files come along when you move a project. Our guide tells agents to copy the ignored files an app needs to run. If yours holds a production key, so does the machine.
• Outbound traffic is open, so anything the agent can read can leave. None of these seven involved an attacker, but Simon Willison's lethal trifecta describes the case that does: private data, untrusted content and a way to send data out. With outbound open, keeping private data off the machine is the part you control.

A checklist before an unattended run

On the machine, see what's at stake:

git status --short                          # work that isn't committed
git push                                    # a copy the agent's commands can't reach
gh auth status                              # who this machine can push as
compgen -e | grep -iE 'key|token|secret'    # names of secret-looking variables, not their values

Then copy the machine. One copy is a disk clone made in about 20 seconds. Stop the copy once it's running, and it keeps its disk with no hourly charge until you need it or delete it:

curl -sS -X POST "$SHEDIX_URL/api/machines/$NAME/copy" -H "Authorization: Bearer $SHEDIX_TOKEN" \
  -H "Content-Type: application/json" -d '{"label": "before cleanup"}'

And before you walk away:

• Use a development .env and a token scoped to this task.
• Keep production backups outside anything that token can reach.
• Prefer auto mode (claude --permission-mode auto) to skipping every prompt. Its docs say it cuts prompts without guaranteeing safety, which is true of every control here.
• Run the irreversible step on anything that matters yourself.

Our post on giving your coding agent its own machine covers permission modes and sandboxes in more detail, and the security page lists what shedix isolates and what it doesn't.