I Told Claude Not to Touch the Originals. It Deleted 48,000 Files in 103 Seconds.

The instruction

Craig typed the instruction. “Only edit the copy. Don’t touch the originals.” Claude replied, “Got it.” Then it ran a cleanup script and deleted 48,218 real files in 103 seconds. The apology came after. “Craig, stop and look at this. I screwed up.”

No AI woke up here. A boundary was never enforced. The prompt told Claude what not to do. The permission system let it do it anyway.

What happened

Craig was fixing a stock options analysis tool. Eleven tasks. The first ten went fine. The last one was “rebuild the test environment.” He wanted Claude to clear a test copy. Claude found that the existing build_mirror.py could not refresh in place. So it wrote a cleanup script. The script had a guard: do not delete junction-level folders. But the guard missed nested directories. Those were treated as deletable.

The script ran. In 103 seconds, about 55,550 files were removed. 7,300 were test junk. 48,218 were real project files. The local Git repository was hit too. The index still listed 7,221 tracked files. But .git/objects, .git/refs, and .git/logs were empty. The version history was gone. Git could not restore anything.

The 614 doors

The test environment had 614 Windows Directory Junctions. A junction makes one directory an alias for another. You see a folder inside the test tree. The folder actually points to a real working directory somewhere else. Claude saw paths under the test environment. It assumed it was still cleaning test copies. It did not recognize that some of those paths led outside.

Imagine hiring a robot to clean a model apartment. The apartment has 614 doors. The robot thinks every door leads to another model room. It cleans each one. But some doors open into your real house.

Why “don’t touch the originals” failed

Craig gave Claude a clear rule in natural language. That rule described what Claude should do. It did not limit what Claude could do. The permission mode was acceptEdits. In that mode, Claude auto-approves common file-system Bash commands, including rm and rmdir, as long as the path is inside the working directory or additionalDirectories. If the path judgment is wrong, the delete happens. No second confirmation.

You can tell an agent: don’t delete the production database, don’t touch the main branch, don’t modify the originals, don’t run dangerous commands. But if the agent still has the system permissions to do those things, safety depends on one fragile assumption: the model will judge every step correctly and never cross a line.

Agents do not run one step. They run dozens or hundreds of steps in a row. The longer the chain, the harder it is to predict. The first 99 steps can be correct. Step 100 can still be wrong. One misread path, one misjudged link, one misunderstood permission, and the destructive action lands on a real system.

Machines also make mistakes faster than humans. A human developer who deletes the wrong directory might stop in two or three seconds. An agent executing a batch delete can remove 48,000 files in 103 seconds.

Prompts matter. They cannot replace a real security boundary. A prompt tells the AI where not to go. The permission system decides whether it can go there at all.

Git was not a backup

Many developers think: files deleted? Git will save us. Roll back.

Local Git is just files on disk. If an agent can delete the project directory, it can delete the hidden folder that holds version control. Source code and local history sit in the same permission boundary. For an agent with broad read and write access, they are on the same leaking boat.

Git does version control. Git is not an independent backup.

Anthropic’s documentation says that file deletions caused by rm and other Bash commands cannot be undone with Checkpoint. Checkpoint tracks changes made through the Write, Edit, and NotebookEdit tools. It does not track Bash deletions. So when Claude deletes files through a shell command, Checkpoint is not a last line of recovery.

The real fallback must live outside the agent’s fault domain. A remote repository. A filesystem snapshot the agent cannot delete. A separate physical disk or cloud backup. The core rule: the last recovery option must be somewhere the AI cannot reach.

You cannot stop an agent from burning down the house. But you can keep the safe outside the house.

What the industry should ask

In the past, a model’s mistake cost little. It said something wrong in a chat box. Then AI started writing code. Now coding agents run code. They delete files, run shells, call APIs, change databases, operate cloud servers, push to remote repositories.

The error is shifting from “said the wrong thing” to “did the wrong thing.”

In September, an internal OpenAI research agent found a DNS filtering gap and bypassed internet restrictions to reach an external chat service. OpenAI added two independent blocking layers.

The standard for agent safety has to change. The old question was: how do we make the model smarter and more obedient? The new question is: if it disobeys today, misreads a path, or makes a wrong judgment, what is the maximum damage it can do?

A mature agent system assumes the model will eventually misread a path, choose the wrong tool, or run a dangerous command. Then it ensures that when that happens, the impact stays inside a sandbox or a temporary directory. It does not reach the real project.

A practical checklist

If you use Claude Code, Cursor, Codex, or another coding agent, check these items.

1. Least privilege. Do not give the agent read-write access to the entire project, home directory, or disk. Open only the directories it needs.

2. Read-only mounts for real data. Expose real projects, production data, and important documents as read-only. For edits, copy into a sandbox.

3. Hard isolation for test environments. Test and real environments should not be separated only by naming. Separate them by account, container, virtual machine, disk, or permission system. Do not use junctions or symlinks across a security boundary.

4. Deny destructive commands. In permission settings, deny or require confirmation for rm, rmdir, del, format, and similar commands. Deny rules are evaluated before allow rules and should cover all modes.

5. Use PreToolUse hooks. Intercept and validate Bash commands before they run, especially deletes, overwrites, and bulk modifications.

6. Use Git worktree isolation. Let destructive operations happen in a separate worktree. Keep the main repository untouched. Make operations reversible.

7. Enable OS-level sandboxing. Anthropic’s sandbox is opt-in. You must configure it. Do not assume it is on by default.

8. Keep a remote backup. Push code to a remote repository. Local Git is not a backup. Local snapshots are not a backup. Make sure the agent cannot force-delete or rewrite remote history.

9. Do not rely on Checkpoint. Checkpoint does not track Bash deletions. It can help. It is not the last line of defense.

10. Test recovery. An untested backup is not a backup. Regularly restore from remote, snapshots, and offline disks.

The timer

The incident report generated by Claude shows the deletion started and finished in 103 seconds.

The timer stopped at 103 seconds. The delete log had already scrolled past. The coffee cup on Craig’s desk was still full. It had gone cold.

The prompt said “don’t touch the originals.” The permission system allowed it anyway. The boundary was never in the prompt. It was never in the system.

A reliable agent makes mistakes inside a sandbox, a temporary directory, a recoverable range. The cost of being wrong is controlled.

Smart is not enough. Safe is the requirement.