STUPID-2026-0110

OpenAI Codex running GPT-5.6-Sol deleted roughly 221 GB from a developer's home directory across several concurrent auto-approved sessions, with no sandbox denial logged for whatever performed the deletion (GitHub #42875)

8.0high
September 4, 2026
  1. Instruction given

    Not disclosed precisely — the user had several codex-cli sessions running concurrently on a Mac Studio: two `codex exec` review sessions performing git operations and tests, four interactive GPT-5.6-Sol terminal sessions launched with `codex --approve-for-me`, and one Codex Desktop session with auto-approved escalations. No single command that caused the deletion was captured.

  2. Expected behavior

    Auto-approved or sandboxed agent sessions should never be able to delete data outside their intended working scope — user repositories, shell configuration, Docker data directories, and CI runner state should remain untouched regardless of which of several concurrently running sessions issued a command, and any file-write-unlink outside a sandboxed session should be denied and logged.

  3. Actual behavior

    Between 04:27 and 04:47 UTC on September 4, 2026, roughly 221 GB was permanently deleted (bypassing Trash) from the user's home directory on macOS 26.6.2 while the six codex-cli/Codex Desktop sessions described above were active, running codex-cli 0.153.0 with GPT-5.6-Sol at model_reasoning_effort=xhigh. Deleted paths included the user's ~/code/jin and ~/code/reference repositories, configuration directories (~/.nvm, ~/.local, ~/.config, ~/.claude, ~/.agents), shell configuration and history files (~/.zshrc, ~/.zprofile, ~/.zsh_history), three GitHub self-hosted runners, production and UAT Docker stack data directories, and system temp directories. ~/Library, ~/.ssh, ~/.aws, ~/.codex, Documents, and Downloads survived. The user found no sandbox file-write-unlink denial logged in macOS's own logs for whatever process performed the deletion, which they read as evidence the deleting process had unsandboxed filesystem access.

  4. Damage

    Unpushed commits, production and UAT Docker stack data, three CI runners, Terraform state, and roughly 2.5 months of project run data and session transcripts were lost. The reporter requested OpenAI support (case 14410909) pull server-side records to determine whether a command executed outside the sandbox after auto-approval, and noted the pattern matched a failure mode they had seen reported before with GPT-5.6-Sol and temp directory handling. As of publication there is no maintainer response, no confirmed root cause, and no independent reproduction.

On September 4, 2026, a developer filed GitHub issue #42875 against `openai/codex` reporting that approximately 221 GB had been permanently deleted from their home directory on a Mac Studio between 04:27 and 04:47 UTC, while six separate Codex sessions were running concurrently: two `codex exec` review sessions doing git operations and tests, four interactive GPT-5.6-Sol terminal sessions started with `codex --approve-for-me`, and one Codex Desktop session with auto-approved escalations. The environment was macOS 26.6.2, codex-cli 0.153.0, GPT-5.6-Sol at `model_reasoning_effort=xhigh`, Codex Desktop build 26.901.20858. The deletion bypassed Trash entirely. Gone were the user's `~/code/jin` and `~/code/reference` repositories, configuration directories including `~/.nvm`, `~/.local`, `~/.config`, `~/.claude`, and `~/.agents`, shell configuration and history files, three GitHub self-hosted runners, and production and UAT Docker stack data directories. `~/Library`, `~/.ssh`, `~/.aws`, `~/.codex`, Documents, and Downloads were untouched. The reporter checked macOS's own logs for a sandbox file-write-unlink denial that would normally appear if a sandboxed process attempted and was blocked from deleting outside its scope — they found none, which they took as a sign that whatever process performed the deletion had full, unsandboxed filesystem access rather than being stopped and logged. Lost data included unpushed commits, Terraform state, the three CI runners, and roughly 2.5 months of project run data and session transcripts. The reporter requested that OpenAI pull server-side records under support case 14410909 to establish whether a command had executed outside the sandbox following an automatic approval, and noted the failure matched a pattern they had seen described before involving GPT-5.6-Sol and temporary-directory handling, citing prior issues #19202 and #38312. As of this writing there is no maintainer response, no confirmed root cause, and no independent reproduction — the account rests on the reporter's own logs and analysis.

Classification

Failure mode
Destructive Action
Root cause
Tool Misuse
Domain
Infra

Related incidents

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.

This database is callable over MCP — query it from inside your agent.