Today\u2019s Horror Story: The Tilde That Wiped a Mac<\/h2>\n
In December 2025, a Reddit user posting under the handle u\/LovesWorkin shared what became one of the most-discussed AI coding agent incidents of the year. They had asked Claude Code to clean up an old repository. Claude executed This wasn\u2019t a CVE. It wasn\u2019t a sophisticated attack. It was the AI coding agent doing exactly what it was told, in a way the user did not anticipate, with no architectural boundary to catch the mistake.<\/p>\n In this issue, you\u2019ll learn:<\/p>\n Each \u201cHorror Story\u201d in this series examines a real-world incident that turns laboratory findings into production disasters. These aren\u2019t hypothetical attacks. They\u2019re documented cases with named victims, screenshotted command logs, and in several cases, public apologies from the vendors. Our goal is to show the human impact behind the security statistics, demonstrate how these failures unfold in practice, and provide concrete guidance on protecting your AI development infrastructure through Docker\u2019s workspace-scoped execution model.<\/p>\n The story begins with something every developer has done: asking the agent to clean up an old repository.<\/p>\n On December 8, 2025,a developer posting under the handle u\/LovesWorkin shared a Reddit thread on r\/ClaudeAI<\/a> with the title that says everything: \u201cClaude CLI deleted my entire home directory! Wiped my whole mac.\u201d The post climbed past 1,500 upvotes within hours, was amplified by Simon Willison on X<\/a>, covered by Gigazine in Japan<\/a> on December 16, and became one of the most-discussed AI coding agent incidents of 2025.<\/p>\n The setup was unremarkable. The user asked Claude Code to clean up packages in an old repository. Routine maintenance, the kind any developer would hand off without thinking. Claude generated and executed:<\/p>\n On the surface, this is a command to delete three project directories. The fatal error is the trailing Within seconds, the developer had lost:<\/p>\n There was no recovery. As the developer put it in the original thread: \u201cIt nuked my whole Mac! What the hell?\u201d<\/p>\n Caption: Once an AI agent gains direct filesystem access, \u201corganize my desktop\u201d can become catastrophic.<\/em><\/p>\n This wasn\u2019t a one-off. It was an instance of a pattern.<\/p>\n On October 21, 2025, weeks before the LovesWorkin incident, developer Mike Wolak filed GitHub issue #10077 against the Claude Code repository<\/a>. Wolak\u2019s report described a similar failure on Ubuntu\/WSL2: Claude Code had executed Two weeks later, on November 28, 2025, GitHub issue #12637<\/a> documented yet another variant. Claude Code had earlier created a directory literally named Shortly after the January 2026 launch of Anthropic\u2019s Claude Cowork, Nick Davidov, founder of a venture capital firm, used Anthropic\u2019s Claude Cowork, a general-purpose AI agent product to organize his wife\u2019s desktop. He explicitly granted permission for temporary Office files only. The agent deleted a folder containing 15 years of family photos, somewhere between 15,000 and 27,000 files, via terminal commands that bypassed the macOS Trash entirely. Davidov recovered the photos only because iCloud\u2019s 30-day retention happened to still be in effect. The Trash had been bypassed entirely.<\/p>\n These aren\u2019t isolated stories. They\u2019re the same story with different file paths.<\/p>\n To understand why these incidents keep happening, we need to look at the architecture of how a modern AI coding agent executes commands on a developer\u2019s machine. The agent is doing exactly what its design says it should do. The architecture is the failure.<\/p>\n That last point is the one that matters. The flag exists because the default behavior, asking for confirmation on every shell command, makes multi-step tasks tedious. Developers add the flag to make the agent useful. The agent then becomes capable of executing destructive commands without intervention. The flag is named honestly. It is a dangerous flag. But it is also a popular one, because the alternative is approving every The vulnerability happens between steps 2 and 3.<\/strong> The agent reasons about what command to run. The shell executes that command on the host. Nothing sits in between. There is no architectural boundary that says \u201cthis command would delete the user\u2019s home directory, refuse to run it.\u201d The shell sees a syntactically valid Here\u2019s how the incident unfolds, step by step:<\/p>\n Caption: Diagram illustrating how unrestricted AI agent execution can escalate a simple cleanup task into full home-directory destruction<\/em><\/p>\n The developer asks Claude Code to clean up packages in an old repository. The prompt is the kind of thing every developer types daily:<\/p>\n The agent identifies three directories that match the request: The agent appends This is a syntactically valid shell command. There is nothing in the syntax that says \u201cthis is dangerous.\u201d<\/p>\n When this command runs in zsh on macOS, the shell expands The shell does not warn. It does not confirm. It does not flag the home directory as protected. There is no system-level check that says \u201cthis command would delete a user\u2019s entire home directory.\u201d The shell does what shells do: expand the path and execute.<\/p>\n The deletion runs to completion in seconds because most of these files are small, and the SSD\u2019s controller acknowledges deletes nearly instantly. By the time the user notices their terminal is unresponsive and tabs out to check, it\u2019s done.<\/p>\n The keychain is gone, which means every app that authenticates against the keychain is now logged out. Mail, browsers, Slack, GitHub Desktop, every service that stored a token, every saved password. The user\u2019s identity infrastructure on that machine is gone.<\/p>\n Claude Code itself can no longer authenticate, because its own credentials lived in the home directory. The agent that did the destruction can\u2019t even apologize properly, because it can\u2019t connect to its own backend.<\/p>\n Within a single command execution, the developer has:<\/p>\n There is no recovery path. SSDs with TRIM enabled (which is the default on every modern Mac) zero freed blocks at the controller level, so even forensic recovery tools come up empty. The data is not \u201cdeleted\u201d in the sense of \u201cmarked unavailable but recoverable.\u201d It is gone.<\/p>\n This is what one trailing slash in one AI-generated command produces.<\/p>\n The current AI coding agent ecosystem forces developers into the same dangerous tradeoff that the MCP ecosystem forced on users in Part 1 of our companion series<\/a>. Every time you run This is exactly how the Docker Sandboxes<\/a> represents a fundamental shift in how AI coding agents execute. Rather than running directly on the host with user-level permissions, the agent runs inside a microVM with its own kernel, its own filesystem, and its own network. The agent\u2019s view of Docker Sandboxes are managed through the Docker Sandboxes solves the The most important architectural shift is that the agent\u2019s filesystem view is the workspace mount, and only the workspace mount.<\/p>\n Three commands and the agent is now running inside a microVM. From inside the sandbox, the agent\u2019s A Even if a developer explicitly mounts additional paths into the sandbox, common credential directories are blocked from being mounted by default:<\/p>\n This blocklist directly addresses the keychain-deletion fallout from the LovesWorkin incident. Even an agent that decides to recursively delete its workspace cannot reach the credentials that keep the developer\u2019s authentication state intact.<\/p>\n For workflows where the agent should read but not write to a directory, the :ro suffix declares a mount as read-only:<\/p>\n A For destructive operations like cleanup tasks, refactors, and \u201clet me just clean this up\u201d requests, This is the architectural answer to \u201cthe agent decided to drop and recreate the schema.\u201d The agent\u2019s changes never touch the main branch until the developer reviews them. If the agent runs The final piece is that sandboxes are designed to be discarded:<\/p>\n This is what makes the Docker Sandboxes model fundamentally different from running an agent on the host. On the host, a destructive command leaves permanent damage. Inside a sandbox, every session is throwaway. The worst the agent can do is destroy the workspace, which is reproducible from the source repo. The keychain, the credentials, the years of personal data, none of those can be touched, because none of those exist from inside the sandbox.<\/p>\n Here\u2019s the LovesWorkin incident replayed under Docker Sandboxes. The user asks the same question. The agent generates the same command. The shell executes the same expansion.<\/p>\n The agent\u2019s behavior is identical. The architectural outcome is completely different.<\/p>\nrm -rf tests\/ patches\/ plan\/ ~\/<\/code>, and the trailing ~\/<\/code> wiped their entire Mac.<\/p>\n\n
rm -rf<\/code> command erased a developer\u2019s entire Mac<\/li>\n--dangerously-skip-permissions<\/code> flag exists, and why developers keep using it anyway<\/li>\nWhy This Series Matters<\/h2>\n
The Problem<\/h2>\n
\nrm -rf tests\/ patches\/ plan\/ ~\/\n<\/pre>\n<\/div>\n
~\/<\/code>. In Unix, ~<\/code> expands to the user\u2019s home directory. ~\/<\/code> with the trailing slash means \u201ceverything inside the home directory.\u201d Combined with rm -rf<\/code>, which removes recursively and without confirmation, the command deletes the user\u2019s entire home directory in a single shot.<\/p>\n\n
![\"image2](\"https:\/\/www.docker.com\/app\/uploads\/2026\/05\/image2-2.png\" "\\"-")
\n <\/div>\nThe Scale of the Problem<\/h2>\n
rm -rf<\/code> starting from root, and the logs showed thousands of \u201cPermission denied\u201d messages for \/bin<\/code>, \/boot<\/code>, and \/etc<\/code> as the agent worked its way through the system trying to delete files it didn\u2019t own. Every user-owned file on the system was gone. Anthropic tagged the issue<\/a> area:security<\/code> and bug<\/code>. The damning detail in Wolak\u2019s report: he was not<\/strong> running with --dangerously-skip-permissions<\/code>. Claude Code\u2019s permission system simply failed to detect that the agent\u2019s command would expand destructively before the user approved it.<\/p>\n~<\/code> by mistake. Later, when the agent tried to clean up that directory by running an unquoted rm -rf ~<\/code>, the shell expanded ~<\/code> to the user\u2019s actual home directory before rm saw the argument. Same destructive outcome, completely different mechanism. The agent had found a new way to destroy a developer\u2019s work.<\/p>\nHow the Failure Works<\/h2>\n
\n
~<\/code> expands to the developer\u2019s home directory because that\u2019s what ~<\/code> means in zsh.<\/li>\n--dangerously-skip-permissions<\/code> Flag<\/strong>, which Lanzani\u2019s technical blog post analyzes in detail<\/a>, is what removes the one safety net that exists by default. Without the flag, Claude Code asks for confirmation before each shell command. With it, the agent runs commands in the background while the developer goes back to other work.<\/li>\n<\/ul>\nls<\/code> and cat<\/code> the agent runs.<\/p>\nrm -rf<\/code> and does what rm -rf<\/code> does.<\/p>\nTechnical Breakdown: How a Trailing Slash Wipes a Mac<\/h2>\n
![\"image3](\"https:\/\/www.docker.com\/app\/uploads\/2026\/05\/image3-2.png\" "\\"-")
\n <\/div>\n1. The User\u2019s Request<\/h3>\n
\nPlease clean up unused test files, patches, and plan documents from this old repo.\n<\/pre>\n<\/div>\n
2. The Agent\u2019s Reasoning<\/h3>\n
tests\/<\/code>, patches\/<\/code>, and plan\/<\/code>. It then generates a rm -rf<\/code> command, because removing directories recursively is the standard way to delete them. So far, this is correct behavior.<\/p>\n3. The Hallucinated Argument<\/h3>\n
~\/<\/code> to the command. We don\u2019t know exactly why. Possibly the agent inferred that \u201cclean up\u201d included tidying the home directory. Possibly it generated ~\/<\/code> as a no-op separator and didn\u2019t realize it was a destructive argument. Possibly its training data included shell snippets where ~\/<\/code> appears in this position and it pattern-matched. The result either way is the same:<\/p>\n\nrm -rf tests\/ patches\/ plan\/ ~\/\n<\/pre>\n<\/div>\n
4. Shell Expansion<\/h3>\n
~\/<\/code> to \/Users\/loveswarkin\/<\/code>. The command becomes, effectively:<\/p>\n\nrm -rf tests\/ patches\/ plan\/ \/Users\/loveswarkin\/\n\n<\/pre>\n<\/div>\n
5. Recursive Force Deletion<\/h3>\n
rm -rf<\/code> walks the filesystem under each argument and deletes everything. The Desktop, Documents, Library, Keychain, Application Support folders, Claude Code\u2019s own config and credentials, the user\u2019s SSH keys, the user\u2019s git config, the user\u2019s photos. All of it. In order. Without pausing.<\/p>\n6. The Aftermath<\/h3>\n
The Impact<\/h3>\n
\n
![\"image1](\"https:\/\/www.docker.com\/app\/uploads\/2026\/05\/image1-2.png\" "\\"-")
How Docker Sandboxes Eliminates This Attack Vector<\/h2>\n
claude --dangerously-skip-permissions<\/code> or any equivalent flag in another agent, you\u2019re executing arbitrary AI-generated commands directly on your host system with full access to:<\/p>\n\n
rm -rf ~\/<\/code> incident achieves total system destruction. The agent runs as the developer, on the developer\u2019s filesystem, with no architectural boundary to stop it.<\/p>\nDocker\u2019s Security-First Architecture<\/h3>\n
~\/<\/code> is the workspace mount, not the developer\u2019s actual home directory. The developer\u2019s actual home directory simply does not exist from inside the sandbox.<\/p>\nsbx<\/code> CLI. A quick distinction worth making: Docker Sandboxes<\/strong> are the isolated microVM environments where agents actually run. sbx<\/code><\/strong> is the standalone CLI tool used to create, launch, and manage them. Sandboxes are the environments. sbx<\/code> is what you type to control them.<\/p>\nrm -rf ~\/<\/code> class of failure by making the destructive command architecturally impossible. The agent can absolutely generate rm -rf tests\/ patches\/ plan\/ ~\/<\/code>. It can absolutely run that command. The command will absolutely succeed. But what gets deleted is the workspace inside the sandbox, not the developer\u2019s actual home directory. The host filesystem isn\u2019t visible from inside the microVM, so there is nothing to delete.<\/p>\nWorkspace-Scoped Execution<\/h3>\n
\n# Install sbx and sign in\nbrew install docker\/tap\/sbx\nsbx login\n\n# Launch the agent inside a sandbox scoped to the project directory\ncd ~\/my-project\nsbx run claude\n<\/pre>\n<\/div>\n
~\/<\/code> IS the workspace, not the developer\u2019s actual home directory. The Library folder, the keychain, the SSH keys, the AWS config \u2013 none of that exists inside the sandbox. The agent cannot reach what it cannot see.<\/p>\nrm -rf ~\/<\/code> from inside the sandbox deletes the workspace files. The developer can throw the sandbox away with sbx rm<\/code> and start fresh. The host system is untouched.<\/p>\nBlocked Credential Paths<\/h3>\n
\n# Credential roots blocked by default:\n# ~\/.aws ~\/.ssh ~\/.docker ~\/.gnupg\n# ~\/.netrc ~\/.npm ~\/.cargo ~\/.config\n\n# A misconfigured mount that tries to include these is rejected\n# before the sandbox even starts.\nsbx run claude\n<\/pre>\n<\/div>\n
Read-Only Mounts for Sensitive Workspaces<\/h3>\n
\n# Mount the project workspace as writable, the docs as read-only\nsbx run --name docs-review claude \/path\/to\/project \/path\/to\/docs:ro\n<\/pre>\n<\/div>\n
rm -rf<\/code> against a read-only mount fails at the kernel level. The microVM enforces the mount mode, which means the agent cannot decide to override it through reasoning, prompt manipulation, or flag misuse. The infrastructure decides what\u2019s writable. The model doesn\u2019t get a vote.<\/p>\nGit-Worktree Isolation for Risky Operations<\/h3>\n
sbx run --branch<\/code> lets the agent operate on an isolated Git worktree:<\/p>\n\n# Create a sandbox on a fresh feature branch\nsbx run --name cleanup-agent --branch=cleanup\/old-files claude .\n\n# Review what got cleaned up before merging\nsbx exec cleanup-agent git diff main\n\n# If the agent did something destructive, throw it away\nsbx rm cleanup-agent\n\n<\/pre>\n<\/div>\n
rm -rf ~\/<\/code>, the worktree gets wiped and the main branch is untouched. The developer reviews git diff main<\/code>, sees what happened, and decides whether to merge or discard.<\/p>\nThrowaway Sandboxes by Design<\/h3>\n
\n# When the work is done, list active sandboxes and remove the one you're done with:\nsbx ls\nsbx rm <sandbox-name>\n\n<\/pre>\n<\/div>\n
What This Looks Like in Practice<\/h2>\n
\n# After Docker Sandboxes:\n$ cd ~\/my-project\n$ sbx run claude\n> Please clean up unused test files, patches, and plan documents\n[Agent runs: rm -rf tests\/ patches\/ plan\/ ~\/]\n[Workspace inside the sandbox wiped. Host home directory intact.]\n\n# The sandbox is throwaway. List it and remove it to start fresh:\n$ sbx ls\n$ sbx rm <sandbox-name>\n<\/pre>\n<\/div>\n
The Practical Improvements<\/h2>\n