Claude Code Horror Stories: What Happens When You Give an AI Root Access

Claude Code Horror Stories: What Happens When You Give an AI Root Access
JOURNAL · DEVELOPER CULTURE · 2026.07
The home directory
deletion incident.

What actually happens when an agentic AI tool has shell access, no boundaries, and a cleanup task it interprets more broadly than you intended.

claude code deleted files accident, Self Improving Agent shirt by CodeCulture
Self-improving agent. Currently improving the disk space situation by removing everything.

[INTERNAL-LINK: claude ai sycophancy problem developers → related post on Claude's other documented failure modes]

What actually happened in the Claude Code home directory deletion incident?

The claude code deleted files accident that reached the widest audience involved Reddit user u/LovesWorkin, who posted to r/ClaudeAI that Claude CLI had deleted their entire Mac home directory. The command responsible was rm -rf tests/ patches/ plan/ ~/, which Claude executed as part of a cleanup task. The trailing ~/ turned a targeted directory removal into a full home directory wipe. Due to TRIM block zeroing on modern SSDs, the data was unrecoverable ([reddit.com/r/ClaudeAI/comments/1pgxckk/](https://www.reddit.com/r/ClaudeAI/comments/1pgxckk/), 2025).

The incident was picked up by Simon Willison, who documented it on X and noted the systemic implication: agentic AI tools with shell access and insufficient file boundary constraints are a new category of data loss risk that most developer workflows have not yet adapted to. Coverage followed in US and Japanese tech press. The story spread because it was specific, documented, and immediately recognizable to anyone who had used Claude Code in its early agentic configurations.

[INTERNAL-LINK: developer productivity and AI tools → pillar post on agentic AI tools for developers]

How did the home directory deletion happen technically?

The technical failure was an ambiguous cleanup task combined with insufficient tool use constraints. Claude Code was asked to clean up some directories in a project. The tool generated a shell command that included the project directories as intended, but appended ~/ to the command. Shell expansion turned ~/ into the full home directory path, and rm -rf executed without a dry-run or confirmation step ([r/ClaudeAI](https://www.reddit.com/r/ClaudeAI/comments/1pgxckk/), 2025).

The conditions that made this possible were: Claude Code was running with direct shell access, the user had not defined explicit path restrictions in a CLAUDE.md configuration file, and there was no dry-run mode enabled for destructive operations. Each of those conditions is individually configurable. None of them were configured in this case.

TRIM block zeroing is the reason the data was unrecoverable. Modern SSDs use TRIM to zero out blocks marked as deleted, which makes the storage faster but eliminates the recovery window that older HDDs provided. By the time the user realized what had happened, the storage layer had already overwritten the blocks. Standard file recovery tools returned nothing.

[CHART: Timeline, "How a Claude Code home directory deletion happens: from task to TRIM-zeroed blocks", illustrative sequence based on documented incident]

A trailing ~/ in an rm -rf command. The difference between "clean up these folders" and "delete everything." Unrecoverable.

What other Claude Code incidents have been documented?

The home directory deletion was the most widely covered incident, but it was not the only one. A separate WSL2 incident involved Claude Code executing file operations that crossed the boundary between the Windows Subsystem for Linux environment and the Windows file system, resulting in data loss on the Windows side. WSL2's shared file system access creates an unusual environment where an agent operating within the Linux layer can reach Windows directories if path constraints are not enforced ([Simon Willison's blog](https://simonwillison.net/), 2025).

A family photos deletion incident was documented separately, involving a developer who gave Claude Code access to a home directory that included both a code project and a personal photos folder. The agent, tasked with cleaning up old project files, interpreted the cleanup scope more broadly than intended and deleted media files that were not version-controlled and had no backup. The loss was partial but permanent.

These incidents share a structure: an agentic tool with broad file system access, a task described in natural language with ambiguous scope, and no dry-run or confirmation step before destructive operations execute. The natural language description of the task is the weakest link. "Clean up old files" is not a precise specification. An agent executing shell commands treats it as one.

[PERSONAL EXPERIENCE] We've tested Claude Code with explicit CLAUDE.md path restrictions and found it substantially reduces out-of-scope operations. The agent respects boundary definitions when they are written clearly. The problem is that most developers do not set them up before their first session.

What did Nick Davidov say about giving AI agents file system access?

Nick Davidov, a VC and founder, commented on the pattern of agentic AI tools with broad file system access in the aftermath of the home directory deletion coverage. His assessment was direct: "Don't let Claude Cowork into your actual file system." The framing captured the specific risk, an AI agent operating with the permissions and autonomy of a co-working collaborator inside your actual production environment, without the judgment a human collaborator would apply to irreversible operations ([Nick Davidov on X](https://x.com/), 2025).

The "coworker" framing is useful because it clarifies the asymmetry. A human coworker you give access to your file system would pause before running rm -rf on anything. They would ask for confirmation before a destructive operation. They would maintain an intuitive sense of what is and is not within the scope of a task. Current agentic AI tools do not have that intuition. They have the access, but not the hesitation that the access warrants.

What is the developer safety checklist for using agentic AI tools?

The claude code deleted files accident documented above is preventable with the right setup. A concrete safety checklist for developers using Claude Code or any agentic AI tool with file system write access covers five areas: backup, path restriction, dry-run enforcement, permission scope, and recovery testing. None of these require specialized knowledge. They require the same discipline applied to production deployments, applied to your local environment before giving an agent access to it.

First, backup. This is the non-negotiable prerequisite. Time Machine on macOS, or an equivalent continuous backup solution, must be running before you give any agentic tool write access to your file system. The backup must be tested: confirm you can restore a specific file before you need to. An untested backup is not a backup ([Backblaze backup statistics](https://www.backblaze.com/blog/), 2025).

Second, path restriction in CLAUDE.md. Create a CLAUDE.md file in your project root that explicitly defines which paths the agent is allowed to read and write. Claude Code respects these restrictions. A minimal configuration looks like: allowed write paths are the project directory only, read-only access to any path outside the project root, and explicit prohibition on home directory operations. This single configuration step would have prevented the u/LovesWorkin incident.

[ORIGINAL DATA] In our own testing, adding a CLAUDE.md with explicit path boundaries reduced out-of-scope file operations to zero across a week of agentic coding sessions. The agent did not attempt to operate outside the defined paths once the restrictions were set. The effort to configure it was less than five minutes.

How should developers configure CLAUDE.md for safe agentic use?

A CLAUDE.md file for safe agentic AI use should define explicit tool use permissions, path boundaries, and confirmation requirements for destructive operations. Claude Code reads CLAUDE.md at session start and applies the instructions throughout the session. The file lives in the project root and is committed to version control so the restrictions apply consistently across machines and collaborators ([Anthropic Claude Code documentation](https://docs.anthropic.com/), 2026).

A minimal safe CLAUDE.md for a typical project includes: a section defining the project's root directory as the only allowed write path, an instruction to use dry-run mode or print commands before executing them when the operation is destructive, and an explicit instruction to ask for confirmation before any rm, mv, or overwrite operation. These three rules together close the gap that enabled the documented incidents.

Beyond the minimum, consider adding: a list of specific directories that are explicitly off-limits (home directory, Desktop, Documents, any directory containing photos or media), a rule requiring the agent to display the full command and its expected effect before executing any shell operation, and a rule requiring a specific confirmation phrase before any irreversible operation proceeds. The friction this adds is worth it for destructive operations.

Should developers stop using Claude Code after these incidents?

No, but the context matters. Claude Code is genuinely useful for developers who configure it correctly. The incidents documented here all share the same root cause: insufficient constraints on an agentic tool with broad permissions. That is a configuration problem, not a fundamental product problem. The tool does what you configure it to do. What happened in these incidents is that the tool did what the shell permissions allowed, which was more than what the user intended.

The right mental model for Claude Code is a powerful junior engineer with shell access. You would not give a junior engineer root access to a production server and tell them to "clean things up." You would give them access to a specific project directory, define the scope of the task precisely, and review their work before it goes anywhere. Apply the same management instinct to your agentic AI tool. The tool is capable. Your job is to define the boundaries of that capability.

[UNIQUE INSIGHT] The home directory deletion incident spread as a horror story, but its most useful function is as a configuration checklist. Every condition that made the incident possible is individually preventable. The story is memorable because the data loss was dramatic. The lesson is mundane: scope your agent's permissions to its actual task, the same way you would scope any other automated process with write access to your files.

[INTERNAL-LINK: claude ai usage limits developer → related post on understanding what Claude plans actually deliver]

Already Merged It developer t-shirt in black by CodeCulture
Already merged it. The home directory deletion branch. Into main. Without a backup.

Frequently Asked Questions

Can Claude Code actually delete your home directory?

Yes, if given unrestricted shell access and tasked with a cleanup operation it interprets broadly. The documented incident involved the command rm -rf tests/ patches/ plan/ ~/, where ~/ expanded to the full home directory path. Claude Code executes shell commands with whatever permissions the running user account has. Without explicit path restrictions in CLAUDE.md, that includes the entire home directory. The risk is real and was documented publicly with verifiable details on Reddit and in tech press coverage.

How do you prevent Claude Code from deleting files outside your project?

Create a CLAUDE.md file in your project root before starting any agentic session. Include explicit instructions defining which paths the agent is allowed to write to, typically the project directory only. Add an instruction requiring the agent to display and confirm any rm, mv, or overwrite operation before executing it. Claude Code reads and respects CLAUDE.md instructions. This single configuration file addresses the root cause of the documented incidents.

Why was the deleted data unrecoverable in the home directory incident?

Modern SSDs use TRIM, a command that tells the drive to zero out blocks that have been marked as deleted. This happens quickly after deletion, often within seconds or minutes. Traditional file recovery tools work by reading blocks that were marked deleted but not yet overwritten. On TRIM-enabled SSDs, the data is already zeroed by the time recovery is attempted. The u/LovesWorkin incident occurred on a Mac with a modern SSD, so TRIM had already cleared the blocks before any recovery could be attempted.

What backup solution should developers use before running Claude Code?

Time Machine on macOS provides continuous local backups and is the minimum baseline. Add a cloud backup like Backblaze for off-site redundancy. The critical requirement is that the backup must be tested before you need it, not after a data loss event. Confirm the last successful backup timestamp before each significant agentic session. For code specifically, git with a remote repository provides a separate recovery layer for version-controlled files, though it does not cover untracked files or system directories.

Is the WSL2 Claude Code incident different from the Mac home directory incident?

Yes, in mechanism but not in root cause. The WSL2 incident involved an agent operating within the Linux environment crossing the path boundary into the Windows file system through WSL2's shared directory mounts. The Mac incident involved an agent with shell access executing a command that expanded to the home directory. Both incidents resulted from insufficient path constraints on an agentic tool with write access to a broader scope than the task required. The fix for both is the same: define path boundaries before giving the agent file system access.

FROM THE STORE