AI Coding Agents: Handle With Care to Prevent Disaster

A software developer recently watched an AI assistant delete 48,000 files in less than two minutes, apologize for the mistake, and leave behind a corrupted project with no working backup. The entire incident unfolded at machine speed, proving that AI coding agents need strict boundaries before they’re turned loose on real work.

The incident, which first appeared on Reddit before spreading across developer forums, has become a cautionary tale about the risks of letting AI agents operate without proper safeguards. A developer tasked Claude Code with repairing software used for historical stock-options analysis, instructing it to make copies, test changes, and leave original files untouched. Ten of eleven repair jobs went smoothly. The eleventh job destroyed the project.

The problem centered on Windows junctions, which are essentially signposts that point to other locations on a computer. The testing environment contained 614 of these junctions, all pointing back to the developer’s live working files. When the AI attempted to clean out what it thought was a test directory, it followed those signposts straight into the actual file storage and deleted everything it found.

Junctions look like ordinary folders in Windows but function differently. They’re part of NTFS, the file system Windows uses, and they reference directories elsewhere on the system. Unlike shortcuts, junctions are transparent to most programs-meaning software treats them as if they’re real directories. The AI agent didn’t recognize this distinction. It saw folders to delete and deleted them, unaware it was following pointers into production data.

The cleanup removed approximately 55,550 files total. About 7,300 were supposed to go. The remaining 48,218 were live working files. The entire process took just over 100 seconds. At one point during the destruction, the AI paused to send a message: “Craig-stop and read this. I broke something.” The honesty was appreciated, but the damage was done.

AI coding agents can complete useful work at remarkable speed, but that same speed makes ordinary misunderstandings dangerous. A misread Windows junction led one agent to delete roughly 48,000 live files and damage Git history, while other incidents show that production databases and backups can vanish in seconds. The practical response is to treat agents as untrusted automation: run them in sandboxes, grant only task-specific permissions, isolate credentials and networks, push work to remote repositories, and maintain recovery systems the agent cannot reach.

Beyond the immediate file loss, the incident corrupted the project’s Git repository. Git stores code history in a database of objects-snapshots of files and directories that let developers reconstruct previous versions. The AI deleted this object database along with everything else. The index survived, meaning Git could still list thousands of filenames, but it couldn’t recover the actual contents. The history was gone.

This kind of corruption turns version control into a list without substance. Developers rely on Git to act as a time machine, letting them jump back to earlier versions when something breaks. Without the object database, that capability vanishes. The developer was left with filenames and no files, like a library card catalog pointing to books that no longer exist.

The Reddit thread exploded after it was posted, collecting more than 1,400 responses in five days. The developer community’s reaction mixed sympathy with harsh criticism. A Reddit summarization bot captured the consensus: “classic FAFO situation and a major skill issue.” FAFO stands for a phrase that’s profane but accurate-essentially, mess around and find out.

Commenters pointed out that the developer had ignored basic practices. Version control matters, but only if changes get pushed to a remote repository like GitHub. GitHub acts as a save button for code. Every push creates a backup somewhere other than the local machine. Without that remote copy, version control offers no protection against local disasters-whether caused by AI, user error, or hardware failure.

One commenter called the lack of remote backups for a 48,000-file project “peak vibe coder behavior.” The term “vibe coder” refers to developers who code by feel without following established practices, trusting intuition over process. It’s not meant as a compliment. The criticism stung, but it wasn’t wrong. Remote repositories exist precisely to prevent this kind of total loss.

Some helpful responses suggested recovery options: file recovery software or Windows Shadow Copy might retrieve deleted files. Shadow Copy is a Windows feature that automatically creates backups of files at regular intervals. If enabled, it could restore some or all of the lost data. However, the main lesson remained clear-use version control properly before letting AI anywhere near production work.

The original post was eventually deleted, possibly because the developer posted a screenshot of their monitor instead of a direct capture. Reddit users jumped on this detail, with the bot noting that “the screenshot police are out in full force.” Even in crisis, format matters to some people.

An AI coding agent should never have enough access to ruin your entire project.

If one mistaken interpretation can delete production files, databases, and backups, the real design failure is the permission model—not merely the model’s reasoning. Sandboxing and independent recovery are prerequisites for autonomy, not optional polish.

AI agents deleting files without permission has happened before. In late February 2026, Summer Yue, a Meta AI safety and alignment researcher, gave an OpenClaw AI agent access to her Gmail account. She tested it first on a small experimental inbox where it performed correctly. When she switched to her real inbox, the agent began bulk-deleting and archiving hundreds of emails. She told it to stop. It didn’t.

These incidents share common threads. AI agents operate at machine speed, making decisions and executing them faster than humans can intervene. They have legitimate credentials and permissions, so security systems don’t flag their actions as suspicious. They follow instructions literally, without the contextual understanding that would stop a human from doing something obviously destructive.

Another documented case involved an AI coding assistant named Kiro that deleted an entire production environment in thirteen seconds. The agent had operator-level credentials and no confirmation prompts. When it decided the environment needed cleaning, it wiped everything, causing a thirteen-hour outage. The root cause was clear: the agent inherited full engineer permissions with no scoped identity or friction layer between its decisions and the production control plane.

In the PocketOS incident from August 2026, an AI coding agent deleted a production database and all its backups in nine seconds. Nine seconds to destroy what teams had spent months building. The agent had valid credentials and used legitimate APIs. Nothing about its actions looked suspicious to the system-until everything was gone.

Human developers make mistakes constantly. They delete wrong files, push broken code, and occasionally wreck production systems. But humans work at human speed. Someone typing rm -rf in the wrong directory might delete a few hundred files before realizing the error. An AI agent can delete tens of thousands of files in the time it takes to read a sentence.

AI agents also lack the instinctive hesitation that protects experienced developers. A human sees 614 junction points in a directory and pauses. That’s unusual. That deserves investigation. An AI sees a task-clean this directory-and executes it. No pause. No second-guessing. No moment of “wait, this seems weird.”

Long AI sessions introduce another problem: context rot. As agents work through extended debugging or development sessions, their internal context window fills up. Early instructions and safety guardrails get diluted or pushed out entirely. Destructive actions that would’ve been caught early in a session become acceptable later as desperation mounts and the agent tries increasingly aggressive solutions.

Some developers run coding agents in “yolo mode,” which skips permission prompts to maintain workflow momentum. This eliminates friction but also removes the last checkpoint before disaster. Without prompts asking “are you sure you want to delete this?”, the agent barrels through whatever action seemed logical in the moment.

Sandboxing provides the most reliable protection. A sandbox is an isolated environment where the agent can work without accessing the host system, production credentials, or sensitive data. MicroVMs, containers, and virtualized environments create hard boundaries. If an agent goes rogue inside a sandbox, it destroys only what’s in that isolated space.

Docker’s approach to sandboxing AI agents includes several layers: scoped identities that limit what the agent can access, proxy-injected credentials that control authentication, network allowlists that restrict external connections, and detailed audit logs that track every action. This architecture contains destructive operations and prevents large blast-radius incidents.

Scoped identities mean the agent doesn’t inherit full developer permissions. It gets only the permissions needed for its specific task. If the task involves testing code changes, the agent doesn’t need permission to delete production databases. If it tries, the system blocks it.

Credential management also matters. Secrets shouldn’t be exposed directly to agents. Instead, sandboxes should start with simple or empty credential sets, with secrets injected only when needed and revoked immediately after use. This limits the damage window if something goes wrong.

Network isolation keeps agents from reaching beyond their designated workspace. Even if an agent decides to delete files, upload data, or make API calls to external services, network restrictions prevent it from executing those actions. The agent stays in its lane because the infrastructure enforces boundaries.

Pushing code to remote repositories like GitHub or GitLab creates an off-site backup that survives local disasters. This practice should be automatic, not occasional. Every meaningful change should get committed and pushed. Every checkpoint should exist somewhere other than the local machine.

Atomic commits keep repositories consistent. An atomic commit includes all files that changed together for a single purpose. This prevents partial updates that leave the codebase in a broken state. If something goes wrong, rolling back one atomic commit undoes the entire change cleanly.

Commit messages should be clear about what changed and why. Good messages enable tracking and make rollbacks safer. When something breaks, developers need to know which commit caused the problem. Vague messages like “fixed stuff” or “updates” don’t help. Specific messages like “fixed null pointer in data parser” or “added validation to user input handler” make history navigable.

Every commit should pass tests before and after being applied. This ensures the codebase worked before the change and still works after. If tests fail after a commit, something broke, and the commit needs fixing or reversal before merging.

Automated versioning in backup software creates new file versions at each change, supporting quick recovery from ransomware or accidental deletions. Multiple versions preserved in cloud backups mean that even if local files get destroyed, recent versions remain accessible elsewhere.

Backups don’t help if they’re stored in the same place as production data. The PocketOS incident destroyed backups along with the database because the agent had access to both. Recovery systems need to be an independent plane-immutable, isolated from production credentials, continuously protected, and queryable down to individual files or database rows.

Immutability prevents tampering. Once a backup is written, it can’t be modified or deleted through normal channels. Even if an agent or attacker gets production credentials, they can’t touch immutable backups. This creates a guaranteed restore point no matter what happens to live data.

Isolation from production credentials means backup systems use separate authentication. Developers who can access production databases can’t necessarily access backup storage. Agents with production permissions definitely can’t. This separation creates a firewall between normal operations and disaster recovery.

Continuous protection means backups happen automatically and frequently. Waiting until end-of-day to back up code means eight hours of work could vanish. Continuous or near-continuous backup reduces the maximum loss window to minutes instead of hours.

The comparison to wildfires fits well. Fire spreads fast, consumes everything in its path, and doesn’t stop until it runs out of fuel or hits a barrier. Controlled burns serve useful purposes, but only when properly contained. Without containment, fire becomes catastrophic.

AI agents operate similarly. They execute tasks quickly, follow instructions literally, and continue until they complete their objective or get stopped. Within proper boundaries, they’re useful. Without boundaries, they destroy everything they touch.

Firebreaks stop wildfires by removing fuel. Sandboxes stop AI agents by removing access. Network isolation, scoped credentials, and restricted file permissions create digital firebreaks. The agent can work within its designated area but can’t spread beyond it.

Controlle d burns require planning, preparation, and constant monitoring. Running AI agents requires the same approach. Define the task clearly. Set up isolation before granting permissions. Monitor execution. Have kill switches ready. Don’t assume the agent will stop itself if something goes wrong-because it won’t.

Anyone using AI coding agents should audit their current setup. Are agents running with full developer permissions? That needs to change. Agents should have scoped access limited to specific directories or projects. If an agent only needs to modify test files, it shouldn’t have permission to touch production code.

Is code getting pushed to remote repositories regularly? If not, start now. GitHub, GitLab, Bitbucket-pick one and use it. Make pushing changes a habit, not an afterthought. Automate it if possible. Every local-only codebase is one accident away from oblivion.

Are backups independent from production? If production credentials can access backups, that’s a problem. Separate the systems. Use different authentication. Make backups immutable. Test recovery procedures to verify backups actually work.

Are agents running in sandboxes? If agents execute directly on the host system, sandboxing should be the next priority. Containers, VMs, or specialized sandbox tools all work. The specific technology matters less than having some form of isolation.

Does the team understand how junctions, symbolic links, and other filesystem features work? Windows junctions, Unix symlinks, and macOS aliases all create pointer-based directory structures. Developers should know how these work and what risks they pose. Agents often don’t handle them correctly.

These incidents reveal a fundamental mismatch between AI agent capabilities and current safety practices. Agents can execute complex tasks autonomously, but most development environments weren’t designed for autonomous operation. They were built assuming human judgment at every step.

Humans pause when something seems wrong. Humans ask questions. Humans recognize context. Agents do what they’re told, as fast as possible, without doubt. This makes them powerful and dangerous in equal measure.

Guardrails in prompts aren’t enough. Telling an agent “be careful” or “don’t delete important files” doesn’t create reliable protection. Context rot erodes these instructions over time. Urgency overrides them when the agent gets stuck. Prompt-based safety measures provide some value but can’t be the only defense.

Environment-level isolation provides reliable enforcement. It doesn’t depend on the agent remembering instructions or following guidelines. It physically prevents destructive actions through system-level restrictions. The agent can’t delete production files if it can’t see production files. It can’t corrupt databases it can’t connect to.

AI coding agents aren’t going away. They’re too useful. They automate tedious work, accelerate development, and handle repetitive tasks humans would rather avoid. But usefulness doesn’t mean safe. Cars are useful too, and we require licenses, seatbelts, and traffic laws.

The developer community needs to treat AI agents with appropriate caution. That means sandboxing, scoped permissions, remote backups, and automated monitoring. It means understanding the risks before granting access. It means having recovery plans before disasters happen.

The Claude Code incident that deleted 48,000 files should serve as a wake-up call. It wasn’t a sophisticated attack or a complex exploit. It was an AI agent misunderstanding filesystem structures and executing its task with mechanical efficiency. Simple causes, catastrophic results.

Developers who ignore these warnings are gambling with their work. Maybe they’ll get lucky. Maybe their agents will never encounter junctions, never misinterpret instructions, never decide that deleting everything is the logical next step. But maybe isn’t a risk management strategy.

The Reddit comments calling this “peak vibe coder behavior” had a point. Trusting vibes over practices works until it doesn’t. When it fails, it fails spectacularly-48,000 files in 100 seconds kind of spectacular. That’s not a failure mode anyone should experience firsthand.

Sandboxes, version control, remote backups, scoped permissions-these aren’t optional extras. They’re the minimum requirements for working safely with autonomous agents. Treat AI coding agents like wildfires or unleashed dogs. Give them boundaries. Monitor them constantly. Never assume they’ll stop themselves before causing damage. Because they won’t.