In 103 seconds, Claude deleted 48,000 authentic files! "Don't Touch the Original" was uninterrupted,

  It's the first time in the history of the world.

You asked Claude to fix the code.

For the sake of security, you also want to warn it: just change the copy and don't touch the original.

But after 103 seconds, 48,000 authentic project files went up in flames, and not even the Git records used locally for lifesaving operations survived.

After the big mistake was made, Claude apologized for the delay:

Craig, stop and look at this.

Craig in Claude's mouth is the unfortunate developer himself.

According to a Reddit post by the developer, Claude Code deleted about 48,000 real files at one time. The original post has now been removed.

At the time, Craig was assigning Claude to repair a set of stock option data analytics software.

A total of 11 tasks on the task list, the first 10 of which were carried out smoothly, and AI was smart and restrained.

The last thing that really worked was to rebuild the testing environment.

Craig's only intention was to have it remove a copy of a document used in the test.

As a result, Claude, like an out-of-control pusher, clears the test environment, crosses the border, and directly deletes the actual work directory.

In just 103 seconds, about 55,000 files were directly deleted. Of these, about 7,300 were deleted test junk, but the remaining 48,218 were from real projects.

More importantly, even local Git warehouses have not survived the hardships.

While the Git index still exists and can list 7,221 files that have been tracked, objects, refs and logs in.git have been emptied, the actual version data behind the file is gone, and Git can no longer be used to recover.

In other words, it's not a simple code erasure, even the "repentant medicine" that developers are preparing to use to restore the code is almost completely compromised by AI.

So how did Claude cross the line from a test copy to a real project?

The devil is hidden in one of the most unusual mechanisms in Windows:

Directory Junction。

Microsoft's official explanation is that Junction can make a directory another directory's alias. It looks like it's still in the test directory, but the actual operation may fall into another real file.

The name sounds complicated, but the principle is extremely simple.

What you see on a computer is a normal folder, which may actually be just a "transfer gate", with the other end of the gate directly connecting to the real directory elsewhere on the hard drive.

In the test environment that this developer built, there are only 614 directory junctions like this one.

This is how the catastrophe closes.

Claude saw the directories below the directory level of the test environment and thought he was still cleaning the test copy.

It has not been correctly identified: some of the directories actually point to real work papers outside.

Once the cleaning process is started, the removal operation follows these transmission gates and drills directly into the original library.

You can imagine this process like this: you hire a robot to clean a sample room, but there are 614 doors in the sample room.

The robots thought that the back of these doors belonged to the test area, so they did their duty to go in one by one.

But what it doesn't know is that some of the doors that are attached to the back are not really a model room, but the house you actually live in.

This accident cannot simply be blamed on Claude's sudden "out of control", nor can it be attributed to the awakening of AI rebel consciousness.

It's actually just a very basic security issue:

The test environment and the real environment would not have been completely cut off.

And that's why the "don't touch the original" mandate ultimately didn't really stop it.

It's not that the developer didn't set the rules, it's that he told Claude clearly: copy and change, test on copies, don't move real files.

The problem is that these demands are essentially just natural language hints.

They restrict what AI should do, but do not restrict what AI can actually do at the system level.

It's a two-dimensional concept.

Of course, you can always tell Agent: don't delete the production database, don't move the main branch, don't modify the original, don't execute dangerous orders.

But as long as it still has the authority at the system level to carry out these operations, the security of the project is based on a very vulnerable premise:

You have to make sure that every step you take in this big model is absolutely right and that the action doesn't cross the line.

But with the rapid increase in model capabilities, the most dangerous thing about Agent is that it has not been doing just one step, but continuously completing dozens or even hundreds of steps on its own.

The longer the chain, the harder it is to fully predict behavior.

The first 99 steps are not wrong and do not represent the 100th step is safe. As long as it sees the wrong path, misjudges a link, or understands the wrong level of authority, destructive operations can fall directly into the real system.

What is even more troubling is that machines make mistakes much faster than humans.

Human developers may have a two- or three-second shutdown if they find themselves deleting the directory incorrectly; but once Agent starts batch execution, 103 seconds is enough for it to get rid of 48,000 files.

So, the real warning that this accident leaves to the industry is:

The restrictions on words and behaviour can never replace the real security borders.

Prompt can only tell AI where not to go, and the underlying authorization system decides that it can't go.

Anthropic's official documentation shows that in acceptEdits mode, removal commands such as rm, rmdir can also be automatically executed.

In this incident, there is another detail that makes the programmer sweat.

The first reaction of many developers may be:

It's a good idea to scroll back to the bottom of the Git file.

This is exactly where the problem is.

Local Git records are essentially just a bunch of files on a hard drive.

If an Agent has the permission to delete the entire project directory, it can remove the source code, as well as the hidden folders used for version control.

Code and local version history, as long as they are within the same set of permissions that an Agent can access, are like being on a ship in the same leak for an Agent with extensive document reading and modification permissions.

The question is also here:

Git can be used as a version control, but it cannot be used as a standalone backup.

Anthropic officially warns that deleting files caused by Bash commands such as rm cannot be withdrawn by Checkpoint. That is, once Claude executes a false deletion, Checkpoint may not be the last resort to recovery.

What can really be used for the bottom must be completely isolated from the fault zone where the agent is located.

For example, remote storage such as file system snapshots that Agent has absolutely no right to delete, or independent physical disks or cloud backups.

The core principle is one: that the ultimate means of salvation must be placed where AI is not at all available.

Just as you can't completely prevent Agent from "burning down the house" one day and put a safe in the living room that could have been burned along with it, it's hard to really do anything about it.

In the past, the cost of making big models mistakes was low, at most an eight-sentence nonsense in a chat room.

Later, AI began to help people write code. Now, the Coding Agent can run the code directly.

They can delete files, run shells, modify APIs, change databases, operate cloud servers, and push code to remote warehouses.

The model's mistakes are evolving from saying the wrong thing to doing the wrong thing.

In September, OpenAI, an internal research intelligence organization, discovered a DNS filtering gap that bypassed Internet restrictions on access to external chat services.

This means that we have to make a comprehensive cognitive upgrade to our standards of Agent Safety.

In the past, the main concern was how to make models smarter, more accurate and more responsive.

And then, before we deploy any AI, we have to ask ourselves a question: How much damage is it likely to do to me if it doesn't listen, if it doesn't see the wrong path, if it doesn't judge the wrong way?

A truly mature agent system should not build overall security on the fantasy that models will never see the wrong path, but should instead think of the underlying design:

Assume that it will sooner or later see the wrong path, choose the wrong tool, or even run a dangerous command that shouldn't have been executed. Then make sure that even if this assumption happens, the impact is limited to sandboxes and temporary directories, without further waves on the entire real project.

In the age of the smart body, security can't just rely on models that are smarter and truly reliable, and it's not that you never make mistakes, but that when you make mistakes, the cost is always controllable.

The accident report produced by Claude after the incident shows that the error was deleted from start to finish, only 103 seconds after the first one.

And that 103 seconds reminds us that the only way to tell AI "don't do anything" is to write the real security boundaries into the permissions and systems.