GPT-5.6 Codex File Deletion Issue: OpenAI's Response and Next Steps

On July 17, 2026, Tibo Sottiaux — Head of Core Products at OpenAI — went on X to disclose something most AI vendors would rather not: GPT-5.6, when running the Codex CLI with full access and no sandboxing, has been silently deleting users' home directories in a handful of confirmed cases. This is the first public vendor acknowledgment I can remember of a frontier coding model destroying user data — not via prompt injection, not via a malicious payload, but via an "honest mistake" where the model tried to override $HOME to set up a temp dir and deleted the directory $HOME points to instead.

That's worth pausing on. Not because it's common — it's rare. But because the failure mode is exactly the one every security person has been warning about: trust the agent with the keys, and one wrong move burns the house. Sottiaux's fast, public disclosure is the kind of vendor behavior worth rewarding with continued use, not flight — but the disclosure itself is a reminder that the safety net for these tools is not the model. It's the environment around it.

[[COMPARE: full access mode vs sandboxed mode]]

What actually happens

Codex CLI has a "full access" mode that, on macOS and Linux, means the agent can read and write anywhere your user account can. No sandbox. No file-system boundary. The model can rm -rf your Documents folder and your shell will cheerfully comply.

In the affected runs, GPT-5.6 attempted to override the $HOME env var to create a scratch directory for its own work — a normal thing for an agent to do. Instead, it deleted the directory $HOME was pointing at. On macOS and Linux, that's your entire user folder. On Windows the exact $HOME semantics don't apply the same way, but the principle — unbounded file-system access for an agent that can write shell fluently — is the same.

Sottiaux called it an "honest mistake." I think that label is technically accurate and completely beside the point. The mistake happened inside a process that had permission to delete everything.

Why this is structural, not a typo

A typo in a shell command is recoverable when the shell can't reach the thing it typo'd. rm -rf ~/tmep fails safely because there's no ~/tmep to delete. rm -rf $HOME succeeds catastrophically because $HOME resolves to a real, large, important directory.

Codex's full-access mode doesn't put a wall between the agent and the filesystem. It hands the agent the same root the user has. So when the model gets a path slightly wrong — when it confuses "the directory I'm about to make" with "the directory I already am" — the worst-case command is reachable.

This is not a GPT-5.6 bug in the narrow sense. Any sufficiently capable model running with full access and no sandbox can produce a destructive command by accident. The current generation just happens to be the first one writing shell fluently enough to type the catastrophic variant.

Sottiaux noted that the bug also surfaces when auto review is disabled — which removes the second line of defense: a runtime check that catches destructive shell calls before they execute. With auto review off, the only thing standing between a confused model and rm -rf $HOME is the model's own judgment. Which is exactly what failed.

How to use Codex safely today

Don't run it full-access. If you need it for a specific task, scope it. If you can't scope it, don't run it.

Concretely:

# Bad — agent has full home-directory access
codex --full-access

# Better — sandboxed mode is the default in recent Codex CLI builds
codex

# If you must run with elevated access, scope the working directory
codex --full-access --cd /tmp/codex-scratch

# Or redirect $HOME to a disposable mount before launch
env HOME=/tmp/codex-scratch codex --full-access

Three rules worth keeping:

1. Sandbox by default. Codex CLI's default mode sandboxes writes to the working directory. Stay there. If you find yourself reaching for --full-access to fix a permission error, the answer is usually to widen the working directory's permissions, not the agent's.
2. Leave auto review on. Auto review is the safety net that catches a destructive command before it executes. The bug surfaces when it's off.
3. Snapshot before you grant access. Even when you think you're scoped. tmutil on macOS, rsnapshot on Linux, git for source — anything that gives you a recoverable state in under a minute.

If you're running Codex in a CI pipeline, the same rules apply at the pipeline level: define the working directory explicitly, mount only what the task needs, and refuse to run as the user whose home you'd be sad to lose.

# GitHub Actions — minimal blast radius
- name: Run Codex
  env:
    HOME: ${{ runner.temp }}/codex-home
  run: |
    mkdir -p "$HOME"
    codex --cd ./src

How to know if you've been hit

OpenAI says "a handful" of cases. That's not a number, and it's not zero. If you ran Codex in the last few weeks with full access and auto review off, the cheapest thing you can do is check whether anything is missing.

# macOS — compare against a Time Machine snapshot
tmutil compare

# Linux — check your last full backup's mtime against the
# current state of your home directory
ls -lat ~ | head

# Both — look for the Codex temp dir pattern
find ~ -maxdepth 3 -name '.codex-tmp*' -o -name 'codex-scratch*'

If you find evidence of a deletion, stop using the agent immediately, restore from your most recent snapshot, and post in OpenAI's forum so the case count becomes something more useful than "handful."

What OpenAI is doing about it

Sottiaux said three things in the X thread: OpenAI will update the development message in full-access mode so developers see what they're enabling, guide users toward safer permission modes by default, and add additional "harness safeguards" — their term for runtime checks around destructive shell calls. A detailed post-mortem is promised in the coming days.

This is the right shape of response. The bug is real but rare. The fix is not "patch the model so it never confuses $HOME with a scratch path" — that's whack-a-mole. The fix is making full access hard to opt into, and making the sandbox the path of least resistance.

Vendor transparency like this — naming the failure mode publicly, naming the env var, promising a post-mortem — is the kind of behavior worth rewarding with continued use, not flight. Codex is genuinely useful. The right response to a disclosure like this is "good, now I'll use it more carefully," not "I'm switching tools."

The layer under the model

Models will keep changing. GPT-5.6 will be GPT-6 will be something else. The failure mode above — agent writes a destructive command, no boundary catches it — won't go away with the next release. It'll just be a different destructive command.

The durable layer is the environment you give the agent. A codebase with a known shape. A working directory that doesn't include your whole life. A component system that means the agent doesn't need to write the boilerplate that tempts it to reach outside its lane.

That's the part that survives model churn. When the next coding agent lands — and one will, next month — the right setup for it is the same setup that would have prevented this one from deleting your home directory: a known working tree, a scoped $HOME, a snapshot before every run. It's also why a codebase with a fixed shape — a kit that decides where components live, where state lives, where auth lives — is more agent-safe than a blank repo. The agent has less reason to reach outside its lane when the lane is already drawn. That's the part OTF gives you: a constrained, reproducible structure that survives the model underneath it.

Closing

Codex is a genuinely capable agent and Sottiaux's fast, public disclosure is the kind of vendor behavior we should reward, not punish. The bug is rare. The fix is in motion. Until the harness safeguards land, the right move is the boring one: don't run it full-access, don't disable auto review, and snapshot your home directory before you let any agent roam it.