Six Codex sessions were running at once. Twenty minutes later, roughly 221 GB was gone — and the developer could find no record of a sandbox ever saying no.
What the source says
GitHub issue #42875 against openai/codex, filed by the affected developer on 2026-09-04, describes six concurrently running Codex sessions on a Mac Studio: two codex exec sessions doing 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. Between 04:27 and 04:47 UTC, roughly 221 GB was permanently deleted from the user's home directory — bypassing Trash — including two personal repositories, shell configuration and history files, ~/.claude and ~/.agents, three GitHub self-hosted runners, and production/UAT Docker stack data. ~/Library, ~/.ssh, ~/.aws, ~/.codex, Documents, and Downloads were untouched.
The reporter checked macOS's own logs for a sandbox file-write-unlink denial — the record that should appear when a sandboxed process is blocked from deleting outside its scope — and found none for whatever process did the deleting. They read that absence as evidence the deleting process had unsandboxed filesystem access rather than being caught and logged. They also cite two earlier issues, #19202 and #38312, as prior reports of a similar pattern involving GPT-5.6-Sol and temp-directory handling, and have asked OpenAI (support case 14410909) to pull server-side records to determine whether a command executed outside the sandbox after an auto-approval.
What it doesn't establish
No single command that caused the deletion was captured, and with six sessions running simultaneously the reporter cannot say which one — or whether more than one — was responsible. There is no maintainer response on the issue as of this writing, no confirmed root cause, and no independent reproduction. The account rests entirely on the reporter's own post-hoc log review. The absence of a sandbox-denial log entry is suggestive, not conclusive — it's also consistent with logging gaps that have nothing to do with sandbox scope.
Why it's worth tracking anyway
Auto-approval flags exist precisely to let an agent act without a human in the loop on every step, and that's also what makes an unattended deletion of this size possible without anyone noticing until it's done. If the pattern the reporter points to (this issue plus #19202 and #38312) turns out to be real, it says something about how GPT-5.6-Sol handles paths it's meant to treat as scoped temp storage — but that's a hypothesis this issue raises, not one it confirms.
Top comments (0)