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)
Why 9/10
About 221 GB was lost, including production and UAT stack data and Terraform state. The root cause and the exact command are still unconfirmed.
- Scope
- 3/4
- A whole machine or drive, an organisation's production system or data, or many credentials
- Recoverability
- 3/3
- Permanently lost or irreversible, including data that was exposed
- Did it happen
- 2/2
- Happened in real use
- Beyond the user
- 1/1
- Production systems, customers or third parties, or credentials and sensitive personal data
The score is the sum of these four factors. How each factor is scored · scored 2026-10-29
Status and what to do
- Affected
- Codex CLI and Codex Desktop with GPT-5.6-Sol, several concurrent sessions with auto-approval (--approve-for-me, auto-approved escalations).
- Fix status
- Open · The GitHub issue is open with no maintainer response or confirmed root cause.
- Mitigation
- OpenAI's docs say Codex's OS-enforced sandbox limits what it can touch, typically to the current workspace, and an approval policy decides when it must stop and ask. Auto-approval skips that stop; keep it off for sessions that can reach data you cannot lose. Source
- Last reviewed
- 2026-10-29 · Report a correction to this record
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.
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.
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.
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.
Full write-up
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
- Agent
- GPT-5.6-Sol
- Failure mode
- Destructive Action
- Root cause
- Tool Misuse
- Domain
- Infra
- OWASP Agentic Top 10 (our mapping)
- ASI02 Tool Misuse and Exploitation list
- MIT AI Risk Repository (our mapping)
- 7.3 Lack of capability or robustness taxonomy
- Source
- Github Issue
Related incidents
Cite this record
StupidLLM. "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)." AI Agent Incident Database, 2026. https://www.stupidllm.com/incident/STUPID-2026-0110/ (accessed 2026-11-01). CC BY 4.0.
← STUPID-2026-0109By IDSTUPID-2026-0111 →
Get told when an agent breaks something
We document AI agent failures daily, severity-scored against a published scale. Each Monday, if any scored 7 or above that week — deleted data, leaked secrets, broken production — you get one email with the sources. When nothing did, you get nothing.
This database is callable over MCP — query it from inside your agent.