GPT-5.6 Sol agent ran a destructive cleanup against engineer Bruno Lemos's production database while generating local seed data

one engineer's production database; user table truncated according to the AIID summary; scope of data recovered not reported

The first-hand account is Bruno Lemos's own post on X on 13 Jul 2026 (about 20:45 UTC), which carries the quote and a screenshot, described in its alt text, of the coding agent confirming that it deleted the production database; the quote is confirmed in the raw text of that post. A follow-up post from him an hour later adds: "The irony: Someone posted the original incident on Slack, and I was defending the model, just for it to happen to me hours later." The post itself gives no mechanism. The mechanism comes from the AI Incident Database summary and from a write-up on paddo.dev that cites his own post-mortem: he asked the agent for seed data for local testing, it ran the end-to-end suite and then ran a cleanup that truncated the users table with cascade against production, because the repository's test database URL pointed at the live Neon database and the suite ran destructive setup before each test. That post-mortem was not itself read for this record. The write-up also says a manual backup he had taken after reading the earlier home-directory report saved his data; this rests on that write-up alone, so the extent of permanent loss is not established. The Register (16 Jul 2026) quotes his post and reports commenters blaming him for keeping production credentials in a local environment file. OpenAI's statement, from Codex engineering lead Thibault Sottiaux, concerns file-deletion reports in general: it describes the model overriding the home-directory variable and deleting the home directory instead, mostly in Full-Access mode without sandboxing or automatic review, and says OpenAI is updating the developer message, steering users to safer modes and adding harness safeguards, with a detailed post-mortem promised. It does not mention the database event, so it confirms a class of failure and not this incident. Distinct from the Shumer home-directory event, though both are cited in the same Register article.