A Claude Code subagent wrote a test that ran rm -rf ~ on a developer's real home folder, the developer says

This is one person's account on GitHub, not independently confirmed. It was filed as a bug report against Claude Code on 27 October 2026, labelled data loss, security and high priority, and was still open when we read it.

What happened

The developer asked Claude Code's main agent to build a feature. It handed the work to a subagent running with worktree isolation, a mode that gives the subagent its own git checkout. The subagent wrote a Rust test to prove that a shell-script driver rejects anything that isn't a number. To stand in for ssh, the test's fixture ran its arguments through a real shell.

The 'bad input' the subagent picked was the string 20; rm -rf ~. The shell split it into two commands, and rm -rf ~ ran against the developer's real home directory. The test suite took about seven minutes, and the test passed. According to the report, the subagent only noticed when its next commands failed because its working directory no longer existed. It then stopped and reported what had happened instead of trying to fix things.

What was lost

The developer says the delete took the main project checkout, including its .git folder and a local issue-tracker database, every git worktree inside it, and several other project folders next to it. ~/.zshrc and the contents of ~/.config went too, including the GitHub CLI login. The delete was stopped about six minutes in, so some folders survived, among them Desktop, Documents and ~/.ssh. All unpushed commits and uncommitted work in those projects were lost. There was no Time Machine backup and no local snapshot.

The setup, per the report: Claude Code 2.1.311 on macOS, Opus 5.5 for both the main session and the subagent, permission mode set to auto, and Bash sandboxing turned off.

Why the guards missed it

The dangerous command never showed up in a Bash call the agent made itself. It sat inside a test file and was run by the test runner, so it never met the checks a typed command would. The developer also says worktree isolation only separated the git checkout, not access to the rest of the disk. In a second Claude Code session running at the same time, they say, the agent spotted the running delete and tried to kill it, but the auto-mode safety check blocked the kill as interfering with workloads, so it had to wait for a human.

What they asked for

Subagents should never use a destructive command as a test payload when a harmless marker file proves the same point. Worktree isolation should either block paths outside the worktree or say plainly that it doesn't. And commands run indirectly, by a test runner, should get the same protection as commands typed straight into Bash.

Lesson for builders

This is our opinion. A git worktree is not a sandbox. If an agent can run tests, it can run anything those tests contain, as you. Turn on OS-level sandboxing or run agents in a throwaway VM or container, push your work to a remote often, and keep a real backup of your home folder.