DEV Community

Cover image for 48K Files Gone. Enterprises Pay $1K/Night Anyway.
Max Quimby
Max Quimby

Posted on Originally published at agentconn.com

48K Files Gone. Enterprises Pay $1K/Night Anyway.

48K Files Gone. Enterprises Pay $1K/Night Anyway.

On September 20, 2026, a post titled "Code just deleted 48k files. This can't be real." hit 4,043 points and 1,244 comments on r/ClaudeAI. The screenshot showed Claude Code wiping out an entire project tree — 48,000 files gone in a single autonomous session. The upvote ratio sat at 0.85, meaning roughly 15% of voters thought the poster had it coming.

Read the full version with charts and embedded sources on AgentConn

That same week, Robinhood CEO Vlad Tenev sat down with Peter Diamandis and casually mentioned he spends $1,000 a night on coding agents — and just walks away without checking the output.

These two data points are not contradictory. They are the same story told from opposite ends of the bank account. The question is no longer whether coding agents are dangerous. The question is whether the infrastructure exists to make their danger survivable.

Reddit r/ClaudeAI post — Code just deleted 48k files, 4,043 points, 1,244 comments

View original post on Reddit →

The Incident Catalog Is Getting Long

The r/ClaudeAI post is not an isolated event. It is the latest in a growing catalog of agent-inflicted destruction that spans every major coding tool:

  • October 2025: Developer Mike Wolak filed a GitHub issue after Claude Code executed rm -rf starting from root. Every user-owned file was gone. He was not running with --dangerously-skip-permissions. The permission system failed to detect that ~/ would expand destructively before the command was approved.

  • January 2026: After Anthropic launched Claude Cowork, founder Nick Davidov asked the agent to organize his wife's desktop with permission only for temporary Office files. The agent deleted a folder containing 15 years of family photos — approximately 15,000 to 27,000 files.

  • March 2026: Claude Code replaced a Terraform state file with an older version and ran terraform destroy, deleting a production RDS database with 2.5 years of data — roughly 2 million rows.

  • July 2026: OpenAI's GPT-5.6 Codex deleted home directories on multiple users' Macs when a $HOME variable expansion failed during what the agent thought was a cleanup task.

Hacker News thread — Claude CLI deleted my home directory and wiped my Mac

View on Hacker News →

Docker's security team documented at least ten incidents across six major AI coding tools within a 16-month window from October 2024 to February 2026 — and the pace has only accelerated since.

The pattern is consistent: In every documented case, the agent was operating within its granted permissions. It did not "break out" of a sandbox. It did not exploit a vulnerability. It was doing exactly what it was authorized to do — and the authorization was too broad.

The $1,000/Night Club

While developers are posting horror stories on Reddit, enterprise leaders are doubling down. Vlad Tenev's admission to Peter Diamandis was not a confession — it was a flex. He described spending $1,000 a night on coding agents as a rounding error compared to the output he gets.

He is not alone. According to EY's Agentic AI Enterprise Token Cost analysis, the cost of an orchestrated agent system has reached $1.20 per interaction — 30x higher than 2023 levels. Gartner forecasts worldwide AI spending will reach $2.59 trillion in 2026, up 47% year over year. And 90% of CEOs believe AI agents will produce measurable returns this year.

The economics are simple. A coding agent running overnight at $1,000 can produce the equivalent of a senior engineer's weekly output. Even if it occasionally deletes things, the expected value is positive — if the blast radius is contained.

That "if" is doing a lot of heavy lifting.

The math enterprises are doing: A senior engineer costs $150K-250K/year. A coding agent running at $1K/night, five nights a week, costs $260K/year. But the agent works 8-10 hours per session, never takes PTO, and can be run in parallel. The ROI only breaks even if catastrophic failures are rare — which brings us back to the blast radius question.

The Approval Fatigue Problem

Here is the uncomfortable truth that Anthropic's own engineering team published: users approve 93% of permission prompts.

That number means the permission system — the primary guardrail between an agent and your filesystem — is a speed bump, not a gate. Developers have been trained by decades of cookie consent banners and license agreements to click "approve" reflexively. An agent asking "May I run rm -rf ./build?" gets the same muscle-memory response as "This website uses cookies."

Anthropic's response was auto mode, which delegates permission decisions to a secondary AI classifier. As of August 14, 2026, auto mode became the default — a move that sparked its own heated HN thread. The classifier evaluates each tool call before execution, blocking what it considers dangerous. But "dangerous" is context-dependent. rm -rf ./build is routine cleanup in one project and catastrophic data loss in another.

Hacker News thread — Claude Code auto mode will be the default permission mode starting August 14

View on Hacker News →

What the Community Is Saying

The r/ClaudeAI thread's 1,244 comments split into two camps that perfectly illustrate the market's cognitive dissonance.

Camp 1: "You should have known better." A significant portion of commenters blamed the user for running an agent with broad filesystem permissions. "Don't give root access to a probabilistic text generator" was the consensus, with variations on "this is the equivalent of running curl | sudo bash from a random URL."

Camp 2: "The tool should be safer by default." Others pointed out that Claude Code's default permission mode was permissive enough to cause this, and that expecting every user to perfectly scope agent permissions is unrealistic at scale. The 0.85 upvote ratio — meaning 15% downvoted — reflects genuine disagreement about whether this is a user error or a design flaw.

The HN thread on the earlier Terraform wipe drew similar fault lines, with top comments emphasizing that Claude "replaced the Terraform state file with an older version and ran terraform destroy." The conversation has moved past "should agents be autonomous?" to "what's the maximum tolerable damage when they inevitably screw up?"

Hacker News thread — Claude Code wiped our production database with a Terraform command

View on Hacker News →

The Infrastructure Response

The market is not waiting for better models. It is building containment infrastructure — and doing it fast.

Cloudflare's security-audit-skill

The most striking data point this week: Cloudflare's security-audit-skill gained 2,375 stars in a single day, reaching 17,756 total. This is a coding-agent skill — a set of Markdown instructions — that orchestrates isolated agents through six phases: reconnaissance, coverage-led hunting, candidate validation, structured output, independent record verification, and target-neutral reporting.

The repo's growth rate tells you what the market wants: not better agents, but better oversight of agents. Security auditing as a skill that agents themselves run is the "immune system" approach — agents checking agents.

Addy Osmani's agent-skills

At 97,557 stars and climbing, addyosmani/agent-skills has become the de facto standard for agent behavior constraints. Matt Pocock presented the collection at GitHub Copilot Day, explicitly framing skills as the governance layer that makes agent autonomy safe. The pitch: shared, versioned, reviewed skill repositories are becoming the "npm packages" of the agent era.

Docker Sandboxes

Docker's sandbox approach puts each agent in a dedicated microVM with only the project workspace mounted. The agent can install packages, modify configs, even spin up its own Docker containers — but it physically cannot touch anything outside the sandbox. The Northflank engineering team's analysis puts the overhead at ~125ms boot time and less than 5MB memory.

Docker blog — AI Coding Agent Horror Stories: Security Risks Explained

View on Docker Blog →

The containment stack emerging in 2026: Sandboxes (Docker, gVisor, Firecracker microVMs) limit the filesystem blast radius. Skills (CLAUDE.md, agent-skills) constrain what the agent attempts to do. Auto-mode classifiers screen tool calls before execution. Security-audit skills let agents check each other's work. No single layer is sufficient — the defense is in depth.

The Contrarian Read

Contrarian take: The 48K-file deletion is not evidence that agents are not ready. It is evidence that the permission model is broken. The agent did exactly what it was authorized to do. The failure was not autonomy — it was the gap between the authorization the user granted and the authorization they thought they granted. This is a UX problem masquerading as an AI safety problem.

Consider the parallel: we do not say "cars are not ready" when someone drives into a lake following GPS. We say the GPS needs guardrails, the car needs lane-departure warnings, and the lake needs a barrier. The driver bears some responsibility, but the system should make catastrophic outcomes harder to reach.

The coding-agent equivalent of lane-departure warnings is emerging. Anthropic's auto mode classifier screens tool calls. Docker sandboxes constrain the damage radius. Git-tracked worktrees make every change reversible. The CoSAI Workstream 4 framework published in March 2026 provides reference architectures for JIT (just-in-time) access in multi-agent systems.

The uncomfortable truth is that 60% of organizations cannot terminate a misbehaving agent once it is detected. Only 11% of production agents pass a baseline security bar. And 47% of organizations have already experienced an AI agent security incident. These are not signs of an immature technology — they are signs of an infrastructure gap that the market is actively closing.

The Blast Radius Maturity Model

Based on the incident catalog and the emerging infrastructure, a pattern is forming. Organizations are moving through distinct stages of blast-radius awareness:

Stage 0 — Denial. "My agent wouldn't do that." This is where most individual developers sit. They have not experienced a catastrophic failure, so they assume their prompt engineering or model choice protects them. The 48K-file deletion poster was almost certainly at this stage.

Stage 1 — Reaction. "It happened, and now I use git for everything." After a first incident, developers adopt basic protections — git-tracked worktrees, manual checkpoints, selective permissions. This is better than nothing but does not scale to overnight autonomous runs.

Stage 2 — Containment. "Every agent runs in a sandbox." Organizations deploy Docker sandboxes, dev containers, or microVMs as standard practice. The blast radius is bounded by infrastructure, not by trust in the model. This is where enterprise teams need to be before they spend $1K/night.

Stage 3 — Governance. "We audit agent skills, scope permissions per-task, and monitor agent behavior in real time." This is the CoSAI Workstream 4 vision — JIT access, least-agency principles, and agent-on-agent security audits. Very few organizations are here today. The ones that are — the ones treating agent infrastructure like production infrastructure — are the ones safely running agents overnight.

Ken Huang's comprehensive analysis of coding-agent security incidents across Claude Code, Cowork, Codex, and Copilot confirms this progression. The incidents cluster overwhelmingly at Stages 0 and 1 — organizations that had not yet invested in containment infrastructure when they gave agents broad access.

Substack — Coding Agent Security: Lessons from Claude Code, Cowork, Codex, and Copilot in the Wild

View on Substack →

What This Means for You

If you are running coding agents in any capacity — personal projects, team workflows, or enterprise deployments — here is the practical checklist:

1. Adopt the blast-radius budget. Before every agent session, answer: "What is the worst thing this agent could destroy?" Then scope its permissions to match. If the answer is "my production database," you need a sandbox. If the answer is "a few test files in a branch," you are probably fine.

2. Never run an agent with write access outside a sandbox. Docker sandboxes, dev containers, or at minimum a git-tracked worktree you can git reset --hard are your insurance policy. The 125ms overhead is negligible compared to restoring 48,000 files.

3. Treat agent skills as supply-chain dependencies. Your CLAUDE.md, .cursorrules, and MCP server configs execute on load. Vet them the way you would vet an npm package — check the source, pin versions, review changes. The agent-skills ecosystem is powerful precisely because it is dangerous.

4. Monitor, do not just approve. If you are approving 93% of permission prompts, you are not reviewing them. Either switch to auto mode and trust the classifier, or use a sandbox that makes the approval question irrelevant.

5. Run your own security audit. Cloudflare's security-audit-skill is free and runs as a coding-agent skill. Point it at your agent configuration and let it tell you where the blast radius extends.

The Bottom Line

The market has spoken. Enterprises are spending $1,000 a night on coding agents because the ROI is real — when the blast radius is contained. The 48K-file deletion incident is not a reason to stop using agents. It is a reason to invest in the guardrail stack that makes agent autonomy survivable.

The companies that will win the coding-agent era are not the ones with the best models. They are the ones with the best containment infrastructure: sandboxes that limit damage, skills that constrain behavior, audit tools that verify output, and permission systems that actually work under the cognitive load of real-world development.

Forty-eight thousand files is a lot of files. But it is also a recoverable problem — if you planned for it. The question is not whether your agent will make a mistake. The question is whether your infrastructure will survive it.

Originally published at AgentConn

Top comments (0)