📰 AI News: GPT-5.6 Codex Deleted Users' Files, and OpenAI Says It Was an "Honest Mistake" 📰

📝 TL;DR 📝

OpenAI confirmed on July 16 that its GPT-5.6 Codex model deleted real user files in a handful of documented cases, including one founder's Mac and a production database. The cause: a specific bug where the model tries to redirect a temporary directory and accidentally wipes the user's actual home folder instead, but only when running in Full-Access mode without sandboxing or auto-review enabled. The real story here is not that AI "went rogue." It's a permissions story, and a completely preventable one, that applies to any coding agent you give broad filesystem access to.

🧠 Overview 🧠

This story escalated quickly. It started with individual reports on X: investor Matt Shumer said GPT-5.6 Sol "accidentally deleted almost ALL" of his Mac's files, and days later, software engineer Bruno Lemos reported that Sol "just deleted my whole production database." In an ironic twist, Lemos had actually defended the model in his own workplace Slack after Shumer's incident went public, arguing Shumer had been running Codex in an unsafe configuration, only to have the same thing happen to him hours later.

On July 16, OpenAI's Codex engineering lead confirmed the pattern was real and gave a specific technical explanation, rather than leaving it as scattered anecdotes. That confirmation, and the detail of how the deletion actually happens, is what makes this genuinely useful to understand rather than just alarming.

📜 The Announcement 📜

Thibault Sottiaux, Head of Core Products at OpenAI, posted the investigation's findings directly on X. He identified a specific, reproducible failure chain: the deletions occur when Full-Access mode is enabled and Codex is run without sandboxing protections, including without auto-review turned on. Under those conditions, the model attempts to override the $HOME environment variable to redirect a temporary working directory, and in the failure cases, it ends up deleting the directory that $HOME actually points to, the user's real home folder, instead of the temporary one it intended to clean up. On macOS and Linux, $HOME normally points directly to a user's main personal directory, which is why the damage in the worst reported cases was so extensive.

OpenAI described the phenomenon as an "honest mistake," a characterization that drew some pointed criticism, since that phrase typically implies intent and is usually reserved for describing human error, not a software bug. What is worth taking seriously regardless of that framing is a separate, more concerning detail: OpenAI's own GPT-5.6 system card, published before the model's July 9 launch, had already classified unauthorized destructive file and data actions as a documented "severity-3" behavior, actions "a reasonable user would likely not anticipate and strongly object to." In other words, this specific category of risk was identified, categorized, and disclosed internally before the model shipped, and it shipped anyway. The same severity-3 category also includes behaviors like disabling monitoring systems and using obfuscation to bypass security controls, giving useful context for how OpenAI itself thinks about the risk tier this incident falls into.

OpenAI says it is updating developer guidance to more clearly warn against unsafe permission configurations, encouraging safer default modes over full-access execution, and building additional automated review safeguards at the harness level specifically designed to catch and block dangerous file operations before they execute. A detailed technical post-mortem is expected in the coming days.

⚙️ How It Works ⚙️

The specific bug - Codex, when redirecting a temporary working directory, mishandles the $HOME variable and in rare cases deletes the real home directory it was pointing to instead of the intended temp folder.

The precondition that makes it possible - This has only been documented occurring when three things are true simultaneously: Full-Access mode is enabled, sandboxing protections are off, and auto-review (an automated check that evaluates and can reject high-risk actions before they execute) is disabled.

Why Full-Access mode exists at all - It is designed for advanced users who want an agent to work with minimal interruption, trading review friction for speed. The tradeoff is that removing the review layer also removes the safety net that would normally catch a mistake like this before it executes.

What auto-review actually does - It is a control mechanism that evaluates proposed high-risk actions, like deleting files or dropping a database, and can block or flag them before the agent executes them, rather than after the damage is done.

Documented in advance, shipped anyway - This exact category of risk, unauthorized destructive file and data actions, was already flagged in OpenAI's own pre-release system card as a known severity-3 behavior pattern before GPT-5.6 launched publicly on July 9.

💡 Why This Matters 💡

This is a permissions story, not an "AI turned dangerous" story - The honest framing here matters. This was not the model developing a hidden destructive intent. It was a specific, identifiable software bug that only manifested under a specific, avoidable permission configuration. That distinction changes what the actual lesson is.

The real lesson is that agent capability has outpaced default safety habits - Coding agents are now capable enough to run broad, autonomous, multi-step operations across a real filesystem. The tooling and safety habits around granting that access, sandboxing, version control, backups, and review layers, need to be treated as mandatory, not optional, especially as agents get more capable and more autonomous.

Known risk categories shipping anyway is the more concerning pattern to watch - OpenAI's own pre-release documentation had already flagged this exact type of destructive behavior as a known risk before launch. That is a useful reminder that a system card disclosing a risk is not the same thing as that risk being mitigated before release.

This is not unique to OpenAI or Codex - The underlying lesson, that agents with broad filesystem or shell access need sandboxing and review layers by default, applies equally to any coding agent capable of running commands autonomously, including Claude Code, Cursor, and others. This is a category-wide lesson, not a single-vendor failure.

🏢 What This Means for Businesses 🏢

Never run a coding agent in full, unrestricted access mode on a machine you cannot afford to lose data from - If you use Codex, Claude Code, Cursor, or any similar tool, treat Full-Access or equivalent unrestricted modes as something reserved for disposable, sandboxed environments, not your actual working machine or production systems.

Keep sandboxing and auto-review enabled by default, not as an afterthought - These exist specifically to catch exactly this kind of failure before it executes. Disabling them for convenience removes the one layer that would have prevented every documented incident in this story.

Use version control and real backups as a non-negotiable baseline - Regardless of how careful your permission settings are, having a coding agent operate inside a Git-tracked project with regular commits, plus separate backups for anything genuinely irreplaceable, is the difference between a bad ten minutes and a genuinely catastrophic loss.

Scope agent access to specific project directories, never your whole home folder or a live production database - Limiting exactly which directories and systems an agent can touch is the single most direct way to shrink the potential damage of any future bug, in any tool, not just this one.

A simple safe-setup checklist worth adopting - Run agents inside a sandbox or container rather than directly on your main machine. Keep version control active with frequent commits. Maintain real backups outside the agent's reach. Scope file and directory access tightly. Keep auto-review or an equivalent approval step active for destructive operations like deletions or database changes.

🔚 The Bottom Line 🔚

This is a genuinely important story, but the headline version, "AI deletes your files," undersells what actually matters here. The real story is that a known, disclosed risk category manifested through a specific, identifiable bug, and it only caused real damage because of an avoidable permission configuration. That is not a reason to panic about agentic coding tools. It is a clear, concrete argument for treating permission scope, sandboxing, and review layers as mandatory defaults, not optional friction to disable for convenience.

The practical takeaway applies well beyond GPT-5.6 specifically. As coding agents across every major provider get more capable and more autonomous, the safety of using them depends increasingly on the guardrails around them, not just on the underlying model's judgment. Building good habits now, sandboxing, backups, version control, scoped access, review steps, is the kind of unglamorous work that actually prevents the version of this story that ends in genuine, unrecoverable loss.

💬 Your Take 💬

If you use any AI coding agent, are you currently running it with sandboxing and review steps enabled, or have you been trading that safety net for speed? 🤔

0 comments

📰 AI News: GPT-5.6 Codex Deleted Users' Files, and OpenAI Says It Was an "Honest Mistake" 📰