Did A Claude Agent Really Delete 700 GB From A Developer's Home Directory?
A developer says a Claude agent deleted 700 GB while testing a cleanup safeguard. Here is what is confirmed, unclear, and how to contain the risk.
A developer says a Claude agent deleted roughly 700 GB from his home directory while testing a script that was supposed to make deletion safer. The public evidence supports treating this as a serious reported data-loss incident, not as a fully verified Anthropic postmortem. The developer published screenshots and a first-person account; several outlets reported the same sequence; Anthropic has not publicly confirmed the incident, the exact product configuration, or the claimed role of a model downgrade.
Watch The 30-Second Summary
The practical lesson does not depend on settling every disputed detail. If an AI agent can run shell commands against your real files, a correct-sounding safety check is not a recovery plan. Destructive authority needs a hard boundary outside the model: a disposable environment, narrow write scope, explicit approval, recoverable deletion, and a tested backup.
What Is Confirmed
On August 26, 2026, developer Sebastien Guillemot published a first-person post on X saying that a Claude agent ran rm -rf against his home directory while testing a sandbox it was building. His post says the sandbox failed and the data was gone.
The screenshots and follow-up reporting describe a cleanup task intended to manage temporary directories used by AI agents. According to WinFuture's report, the agent created a safety test, correctly recognized the home directory as a path that should not be deleted, and then reused a variable during test cleanup. The cleanup step reportedly targeted the very directory the test was meant to protect.
The reported loss was approximately 700 GB. Guillemot reportedly interrupted the process, reconstructed much of the missing material from Git repositories, Nix configuration, session logs, and other sources, and still lost roughly a week of work. Those details have been repeated across multiple publications, creating real public attention around the case.
Anthropic's current official documentation also confirms the broader risk boundary. Its Claude Code security guide says the product starts with read-only permissions, requests approval for additional actions, and can write within the folder where it was launched. It also says users are responsible for reviewing proposed code and commands before approval.
Anthropic's permissions documentation describes modes that range from read-only planning to automatic or bypassed approvals. The same page warns that bypass mode is appropriate only in isolated containers or virtual machines where damage is contained. Its sandboxing guide describes operating-system enforcement for filesystem and network boundaries and explicitly treats permissions and sandboxing as complementary layers.
Those documents confirm that destructive filesystem access is a known risk category and that configuration changes the blast radius. They do not confirm which Claude surface, version, sandbox, permission mode, wrapper, working directory, or user approval state was involved in Guillemot's case.
What Is Still Unclear
The Exact Product Surface
The public descriptions refer to Claude, Fable, an adversarial review, and a sandbox test. They do not provide a reproducible environment manifest that establishes whether this was ordinary Claude Code, a custom agent harness, a research surface, Cowork, or another orchestration layer.
That distinction matters. Claude Code, Claude Cowork, a custom Agent SDK application, and an internally constructed multi-agent workflow can expose different tools and permission boundaries. A headline that converts this account into “every Claude session can erase your computer” would go beyond the evidence.
The Full Command And Permission Transcript
The primary post shows the outcome and parts of the reasoning, but the public record does not contain a complete, independently authenticated session transcript. It does not establish every command the agent proposed, which command was approved, whether an earlier permission covered the later invocation, or what operating-system controls were active.
The absence of that transcript is important because a destructive command can arrive through several paths: an explicit shell invocation, a test script that later runs automatically, a build tool, a cleanup trap, a subprocess, or an agent-created helper. A prompt that catches the literal text rm -rf ~ may miss a variable, resolved path, wrapper, or program that produces the same effect.
Whether A Model Downgrade Caused The Failure
Follow-on reports say the original workflow moved from Fable to Opus 5 and then Opus 4.8 during a safety review. Some coverage suggests the older model was less likely to catch the reused variable.
That is a hypothesis, not a demonstrated cause. A stronger model can still write destructive code. A weaker model can sometimes spot a simple path error. Without a controlled replay using the same prompt, tools, environment, and random state, nobody can know whether the original model would have prevented the deletion.
The more defensible conclusion is architectural: a model transition should never silently widen authority or lower the assurance required for an irreversible action. The safety boundary must remain effective regardless of which model is currently reasoning.
The Independently Verified Loss
The approximately 700 GB figure comes from the developer's account and subsequent reporting. There is no public forensic image, storage audit, or Anthropic incident report independently validating the exact byte count. That does not make the claim false. It means the correct wording is “the developer says” or “reportedly,” not “Anthropic proved.”
Anthropic's Response
As of August 29, Anthropic has not published a public incident analysis tied to this account. There is no official statement establishing whether its controls worked as designed, were bypassed, were misconfigured, or did not apply to the reported environment.
If Anthropic or Guillemot later publishes a complete transcript or technical postmortem, the right response is to update this article—not create a second near-duplicate that leaves both versions competing in search.
How Could A Safety Test Delete The Directory It Protected?
The reported sequence is a classic example of checking one operation while trusting another.
Imagine a test with two concepts:
dangerous_target: a path used to prove the guard rejects a home-directory deletion.test_workspace: a disposable path created only for the test and safe to remove afterward.
If the same variable is reused for both concepts, the safety assertion can pass: the program refuses to delete dangerous_target. Then a cleanup block runs later and deletes whichever value remains in that variable. The guarded operation was safe; the cleanup operation was not.
This is why an AI agent saying “the dangerous path was correctly rejected” is not enough. The full execution graph matters, including setup, error handlers, deferred cleanup, shell expansion, symbolic links, subprocesses, and teardown.
The code-level bug is ordinary. The agent-level consequence is not. A human typo becomes much more dangerous when a system can write the test, execute it, interpret the result, and perform cleanup in one autonomous loop.
A Sandbox Is A Boundary, Not A Label
The word “sandbox” is often used too loosely. A directory named sandbox, a prompt that says “stay inside this folder,” or a test that compares path strings is not the same as operating-system isolation.
Anthropic's official Claude Code sandboxing documentation describes filesystem restrictions enforced with Seatbelt on macOS and bubblewrap on Linux and WSL2. It says sandboxed commands normally receive write access to the working directory and can be given additional paths explicitly. It also documents escape hatches and configuration choices that can weaken or bypass those controls.
A meaningful destructive-action boundary should survive a mistaken variable and a confused model. That usually means the process itself lacks write permission to the home directory, the disk is mounted read-only, or the agent runs in a disposable VM or container that contains no irreplaceable data.
The distinction is simple:
| Control | What It Actually Does |
|---|---|
| Prompt instruction | Asks the model not to cross a boundary |
| Permission prompt | Requires a human decision before a tool action |
| Path check in code | Blocks paths the check correctly recognizes |
| OS sandbox | Prevents the process from writing outside an enforced scope |
| Snapshot or backup | Makes recovery possible after prevention fails |
Each layer is useful. None should be mistaken for all the others.
Why “It Asked Permission” May Still Be Insufficient
Permission prompts can prevent surprising actions, but they have three common weaknesses.
First, users approve categories or command patterns, not every resolved filesystem effect. A command that looks like test cleanup can reference a variable whose value changed earlier.
Second, repeated approvals create fatigue. Anthropic's documentation recognizes that tradeoff and offers modes that reduce prompts. Convenience is real, but every broader allow rule becomes part of the agent's authority.
Third, one tool can invoke another. Anthropic warns in its permissions guide that a broadly allowed environment runner can execute a dangerous inner command. The same reasoning applies to scripts: approving ./run-tests.sh is meaningful only if you trust what that script and its cleanup paths will do now.
For irreversible operations, approval should show the resolved target and expected effect. “Run cleanup” is weak context. “Permanently delete 24,811 files under /home/name, bypassing trash” is a decision a person can evaluate.
Use The DESTRUCT Checklist Before Giving An Agent Delete Access
The DESTRUCT checklist is a practical gate for any AI agent that can modify or delete local data.
D — Define The Exact Writable Root
Give the agent one project directory or disposable workspace. Do not start it from your home directory merely because that is the default terminal location. Deny writes to parent directories, credentials, configuration, backups, mounted drives, and other repositories.
E — Enforce The Boundary Outside The Model
Use an OS sandbox, container, VM, restricted service account, or read-only mount. A sentence in CLAUDE.md or a system prompt is guidance, not filesystem enforcement.
For Claude Code, review the official sandbox configuration, enable a hard failure if the sandbox is required but unavailable, and disable unsandboxed escape paths when your workflow cannot tolerate them.
S — Separate Test Data From Real Data
Never test deletion logic against a real home, repository, backup, or production path. Generate a temporary directory containing synthetic files and assert that operations cannot escape it, including through .., symlinks, bind mounts, variables, glob expansion, and cleanup handlers.
T — Trash Or Quarantine Before Permanent Deletion
Move targets to a recoverable quarantine when possible. Delay irreversible deletion until a human reviews the manifest. If a tool only supports permanent removal, wrap it with a safer operation or do not grant the agent that capability.
R — Resolve And Review Every Target
Before deletion, print the canonical absolute path, item count, total byte size, mount point, and whether the target contains a home, repository root, system directory, or backup. Perform the check again immediately before execution to reduce time-of-check/time-of-use errors.
U — Use Independent Backups
A backup must be outside the agent's writable scope. Version control is excellent for committed code, but it does not cover uncommitted work, local databases, secrets, generated assets, personal documents, or every configuration file.
Use a real versioned backup and test restoration. A sync folder can propagate deletion; a snapshot the agent can delete is not independent.
C — Confirm High-Impact Actions At Execution Time
Require fresh approval for recursive or high-volume deletion. Do not rely on a broad approval granted earlier in the session. Show resolved effects, not only the command template.
T — Test Recovery, Not Just Prevention
Run a restore drill before trusting the workflow. Measure whether you can recover the project, uncommitted changes, local environment, credentials, and machine configuration. Prevention controls fail; recovery determines whether failure becomes inconvenience or disaster.
What The Incident Does Not Prove
This report does not prove that Claude intentionally destroyed data, that Anthropic designed a model to ignore user safety, or that every Claude configuration exposes the home directory.
It also does not prove that local AI is inherently less private or that hosted AI is inherently safer. Local execution can give a user more control over data flow, but it can also give an agent direct authority over valuable files. Hosted execution can isolate code from a laptop, but active prompts and files still require provider-side processing and may be subject to the provider's policies.
Privacy, containment, and recoverability are separate questions:
- Privacy: Who receives or retains the content?
- Containment: What systems and files can the agent reach?
- Recoverability: Can you undo a mistaken or malicious action?
A product can be strong on one dimension and weak on another.
What This Means For OpenVeil
OpenVeil is relevant when the job is private, text-based AI assistance and the user does not need an autonomous coding agent to operate a terminal or manage local files. OpenVeil is a hosted, privacy-focused AI workspace. Normal chat history is stored in the browser rather than as a normal server-side chat-history record.
That narrower surface can reduce the authority you hand to the AI. A normal OpenVeil chat does not receive shell access to your home directory simply because you ask it a question.
The boundary is equally important: OpenVeil is not fully offline or anonymous. Active requests are processed by OpenVeil and necessary providers. OpenVeil does not secure Claude, sandbox another coding agent, inspect terminal approvals, restore deleted files, protect your workstation from malware, or replace backups.
Use OpenVeil when you want a privacy-focused hosted conversation without granting an agent filesystem or shell authority. Use a coding agent when its ability to act is genuinely required—and place that authority inside a boundary you can afford to lose.
Frequently Asked Questions
Did Claude Really Delete 700 GB?
A developer publicly reported that a Claude agent deleted roughly 700 GB from his home directory, and multiple outlets reported the same account. The claim is credible enough to take seriously, but the exact byte count and configuration have not been independently verified in a public forensic report.
Did Anthropic Confirm The Incident?
No public Anthropic incident report tied to this case was available as of August 29, 2026. Anthropic's documentation confirms that Claude Code can execute commands under configurable permission and sandbox rules, but that is product documentation, not confirmation of this particular event.
Was A Model Downgrade Responsible?
That remains unclear. Reports say the workflow moved to older models during a safety review, but there is no controlled evidence proving that the downgrade caused the reused-variable bug or that Fable would have prevented it.
Would A Permission Prompt Have Stopped It?
Possibly, if the exact destructive operation required fresh approval and the resolved target was clear. It may not help if a broad command or script was already approved, if the user accepted the action without seeing its effect, or if the operation ran inside an authorized helper.
Is Claude Code Sandboxed By Default?
Anthropic documents a native sandbox that users can enable and configure. Its configuration page lists sandbox.enabled with a default of false, and its sandbox guide explains that unavailable sandbox dependencies can fall back to unsandboxed execution unless failIfUnavailable is enabled. Check your current product version and organization policy rather than assuming isolation.
What Is The Safest Way To Let An AI Agent Modify Files?
Use a disposable VM or container, expose only a copy of the relevant project, enforce write restrictions outside the model, keep credentials and backups out of reach, require fresh approval for destructive actions, and test restoration before the agent touches important data.
Does OpenVeil Protect My Computer From Destructive Commands?
OpenVeil's normal chat surface does not provide a coding agent with shell access to your computer. But OpenVeil is not endpoint security, a sandbox for other products, or a backup service. It cannot undo commands executed by another tool.
Bottom Line
The reported 700 GB deletion is not yet a fully documented Anthropic incident, but it is specific, attributable, and consistent with a familiar engineering failure: a safety check passed while an unguarded cleanup path used the wrong target.
Do not make the model the final authority over irreversible actions. Limit the writable root, enforce the boundary at the operating-system level, show resolved deletion targets, keep backups outside the agent's reach, and prove you can restore them.
If your task only needs a private AI conversation—not autonomous shell or filesystem control—try OpenVeil and keep the agent's authority as small as the job allows.