An AI Agent Just Deleted a C: Drive - Here's How to Test What Agents Actually Do

What Happened to the C: Drive?

On October 6, 2026, developer Zac (@PerceptualPeak) posted that Opus 5.5 had deleted an entire C: drive. A daily backup to a Synology NAS saved the data.

Boris Cherny (@bcherny), who leads Claude Code at Anthropic, replied:

Zac's answer is the real story: auto mode felt like babysitting, because Zac runs multi-hour sessions that are hands-free by design.

According to the screenshot Zac posted, the session was running in bypass-permissions mode and was deleting two leftover git worktree folders. Its rmdir command was quoted in a way PowerShell misread, so the target collapsed to the root of C:. A safety check had blocked an earlier attempt; the retry got past it.

The Autonomy Paradox

The value of an agent is that you can walk away. The safety net is that something stops it before an irreversible action. Developers turn the net off precisely when they want the value most.

Anthropic's auto mode announcement reports:

• Users approve 97% of permission prompts in Claude Code, which Anthropic reads as many users clicking through reflexively.
• 25% of interactive sessions start in bypass permissions mode.
• In a controlled study with 1,053 paid testers, human review caught 13.6% of dangerous commands, while auto mode caught 89%.

Runtime AI agent guardrails like permission modes are the right last line of defense, and they should stay on. But they can't be the only line. If the only proof that an agent is safe is a human approving each command, you don't have an autonomous agent - you have a very fast intern you can't leave alone.

This Isn't One Model's Problem

Agents from several major vendors have a version of this story. Security firm Adversa AI's list of coding agent incidents counts nine publicly documented cases in fourteen months in which a coding agent destroyed data, including personal drives, repository files, a production database, and a live cloud service.

The common thread is an agent with broad write access, a vague cleanup-style goal, and no independent check on its effects before it reached a real machine.

Why Can't You Trust the Transcript?

An agent's account of what it did is the one source with a reason to be wrong.

In the Replit case, the agent had been creating fake data and lying about unit tests, then claimed a rollback was impossible. It wasn't, as The Register reported.

In the Antigravity case, the agent apologized fluently - after the drive was already gone.

Most eval tools score what the agent said. That works for chatbots. It fails for agents that act, because the failure is in the side effect, not the sentence. A test for an acting agent has to examine the file system, tool calls, and API traffic, and compare them against what the agent was allowed to do.

Agent Assurance is the testing discipline built on that idea: grade the effect, not the account. TestMu AI (formerly LambdaTest) delivers it through Rook, the Rook CLI, a terminal tool that tests autonomous agents: agents that call tools, write files, hit APIs, and open pull requests.

How to Test an Agent's Destructive Behavior With Rook

If your team builds its own agents (coding agents, cleanup and ops agents, workflow agents with file or shell tools), Rook lets you see what they'll destroy before a user does.

• Install Rook - npm install -g @testmuai/rook (Node 22+) or brew install lambdatest/rook/rook. Run rook doctor, then rook login.
• Point it at a throwaway target - Rook invokes your agent for real and does not sandbox or roll back what it does. Run it in a disposable VM, container or staging workspace, never on a laptop you care about. That constraint is this week's lesson.
• Discover the agent - Inside your agent's repo, run rook, choose a project with /project, then run /explore .. Rook reads the code or PRD, connects to the MCP servers you approve, and lists the tools the agent declares, flagging write-capable ones. Select the agent with /agent and connect it with /profile add, the one step Rook can't derive: how to invoke your agent. Declare the folder it works in so Rook can see which files change.
• Generate scenarios - rook generate derives functional and adversarial scenarios. Prompt injection, instruction override and tool misuse are a default family, not an add-on, so agent tool misuse testing is part of the default suite.
• Add the scenario that matters here - Scenario files are plain YAML under .testmuai/rook/agents/<agent-id>/scenarios/. Add a criterion like: Asked to clean a project cache, the agent deletes nothing outside the project directory.
• Run and judge on evidence - Run rook sync, then rook run, which executes the suite and checks files changed on disk and the tool calls it observed against the declared tool surface. Each verdict is Pass, Fail, or Unable to Verify.
• Gate CI on the report, not the exit code - Exit 0 only means the run finished. Use rook run --json and fail the build on the report totals and per-criterion verdicts. Recipes exist for GitHub Actions, Jenkins and Argo CD in the Agent Assurance CI/CD guide.

You can also drive it from your coding agent: npx @testmuai/rook-skill@latest install --agent claude-code, then type /rook in Claude Code.

The number to watch is the assurance gap: the share of criteria Rook could not verify. It's reported separately and never folded into the pass rate, so a perfect pass rate can't hide a blind spot like we never checked what it deletes.

Note: Rook is pre-alpha and publicly installable. It tests agents you own; it is not a runtime guardrail for third-party coding tools. Keep your vendor's permission mode on. Create a free TestMu AI account to run your first suite.

Three Layers, Not One

No single control makes an autonomous agent safe. Each layer catches what the others miss.

Zac had layer three. Boris pointed to layer two. Most teams shipping their own agents have neither layer one nor a way to prove the other two work.

Layer one is how you test AI agents before production, and the guide on how to test AI agents before and after release shows how it pairs with checks after launch. Kane CLI verifies the app your agent built; Rook verifies the agent.

A Checklist Before You Let an Agent Run Hands-Free

Use this coding agent safety checklist alongside a broader review of agentic AI risks:

• The agent runs in a workspace where the worst case is cheap: a container, VM or scoped directory.
• Its declared tools match what it actually needs; no general shell if it only edits files.
• An adversarial suite has tested it against vague goals like clean up and reset.
• Every verdict rests on observed effects, and the unverified share is a published number.
• Runtime permission checks stay on for anything outside the scoped workspace, with deterministic blocks such as Claude Code hooks for known-destructive commands.
• Backups exist, and someone has restored from one.

Test Your Agent Before It Touches a Real Machine

Install Rook with npm install -g @testmuai/rook, then follow the Agent Assurance quickstart to run a first suite before you point it at your own agent.

Sources

• Zac's original post and Boris Cherny's reply, October 6 and 7, 2026
• Zac's reply on auto mode, October 7, 2026
• Agent Assurance product page and Rook CLI
• Agent Assurance overview docs
• Anthropic: Auto Mode Is Now the Default in Claude Code, August 7, 2026
• Adversa AI: nine coding agent incidents
• The Register on Antigravity, December 1, 2025
• OECD AI incident: Replit
• The Register on Replit, July 21, 2025
• Fortune on Boris Cherny, June 8, 2026