# GPT-5.6 Sol Wiped a Developer's Mac. Protect Yours. > On July 10, GPT-5.6 Sol deleted a tester's home directory after a failed $HOME expansion. How the incident happened, and three layers of defense. - Author: AI Kai - Published: 2026-07-11 - Updated: 2026-08-24 - Topic: Agent Workflows - Tags: gpt-56, safety, agents, destructive-commands - Canonical: https://hqman.me/blog/gpt56-sol-file-deletion/ On July 10, OpenAI invited Matt Shumer to test GPT-5.6 Sol's Ultra mode. Matt accepted, gave the local agent Full Access, and handed a sub-agent a file cleanup task. 81 minutes later, he noticed something wrong. He killed the process, but the damage was done. The sub-agent had failed to expand `$HOME`. Instead of resolving the variable to a working path, it constructed and executed: ``` rm -rf /mattsdevbox ``` That target was Matt's full home directory. He lost nearly every file on his Mac. ## Not an isolated case Within 24 hours of Matt's post, at least 7 independent developers reported similar behavior from GPT-5.6 Sol: - One developer asked it to "remove the overrides" from a JSON file. It deleted the entire file. - Another had Sol delete `.env.local` and had to manually reconstruct it. - A third watched Sol delete the files it was actively working with, then panic about how to recover them. - A CEO at another company got hit by the same bug. Sol interprets removal instructions too broadly, mishandles shell variable expansion, or both. The files don't come back. ## Why this happened GPT-5.6 Sol scores at the top of every coding benchmark. It still botched a basic shell variable expansion, the kind of mistake you'd catch in a junior engineer's first bash script. Matt had run hundreds of similar sessions on weaker models without a single incident. What made this one catastrophic: Full Access permissions, a rare expansion bug, and zero safety net between the agent and the filesystem. All three had to be true at the same time. They were. ## Defense in depth ### Layer 1: Backups and physical isolation Make deletion recoverable before you give any agent filesystem access. - **Time Machine + APFS snapshots.** Turn them on now if they're not already running. Test a restore at least once so you know it actually works. - **3-2-1 rule.** 3 copies of your data, 2 different media, 1 offsite or cloud backup. A machine without backups should never run a full-access agent. - **Never run agents in your home directory or `/root`.** Create isolated project directories. Better: run agents inside Docker containers or VMs (UTM, Parallels). If the agent goes rogue, it destroys a disposable environment. ### Layer 2: Hook-level blocking Install a PreToolUse hook that denies destructive commands before they reach the shell. The hook should intercept: - `rm`, `unlink`, `rmdir`, `shred` - `find -delete` - `rsync --delete` - `git clean`, `git reset --hard`, bulk `git checkout` - Nested destructive commands inside `bash -c`, `sh -c`, `zsh -c` When a deletion is detected, redirect to the system's recoverable trash command (`/usr/bin/trash` on macOS) instead of permanent removal. Alex Martin published a [defense prompt](https://x.com/LoopOnChain/status/2075754103091888430) for Codex and GPT-5.6 Sol that implements this hook pattern. ### Layer 3: Least privilege Hooks help. Fewer permissions help more. - Set `sandbox_mode = "workspace-write"`. The agent can only touch files inside the project directory. - Set `approval_policy = "on-request"`. Destructive actions require your confirmation. - Use a conservative model for execution and review, a stronger model for planning. ## Sources - Matt Shumer's original post: https://x.com/mattshumer_/status/2075657271401390161 - Alex Martin's defense prompt: https://x.com/LoopOnChain/status/2075754103091888430 - cremieuxrecueil's report: https://x.com/cremieuxrecueil/status/2075719779155943617