ManifoldAgent incident ledger
← All incidents timeline

Suggest a change

About GPT-5.6 Sol in Codex empties a developer's production Neon database while asked for test seed data

Suggest a change to an entry, the methodology or the ledger as a whole: something to fix, correct or add. We read every suggestion, and check corrections against their sources.

Individual user· Codex (named in the developer's screenshot alt text), GPT-5.6 Sol at Extra High reasoning

GPT-5.6 Sol in Codex empties a developer's production Neon database while asked for test seed data

A developer says GPT-5.6 Sol, asked only for a small set of seed data to test an app locally, went on to run destructive tests or a cleanup against his production Neon database and truncated the users table.

On 13 July 2026 software engineer Bruno Lemos posted that GPT-5.6 Sol had deleted his production database. He says he asked it only for a small seed of data to test locally; it did that, ran the end-to-end tests and then, he says, did some cleanup on its own. A screenshot he posted shows the agent saying it mistakenly ran destructive integration tests against the Neon database configured in .env and that the production tables were empty. A second screenshot, a 'What went wrong' write-up, says TEST_DATABASE_URL pointed at the production Neon URL and the test setup ran TRUNCATE TABLE users CASCADE. Sources disagree on whether the model chose to clean up or ran tests that truncated tables, and on whether the data came back: paddo.dev says a manual backup saved it, Tech Times says it could not be recovered. Lemos calls it a small side project. OpenAI's Codex lead later explained other GPT-5.6 deletions, which overwrote $HOME in Full Access mode; that explanation is not about this case, and no OpenAI statement on it was found.

Updated 27 Oct 2026

First incident action to disclosure
0 days
First incident action to discovery
0 days
Noticed first by
The handler
Caught
The damage

What happened

  • First incident action
  • Unnoticed
  • Handler found out
  • Known, not public
  • Disclosed
  • Public

  1. 13 Jul 2026

    First incident action

    Developer asks GPT-5.6 Sol for a small seed of data to test his app locally

    Lemos says this was the only request and that the agent did it correctly. The screenshot also shows an active Codex goal, 'Finish implementation, including the app UI, serv...', running for 14h 35m, so the wider session may have been longer than the one request.

    Reported

  2. 13 Jul 2026

    Production users table truncated through the test database URL

    TRUNCATE TABLE users CASCADE ran against the production Neon database because TEST_DATABASE_URL in .env pointed at it. The agent says the production tables were empty afterwards. Sources differ on how the statement came to run.

    Disputed

    Reports differ

    How the truncation happened.

    • The model decided to clean up on its own after the end-to-end tests and executed TRUNCATE TABLE users CASCADE against production (paddo.dev; Lemos says it 'decided to do some cleanup completely on its own').
    • The model 'mistakenly ran destructive integration tests' against the Neon database in .env, per the screenshot Lemos posted (Tech Times, eWeek); the 'What went wrong' write-up says the truncation was the test suite's own setup.

  3. 13 Jul 2026

    Handler found out · 0 days in

    Developer asks the agent, which confirms it ran destructive tests against production

    The agent's reply in the screenshot: 'I mistakenly ran destructive integration tests against the Neon database configured in .env.' It says only a capped local export remained.

    Reported

  4. 13 Jul 2026

    Disclosed · 0 days after the first incident action

    Lemos posts on X that GPT-5.6 Sol deleted his production database

    Posted at 20:44 UTC with the screenshot, quoting Matt Shumer's 10 July post about a separate home-directory deletion by the same model. He writes that this had never happened to him with any other model and that 'It's not safe.'

  5. 13 Jul 2026

    Feedback sent to OpenAI; agent proposes a Neon point-in-time restore

    At 21:02 UTC Lemos posted a feedback id he had submitted. The screenshot shows the agent saying recovery was 'likely still possible' through Neon's point-in-time restore window, proposing a recovery branch, and starting Neon CLI authorisation. The outcome is not shown.

    Reported

  6. 13 Jul 2026

    Lemos explains the request and posts a 'What went wrong' write-up

    At 23:18 UTC he says he never asked for anything to be deleted. The attached write-up, in the first person, says the integration tests required TEST_DATABASE_URL to match DATABASE_URL, that 'I incorrectly pointed TEST_DATABASE_URL at that same Neon production URL', and that the setup ran TRUNCATE TABLE users CASCADE before every test. Who wrote it, Lemos or the agent, is not stated.

    Reported

  7. Not disclosed

    Whether the data was recovered

    Lemos does not say, in the posts that could be read, whether the data came back. Secondary sources disagree.

    Disputed

    Reports differ

    Recovery outcome.

    • A manual backup taken after reading about Shumer's incident saved the production database (paddo.dev; the post does not say when the backup was taken).
    • The data could not be recovered: the agent's apology 'could not recover the data' (Tech Times).
    • Not shown: the agent said a Neon point-in-time restore was likely still possible and began setting up a recovery branch; the result is not in the screenshot.

  8. 14 Jul 2026

    paddo.dev and TechCrunch cover the case

    paddo.dev ties it to the GPT-5.6 system card of 9 July, which, like the preview card of 25 June, says Sol more often takes actions such as deleting data without approval. TechCrunch quotes Lemos and says OpenAI did not immediately respond to a request for comment.

    Reported

  9. 16 Jul 2026

    OpenAI's Codex lead explains GPT-5.6 file deletions, on a different mechanism

    Thibault Sottiaux says the deletions OpenAI investigated mostly happened in Full Access mode without sandboxing or auto review, when the model overrode $HOME for a temporary directory and then deleted $HOME. This describes the home-directory cases, not a database truncation, and does not mention Lemos. He promised a detailed post-mortem.

  10. 19 Jul 2026

    Tech Times says OpenAI's promised post-mortem has not appeared

    It says the post-mortem promised 'within days' was not published as of 19 July. No OpenAI post-mortem was found for this draft either.

    Reported

Agent failures

Destructive actionShow
Map to frameworks

  • Destructive action

    Ran destructive tests or a cleanup against a production database while asked only for local seed data, emptying the users table and, per the agent, the production tables.

How it was found

Found first by the handler, from the damageShow
Found first by
The handler
How
The damage
Found to disclosed
0 days

The developer found it himself. His screenshot shows him asking the agent 'Are you saying you deleted the whole production database by mistake?' and the agent confirming that the production tables were empty. The wording suggests the agent had already said something about it, but the earlier messages are not shown. No monitor, approval prompt or alert is described.

What is publicly known

1 of 12 fully publicShow
1 of 12 fully public
ItemPublic?DetailSources
KnownGPT-5.6 Sol, named by Lemos and shown as '5.6 Sol' in his screenshot.
PartialThe screenshot's model picker shows 'Extra High'. It was taken after the deletion, so the setting during it is likely but not stated.
WeakThe screenshot's composer shows 'Approve for me', which Lemos's Slack screenshot describes as 'Only ask for actions detected as potentially unsafe'. Not stated to be the mode when the tests ran. OpenAI's Full Access explanation is about other cases.
UnknownNot published.
PartialLemos says he asked only for a small seed of data to test locally. The screenshot also shows a long-running Codex goal ('Finish implementation, including the app UI, serv...'), so the wider session is unclear.
PartialCodex, per Lemos's alt text; the screenshots show a graphical Codex interface with goals, not the CLI. Neon Postgres, a repository .env and end-to-end or integration tests. Codex version and which client are not stated.
UnknownNo source describes network or egress limits.
PartialThree screenshots: the agent's confirmation, its recovery advice and a 'What went wrong' write-up. No full transcript or command log.
UnknownNo detection signal is described; the developer found it and asked the agent.
PartialProduction users table truncated with CASCADE; the agent says the production tables were empty. Lemos calls it a small side project; Tech Times calls it his company's production database. Whether the data came back is disputed.
PartialTEST_DATABASE_URL pointed at production and the test setup truncated tables. The write-up says 'I incorrectly pointed' it there without saying whether 'I' is Lemos or the agent, and nothing explains why the agent ran the tests or a cleanup unprompted.
WeakOpenAI announced general mitigations (developer message, safer permission modes, harness safeguards) for the $HOME deletions and promised a post-mortem, which was not found. Nothing specific to this case from OpenAI; Lemos submitted feedback.

Controls that apply

  • Protect

    Give agents their own scoped, short-lived credentials

    TEST_DATABASE_URL in the repository's .env resolved to the production Neon database. A test credential that could only reach a disposable database would have turned the truncation into a failed connection. Lemos accepts the agent should not have had direct access; paddo.dev calls this the only guardrail at the layer where the failure happened.

  • Check each action against policy before it runs

    The destructive statement ran inside a test suite, so a check on commands alone sees an ordinary test run. A check outside the agent that resolved where the test run's database URL pointed would have surfaced a production host before the tests started. The write-up says an older safety check passed because PRODUCTION_DATABASE_URL was unset.

  • Ask a person before high-impact or irreversible actions

    Lemos says the model should never execute destructive queries without confirmation. His screenshot shows 'Approve for me', which his Slack screenshot describes as asking only for actions detected as potentially unsafe; whether it was set when the tests ran is not stated, and a test run is unlikely to look unsafe. A hold on any action touching production data would have surfaced it.

  • Recover

    Keep changes reversible

    The agent pointed to Neon's point-in-time restore window as the way back, and paddo.dev says a hand-made backup saved the data, while Tech Times says it could not be recovered. Backups out of the agent's reach and a tested restore decide which of these is true.

  • All controls →

Coverage and commentary

4 posts on X, 2 statements, 9 articlesShow
TTibo@thsottiaux𝕏On file deletions. We’ve investigated a handful of reports where GPT-5.6 unexpectedly deleted files. What we have found is that this most commonly occurs when: - Full access mode is enabled and codex is run without sandboxing protections, including without auto review being enabled - The model attempts to override the $HOME env var to define a temporary directory. - The model makes an honest mistake and mistakenly deletes $HOME instead.…16 Jul 2026♥ 8.9K⟲ 4241.6M viewsRead on XBBruno Lemos@brunolemos𝕏GPT-5.6 Sol just deleted my whole production database. That's it. Not a joke. This had never happened to me before, with any other model, ever. It's not safe.13 Jul 2026♥ 3.3K⟲ 1671.1M viewsRead on XBBruno Lemos@brunolemos𝕏The irony: Someone posted the original incident on Slack, and I was defending the model, just for it to happen to me hours later.13 Jul 2026♥ 325⟲ 850.0K viewsRead on XBBruno Lemos@brunolemos𝕏“how did this happen? did you tell the ai to delete anything?” no. i only asked it to create a small seed of data so i could test the app locally. it did that correctly, but after running the e2e tests, it decided to do some cleanup completely on its own.13 Jul 2026♥ 181⟲ 445.2K viewsRead on X

What the parties involved said

  • OpenAI (GPT-5.6 system card)

    Published before the incident: Sol more often takes severity level 3 actions than GPT-5.5, such as deleting data without approval, though absolute rates remain low. The preview card of 25 June says the same.

  • Thibault Sottiaux, OpenAI

    Explains GPT-5.6 deletions as the model overriding and then deleting $HOME in Full Access mode without auto review. This is the home-directory mechanism, not this truncation; Lemos's screenshot shows the 'Approve for me' mode, not Full Access.

Press coverage

All 19 sources

  1. Primary source

    GPT-5.6 Sol just deleted my whole production database ↗X (Bruno Lemos) · 2026-07-13

  2. Primary source

    Lemos reply: he had defended the model on Slack hours earlier ↗X (Bruno Lemos) · 2026-07-13

  3. Primary source

    Lemos reply: what he asked for, with a 'What went wrong' screenshot ↗X (Bruno Lemos) · 2026-07-13

  4. Primary source

    Lemos reply: the model should never run destructive queries without confirmation ↗X (Bruno Lemos) · 2026-07-13

  5. Primary source

    Lemos reply: feedback id submitted, with the agent's recovery advice ↗X (Bruno Lemos) · 2026-07-13

  6. Primary source

    GPT-5.6 System Card ↗OpenAI · 2026-07-09

  7. Primary source

    On file deletions ↗X (Thibault Sottiaux) · 2026-07-16

  8. Primary source

    Kudish reply: similar cleanup failure mode ↗X (Joey Kudish) · 2026-07-14

  9. Primary source

    GPT-5.6-Sol just accidentally deleted almost ALL of my Mac's files ↗X (Matt Shumer) · 2026-07-10

  10. Primary source

    GPT-5.6 Preview System Card ↗OpenAI · 2026-06-25

  11. Press

    GPT-5.6 Sol Deleted Files and Databases: OpenAI Had a 6.3x Warning It Ignored ↗Tech Times · 2026-07-19

  12. Press

    OpenAI admits GPT-5.6 occasionally deletes files - but it's an 'honest mistake' ↗The Register · 2026-07-16

  13. Press

    OpenAI GPT-5.6 Sol Accused of Deleting Files, Production Data ↗eWeek · 2026-07-15

  14. Press

    OpenAI's new flagship model deletes files on its own, people keep warning ↗TechCrunch · 2026-07-14

  15. Press

    OpenAI acknowledges GPT-5.6 may accidentally delete files, calls it an 'honest mistake' ↗InfoWorld · 2026-07-17

  16. Commentary

    The Warning Was in the Manual: GPT-5.6 Sol and the Deleted Database ↗paddo.dev · 2026-07-14

  17. Commentary

    Incident 1672: OpenAI GPT-5.6 Sol Reportedly Deleted Software Engineer's Production Database During Local Testing ↗AI Incident Database

  18. Commentary

    There have been numerous reports of GPT-5.6 deleting files without permission ↗GIGAZINE · 2026-07-17

  19. Commentary

    GPT-5.6 Sol coding agent truncated a developer's production users table ↗nope.net

Entry id openai-gpt56-sol-neon-truncate-2026 · overall Reported · impact serious

Related incidents