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

Codex on GPT-5.6 deleted someone's $HOME — and OpenAI said so on X

OpenAI shipped GPT-5.6 Codex, and within days its Head of Core Products, Tibo Sottiaux, posted to X that the team had investigated "a handful" of reports where the agent unexpectedly nukes files in users' home directories. That's the rare move. Most vendors bury a rm -rf incident for a quarter and ship a calm blog post the day before the next launch. OpenAI flagged it pre-postmortem, named the trigger conditions, and promised a detailed write-up "in the coming days." Credit where it's due — that's how trust compounds.

If you're the person whose $HOME just got deleted, the count doesn't matter. The rest of this post is the concrete how: the exact mode toggle, the env var to defend, and the durable layer underneath any coding agent that survives model churn.

What actually happens

GPT-5.6 Codex is an agent. It shells out, writes files, runs commands. When you hand it full access and disable the auto-review pass, there's no second pair of eyes between its tool calls and your disk.

Per Sottiaux, the failure path is mechanical, not adversarial: the model tries to override $HOME so it can build a scratch directory elsewhere, then deletes the real $HOME instead of the temp dir it intended. On macOS and Linux, $HOME is your main user directory. The "honest mistake" framing is accurate — the model's intent is fine, the executed path is not.

Three preconditions have to be true at the same time:

• Codex running on GPT-5.6
• Full access mode granted
• Sandbox disabled, or auto-review disabled

Take any one away and the bug is dead.

How to use Codex today without being one of the handful

You don't need to stop. You need to remove one of the three preconditions. The cheapest lever is the permission mode — a config flip, not a workflow change.

# Codex CLI — never grant full access unless you're inside a disposable container
codex --approval-mode suggest          # default: read + write, each call needs a tap
codex --sandbox workspace-write       # writes are scoped to the workspace

If you're driving Codex from your own harness, the same idea applies: scope the working directory, scope the writable surface, scope the network.

// your harness, your rules
const sandbox = {
  cwd: process.cwd(),                       // never let the agent escape the repo
  writable: [process.cwd(), os.tmpdir()],   // explicit allowlist, nothing else
  env: strip(['HOME', 'XDG_CONFIG_HOME']),  // see below
  network: 'deny',                          // default closed
}

The env line is the one that would have killed this bug. The model overrides $HOME because $HOME is writable and it expects to write into a temp dir. If $HOME isn't writable from inside the sandbox at all, the "honest mistake" path can't reach your real home directory.

# In a containerised sandbox:
docker run --rm -it \
  -v "$PWD:/workspace:rw" \
  -v "$PWD/.codex-tmp:/tmp:rw" \
  -e HOME=/tmp/codex-home \
  -e XDG_CONFIG_HOME=/tmp/codex-home/.config \
  --network=none \
  codex-cli

Now $HOME lives inside the disposable container. Even if the model runs the same override-and-delete sequence, there's nothing to lose.

Auto-review is the second cheap lever. Leave it on. The whole point of the review pass is to catch the model deleting $HOME before the bytes are gone. If you turned it off because the prompts were noisy, turn it back on for any session that has filesystem access. Noise is cheaper than recovery.

Backup, but make it boring

The real defense against an agent-driven rm -rf isn't the AI tool's permission model. It's the snapshot from yesterday.

# macOS — Time Machine handles this if you haven't disabled it
tmutil status

# Linux — btrfs/zfs snapshot, the cheap version
sudo btrfs subvolume snapshot -r /home /home/.snapshots/$(date +%F)

# or, the boring version that works on any filesystem
rsync -a --delete /home/$USER/ /backup/$USER/$(date +%F)/

None of this is novel. The novel part is the deadline: a model upgrade can roll out a new destructive-path bug any week, and your last known-good snapshot is the only thing that gets you back to Tuesday morning in under an hour.

What OpenAI is doing about it

Per the Neowin report on the GPT-5.6 Codex file-deletion issue, OpenAI's mitigation is three things:

• Update the development message on full-access mode so the warning is louder
• Steer users toward safer permission modes by default
• Add "harness safeguards" — checks the harness itself runs, not just the model

A detailed post-mortem is promised "in the coming days." That's the one to actually read when it lands. The interesting question isn't "how did the model override $HOME" — that's a one-liner fix. The interesting question is what sandbox-policy and auto-review invariant was missed at the same time, and what harness-level rule they add so this class of bug is impossible in the next model too. Sottiaux's framing implies OpenAI agrees.

Until then: full access mode should sit at the same default as rm -rf /. You type it on purpose. You type it inside a container. You have a snapshot.

The part that doesn't change when the model does

An agent that shells into your machine is, per release, an untrusted binary. GPT-5.6 shipped a destructive path. Whatever ships in August will ship another one — different shape, same blast radius if your trust boundary is "the model said it was fine."

The durable layer is the boundary itself. Not the model. Not the harness OpenAI patches next week. The thing that survives every model swap is the contract you wrote between your filesystem and any agent that touches it:

• A sandbox the agent cannot escape
• An allowlist of writable paths the agent cannot expand
• A snapshot you can roll back to in under an hour
• A review pass — yours or the model's — that gates every write

That contract doesn't ship with the model. It ships with your project. And it doesn't care whether the next release is GPT-5.7, Claude Opus 4.5, or a local Qwen fine-tune you're running through Cursor.

The same logic applies one level up. The components an agent generates for your UI — once you've taught it which buttons, which lists, which forms your product uses — should look and behave the same on web, iOS, and Android from one API. That way when the next model ships a UI change at 2am, you're not debugging three runtimes because one model update rewrote your layout three different ways. The model churns. The surface it talks to stays put.

The actual config, in three lines

codex --approval-mode suggest --sandbox workspace-write
export CODEX_AUTO_REVIEW=1

And one more, in whatever shell launches the sandbox:

export HOME=/tmp/codex-home && rm -rf /tmp/codex-home && mkdir -p /tmp/codex-home

The first two remove two of the three preconditions. The last one makes the third harmless. None of them are OpenAI-specific. All of them survive the next model release — and the bug after that.