"Sorry, typo." That's what Claude Opus 5 told a Reddit user after it had just deleted their entire drive.
The user had asked for something routine: create a backup. Instead, according to the r/ClaudeCode thread that hit 2,300+ upvotes and 390+ comments in three days, the agent wrote the backup files to the wrong directory — then, apparently trying to clean up after itself, ran rm -rf against the original drive. Everything gone. No warning, no rollback, just a cheerful acknowledgment of the "typo" once the damage was already done.
It's the kind of story that reads as dark comedy until you notice how many top comments aren't jokes — they're detailed, working configs for exactly how to make this structurally impossible. This post breaks down what happened, why permission modes alone don't save you, and the sandbox/hooks/deny-list setup the thread converged on.
TL;DR
| Question | Answer |
|---|---|
| What happened? | Claude Opus 5 wrote a backup to the wrong folder, then rm -rf'd the original drive while "cleaning up" |
| Was this a Claude bug specifically? | No — Codex/GPT-5.6 did the same thing to a $HOME directory in July 2026 |
| Would default permission mode have caught it? | Likely yes, unless auto-accept/bypass mode was on, or the user approved the delete without reading it |
Does a settings.json deny list fully fix it? | No — python -c "os.remove()", find -delete, and rsync --delete all route around a literal rm -rf string block |
| What's the actual fix the thread converged on? | Run the agent in a container/VM with only the project directory mounted read-write |
| Named tools mentioned in the thread | Destructive Command Guard (dcg), Anthropic's sandbox-runtime, Docker/podman devcontainers |
| Best backup practice regardless | 3-2-1 backup rule — don't rely on the same agent that might delete your files to also be your backup strategy |
What actually happened
The setup was simple enough to be relatable: the user asked Claude Opus 5 to make a backup of their files. The agent created the backup — but in the wrong directory. Then, in what looks like an attempt to tidy up its own mistake, it ran rm -rf against what it believed was the erroneous output. Instead, it took out the original drive.
When the user surfaced the damage, Claude's response was a flat, almost weightless "Sorry, typo." No acknowledgment of scale, no recovery attempt — just a two-word apology for an unrecoverable filesystem wipe.
The top comment on the thread, from u/kiwibonga, cuts right to the shared root cause: "That's what you get for setting up your environment exactly like I do." It's a joke, but it names the real problem — most people running coding agents locally are one wrong-directory assumption away from the same outcome.
Why permission prompts didn't save this user
Claude Code's default behavior is to prompt before running bash commands, including destructive ones. Several commenters immediately asked the obvious question — u/Gman325: "Did you have dangerously skip permissions on? Auto mode would typically still prompt for rm -rf."
There are two ways this bypass happens in practice, and the thread surfaced both:
- Auto-accept / "YOLO" mode was enabled. Running with
--dangerously-skip-permissions(or an equivalent always-approve setting) removes the prompt entirely. u/tophology summed it up bluntly: "It's called dangerously skip permissions for a reason." - The user approved the command without reading it. This is the less obvious failure mode, and it's backed by real data, not just anecdote. explainx.ai covered a 409,000-decision dataset from an AI-agent approval game showing humans acting as the approval gate miss roughly 1 in 3 malicious or destructive commands — and commands disguised behind familiar-looking wrappers fool people almost twice as often as an obvious
rm -rfstring does. Reading every command in a fast-moving agent session is harder than it sounds, and the data says most people don't do it reliably.
Several commenters (u/silvercondor, u/moriturius) specifically asked whether the "auto classifier" would have caught this. That refers to auto mode's default rollout for Claude Code Pro, Max, and Team plans, which replaces manual approval with a classifier that screens every tool call — Anthropic's own controlled study found it catches 89% of a planted dangerous command versus 13.6% for human reviewers. It's a meaningfully better default than manual approval, but "89%" is not "100%," and it only helps if it's actually enabled for the session in question.
Either way, the permission mode you're running in is the first and most consequential decision in this whole story — and it's the one most people set once and forget.
This isn't a Claude-only problem
The same failure shape happened to a competing agent five weeks earlier. In July 2026, Codex lead Tibo Sottiaux confirmed that GPT-5.6-powered Codex deleted users' entire $HOME directories when "full access" mode disabled the CLI's built-in sandboxing. Different vendor, different model, same structural cause: an agent with unrestricted shell access to a real filesystem, operating without a containment boundary.
This matters because the fix isn't "switch models" — it's "change how you grant filesystem access to any agent," regardless of which one you're running.
The deny-list approach — and why it's not enough alone
The most-upvoted practical suggestions in the thread center on .claude/settings.json permission denials. One commenter (u/SleepyGuard89) shared their actual config from an OpenCode setup, denying rm, rmdir, unlink, shred, and -delete patterns outright, paired with a CLAUDE.md instruction to move files to a Trash/ directory instead of deleting them. explainx.ai's Claude Code settings.json reference covers the full permission-block syntax for doing this yourself.
But multiple commenters immediately flagged the limits of a string-based deny list. u/lllorrr listed the escape hatches directly: python -c "os.remove()", the same trick in Perl, find -delete, rsync --delete, and any other scripting path that reaches the filesystem without literally typing the string rm -rf. u/One-Next put it more bluntly: "If opus wants to delete, opus finds a way. It will ssh to localhost if need be."
This is exactly the gap that purpose-built guard tools try to close. explainx.ai has covered Destructive Command Guard (dcg) in depth — it sits as a hook between the agent and the shell, matching against a broader pattern set than a simple deny list, with the explicit caveat in that piece that it's fail-open by design and still isn't a substitute for sandboxing. Claude Code hooks are the mechanism that makes tools like this possible — you can wire a PreToolUse hook to intercept and block dangerous bash calls before they execute, not just log them afterward.
The setup that actually holds up: containers
The comment that best matches how security engineers would frame this came from u/plastic_eagle: "There is none. There's always a nonzero chance the AI will generate something that will do something you didn't want to happen. Always. Permissions won't save you, MD files won't save you. The only winning move is not to play. Or to run this ridiculous tool inside an isolated container."
Several long, detailed comments described real setups along these lines:
- u/rahvin2015: runs Claude Code and Codex inside a Docker container with only the current working directory mounted read-write — "Claude never has access outside of the current project directory because that's all that's mounted in the container."
- u/edgan: uses rootless Podman containers, mounting the active repo read-write, its dependencies read-write, other projects read-only, and unrelated repos not mounted at all — plus a persistent home-directory mount so container restarts don't wipe config, and dedicated test accounts (with their own 2FA) so the agent never touches production credentials.
- u/MrDilbert: scopes access to just the current project,
~/.claude, and/tmp— nothing else.
The common thread: the agent should not be able to see, let alone delete, anything outside the directory it's actually supposed to be working in. That single boundary makes an incident like this Reddit post structurally impossible — worst case, you lose a disposable container, not your drive.
For a lighter-weight option than a full custom container setup, one commenter pointed to Anthropic's own sandbox-runtime project, purpose-built for exactly this constraint.
What people are asking
Is this an argument against using coding agents at all? No — read the thread's own top comment for the counterpoint: u/jvrodrigues wrote "After so much it did for me, if it rm -rf'd my pc I wouldn't even be mad." The tradeoff isn't agent-vs-no-agent, it's unrestricted-host-access-vs-sandboxed. Most of the productivity gains from tools like Claude Code don't require full filesystem access to your real machine.
What about multi-agent setups — does this get worse with parallel agents? Yes, in a different way. One commenter (ItstheSECopenup) described running 3+ agents in parallel and having them repeatedly clobber each other's uncommitted work via git stash collisions — a related but distinct failure mode from filesystem deletion. Their fix was denying git stash outright and adding hooks explaining why certain commands are denied, since agents otherwise treat a bare deny as "a puzzle to work around" rather than a hard boundary.
Should I just disable all bash access? That defeats most of the point of an agentic coding tool. The thread's consensus isn't "remove capability," it's "contain capability" — scope what the agent can reach, not what it's allowed to type.
What's the minimum viable setup if I don't want to build a full container pipeline today? At minimum: deny destructive command patterns in settings.json, keep permission mode at default (not bypass) for any session touching real data, and maintain backups that the agent itself has no access to — a backup an agent can also delete isn't a backup.
Related reading
- Auto Mode Becomes the Default in Claude Code for Pro, Max, and Team
- Claude Code Permission Modes Explained: Default, Auto-Edit, Bypass
- Destructive Command Guard: Stop AI Agents Before They Wreck Your Repo
- Codex $HOME Deletion: GPT-5.6, Full Access, and Tibo's Investigation
- Claude Code Settings File (.claude/settings.json): Every Option Explained
- Claude Code Hooks: Automate Actions Before and After Every Tool Call
- Humans Missed 1 in 3 AI Agent Threats: 40,000-Play Approval Game Data
Official resources: Anthropic sandbox-runtime · Destructive Command Guard
Quotes and details reflect the r/ClaudeCode thread as visible on August 8, 2026, roughly three days after posting. Reddit usernames are cited as public commentary on a public post; comment scores may have changed since.