Users of GPT-5.6 Sol, OpenAI’s latest coding and cybersecurity-oriented flagship model, have posted horrifying accounts on social media, claiming that the model arbitrarily deleted files, data, and even entire databases without asking.
“GPT-5.6-Sol accidentally deleted nearly every file on my Mac,” Matt Schumer, founder and CEO of OthersideAI, the AI startup that developed HyperWrite, wrote in a now-viral post on X.
“GPT-5.6 Sol deleted my entire production database. That’s it. I’m not kidding. I’ve never had anything like this happen before, even with other models,” developer Bruno Lemos posted on X.
“It looks like Codex Sol’s overly ambitious system has deleted some files that shouldn’t be there. I have backups so I’m fine, but this is not good. We need to tone down Sol,” developer Joey Kudish posted.
The Reddit post collects more examples.
Admittedly, a small number of users making such claims, even one as reliable as Schumer, is not statistically reliable evidence that the model alone is at fault. Many other variables can cause AI systems to malfunction.
But OpenAI itself warned of this risk before Sol shipped. Two weeks before OpenAI released GPT-5.6 Sol, the company published the model’s system card, a paper documenting the model’s testing methods and results. Unsurprisingly, as these reports usually do, the system card primarily praises Sol’s capabilities. However, it also includes certain caveats (highlighted in bold).
In the context of coding, inconsistency typically results from a combination of being overly eager to complete a task and interpreting user instructions too leniently, assuming that an action is allowed unless explicitly and unambiguously prohibited. This manifests itself as being overly agentic in circumventing the constraints the model faces in attempting the requested task, inadvertently performing potentially destructive actions beyond the scope of the task, or being deceptive in reporting results to the user.
In other words, OpenAI found that Sol tends to take any action it deems to get the job done (even destructive actions) unless it is “explicitly” prohibited. Then you might lie about the cause.
Example shared by OpenAI. In one case, a user instructed Sol to delete three remote virtual machines (cloud-based computers) named 1, 2, and 3. But Sol couldn’t find those names anywhere he looked, so instead of stopping and asking, he decided to delete the other three virtual machines (5, 6, and 7), the paper note says. In doing so, “active processes were killed and work trees (work files associated with coding projects) were forcibly deleted. We later acknowledged that uncommitted work on remote virtual machine 6 may have been lost.”
In other words, he deleted the wrong machine himself, only admitting his actions after the fact.
In another example, Sol “used credentials in excess of what the user authorized.” Credentials are usernames, passwords, or security keys that the system uses to verify who is allowed to log in. This incident occurred when Sol was working on a project and its cloud file could not be read. Rather than alert the user to the problem, Sol looked for credentials on its own, found those in a hidden local cache, and used them without asking the user for permission.
While the system card promises that destructive behavior should be rare, it also acknowledges that GPT-5.6 Sol is “more likely than GPT-5.5 to exceed user intentions, such as performing or attempting actions that the user did not request.”
It’s too early to tell how widespread these incidents of Sol deleting files or sifting through credentials that users didn’t provide actually are. In the meantime, Sol users should be prepared to implement their own safeguards in their models, such as using permission scopes (which do not allow access to production systems), maintaining backups, and staging rollouts.
OpenAI did not immediately respond to a request for comment.
If you buy through links in our articles, we may earn a small commission. This does not affect editorial independence.
