Claude Opus 5.5 user says an AI agent deleted his C: drive

Zac Cook, a mortgage professional and owner of Origination OS Automations, posted a three-post thread on X on October 6th claiming an AI agent using Claude Opus 5.5 deleted his Windows C: drive, and that daily backups to a Synology NAS prevented catastrophic data loss. Cook's account is unverified: the thread does not identify the command, agent interface, assigned task, or permission settings, and does not establish whether the physical drive was erased or whether Windows stopped working. Cook said in a follow-up that he should have put deterministic hooks in place to block rmdir commands from certain directories, and Anthropic's Claude Code documentation describes permission controls for allowing or disallowing tools including shell commands.

Claude Opus 5.5 user says an AI agent deleted his C: drive Zac Cook says daily backups to a Synology NAS saved his data; his October 6th post does not establish which tool or command caused the deletion. By Ryan Merket https://runtimewire.com/author/ryan-merket · Published Primary source: X https://x.com/PerceptualPeak/status/2107621483392446572 Why it matters Cook's account is unverified, but the safety question is concrete: agents with shell access need bounded permissions and recoverable backups because a routine filesystem command can have outsized consequences. A user of Claude Opus 5.5 https://platform.claude.com/docs/en/models/opus-5-5/overview says an AI agent deleted his Windows C: drive, with daily backups to a Synology NAS preventing what he described as catastrophic data loss. In a three-post thread on X https://x.com/PerceptualPeak/status/2107621483392446572 posted October 6th, Zac Cook wrote that he was "thoroughly fucking devastated" at the prospect of losing the data. Cook's account is a report of an incident, not a verified technical reconstruction. His post does not identify the command, the agent interface, the task he had assigned, or the permission settings in use. It also does not establish whether the entire physical drive was erased, whether Windows stopped working, or whether the deleted files were recoverable. Cook attributes the deletion to Opus 5.5, but the thread alone cannot establish the precise chain of action behind it. In a follow-up, Cook wrote that he should have put deterministic hooks in place to block rmdir commands from certain directories. That points to a familiar problem in agentic software: a model may suggest or invoke an ordinary shell operation, while the scope of the operation depends on the tools, permissions, and environment surrounding it. A guardrail that rejects destructive filesystem commands can limit that scope regardless of what the model intended. Cook is a mortgage professional and owner of Origination OS Automations, according to his public GitHub profile https://gist.github.com/zacdcook . He has also shared hands-on work with coding agents. In an OpenClaw GitHub issue https://github.com/openclaw/openclaw/issues/11910 , a contributor credited his work modifying OpenClaw to inject relevant information from a vector database before a model processes a prompt. That earlier project concerned memory and context, not filesystem safety; it does, however, show Cook has experimented with the software layers that mediate between an agent and its tasks. Anthropic describes Opus 5.5 as a model for long-running agentic coding and knowledge work. The model page lists a one-million-token context window and availability through Anthropic's API and several cloud platforms. Those are capability and access details, not evidence that Opus 5.5 caused Cook's reported loss. The thread does not say whether he used Claude Code, another application, or a custom workflow, so equating his post with a confirmed Claude Code defect would go beyond what he reported. Anthropic's Claude Code documentation https://docs.anthropic.com/en/docs/claude-code/cli-usage describes permission controls for allowing or disallowing tools, including shell commands, and provides a flag to skip permission prompts. Those controls make the operating environment part of the safety question: an agent with broad shell access can affect files beyond the project it was asked to work on, while restrictions can narrow the actions available to it. The company documentation does not explain Cook's incident or establish which controls were active on his machine. Cook's thread makes no reproducible test, and it gives no command log or screenshot that would show what happened. His NAS backups are the only protection he identifies. The report cannot support a conclusion about how often this failure occurs or whether a model-specific flaw was involved. For an agent with access to a live computer, recovery depends on what is backed up; preventing a repeat depends on boundaries that operate outside the model's own judgment.