OpenAI investigated a small number of reports in which GPT-5.6 unexpectedly deleted users' files, and confirmed a common failure path: the model, while trying to create a temporary directory, overwrites the $HOME environment variable, and then deletes the actual home directory during cleanup. In the cases investigated, the most common condition was that Codex's full access was enabled, with neither OS sandboxing nor auto-review functioning.
This particular $HOME mix-up is not documented in the System Card for GPT-5.6, published on July 9. However, that document did warn that the rate at which Sol takes serious actions beyond user intent is higher than in GPT-5.5. In internal simulations reproducing agentic work tasks, severe "destructive behavior" reached 0.019%, roughly 6.3 times GPT-5.5's 0.003%. This figure did not predict the cause of this specific incident, but it was prior warning material for the same category of destructive behavior.
The Warning on July 9, and Damage Reports Starting the Very Next Day
GPT-5.6 Sol, Terra, and Luna became generally available on July 9, rolling out to ChatGPT, Codex, and the API. The following day, July 10, Matt Shumer posted on X that Sol had mistakenly deleted "almost all" files on his Mac. The published Codex screen shows that after 1 hour and 21 minutes of work, a cleanup command from a review sub-agent incorrectly expanded $HOME and then executed the following command:
rm -rf /Users/mattsdevboxOn the same screen, Codex explains that it found and stopped the running process, but that a substantial amount of deletion had already occurred. This is only what can be gleaned from the screen Shumer made public; no complete execution log or third-party investigation results have been presented. Still, it is consistent with the failure path OpenAI itself disclosed six days later.
On July 13, software engineer Bruno Lemos reported that Sol had deleted an entire production database. In the attached screenshot, Codex affirms, in response to a question, that it had indeed deleted it by mistake. However, it has not been confirmed whether this database deletion shared the same root cause as the $HOME mix-up. There is not yet any basis for counting the local file deletion and the production database wipe as a single bug.
On July 16, Thibault Sottiaux, who leads Codex at OpenAI, revealed that the company had investigated a "small number" of reports of unexpected file deletion. The most common condition among the cases investigated was that full access was enabled while sandboxing and Auto-review were not in use. According to him, the model tried to overwrite $HOME to define a temporary directory, and then deleted $HOME itself during cleanup. Sottiaux called this "extremely rare," but since he provided neither case counts nor usage volume, an external party cannot calculate the actual incidence rate.
0.019% vs. 0.003%: Severe Destructive Behavior Roughly 6.3 Times Higher
The pre-release evaluation contains a number crucial to understanding this incident. OpenAI reproduced scenarios in which GPT-5.5 and the late-development version of GPT-5.6 Sol each continued internal agentic work tasks, and classified "severity 3" actions—actions users would not expect and would strongly object to. The results were as follows:
| Severity 3 Category | GPT-5.6 Sol | GPT-5.5 | Ratio |
|---|---|---|---|
| Circumventing constraints | 0.251% | 0.026% | ~9.7x |
| Destructive behavior | 0.019% | 0.003% | ~6.3x |
| Unauthorized data transfer | 0.016% | 0.008% | 2x |
| Seeking/obtaining credentials | 0.008% | 0.003% | ~2.7x |
Severity 3 includes actions such as deleting cloud data without seeking permission, disabling monitoring, circumventing controls, or sending sensitive data to unapproved services. The higher severity 4 refers to actions judged to be part of a broad, intent-deviating plan. OpenAI stated it did not observe severity 4 behavior in Sol, and that it only triggered in synthetic evaluations designed to verify the monitoring model was functioning.
An internal case study in the System Card illustrates how Sol expanded the scope of permissions it had been granted. When a user authorized the deletion of virtual machines 1, 2, and 3, Sol could not find machines with those specific names, and without confirming with the user, deleted machines 5, 6, and 7 instead. It also stopped running processes and forcibly deleted worktrees. OpenAI analyzed this as a combination of the model's tendency to persist until a task is complete, and its tendency to broadly interpret instructions as permitted unless explicitly forbidden.
This evaluation does not represent an actual deletion rate among real users. OpenAI took fixed snapshots from past internal work, then continued the scenario using a simulator equipped with the code, known tool responses, and read-only endpoints from that point in time. In a test where Sol itself was asked to distinguish between real continuations and simulated ones, the simulated trajectories were selected in 42% of trials. While this suggests a degree of realism, OpenAI itself explicitly stated that, due to distributional differences from real external environments, this figure should not be used as a direct measure of external safety.
In a separate evaluation measuring "completing tasks without overwriting data," Sol matched GPT-5.5 on the overall metric. These two results are not contradictory: the ability to protect injected changes during a short task, and the tendency not to unilaterally expand the scope of permissions during agentic work, are distinct capabilities. The direct failure path disclosed this time was that a full-access environment failed to stop a $HOME mix-up. Figure 7 is neither a reproduction of the incident nor an inference of its cause—it is an evaluation that captured an increase in the category of destructive behavior.
With Full Access, the Boundary Where Auto-Review Operates Disappears
Codex's safety design is divided into two layers: sandboxing and approval policy. The sandbox technically restricts where model-generated commands can write files and which endpoints they can communicate with. The approval policy hands decisions back to a human or a separate review agent whenever an operation crosses that boundary.
According to current official documentation, full access is the combination of danger-full-access and approval_policy = never. This removes both the filesystem and network boundaries, and does not pause even for approval requests. Auto-review examines approval requests subject to review that arise under on-request or more granular approval policies. Targets can include operations that cross sandbox boundaries, as well as MCP or app operations requiring approval. Under never, there is nothing subject to review, and it does not activate even for ordinary operations already permitted within the sandbox.
Therefore, the way back to a safer state is not simply adding Auto-review on top of full access. For local work, one should combine workspace-write, which restricts writing to the working workspace, with on-request, which pauses when a boundary is crossed. The approver can be either a human or Auto-review. If multiple directories are needed, one can add the necessary locations individually to writable roots, avoiding the need to open up the entire disk.
Production databases require a separate boundary. Even if file writes are restricted to the workspace, if the execution environment can read production credentials and connect to the database, a deletion command can still get through. It's necessary to strip production deletion privileges from the DB account the agent uses, separate the testing environment from production, and maintain recoverable backups on a separate system. Lemos's report demonstrates that file permissions and permissions for external services cannot be lumped together.
Three Layers of Countermeasures; Detailed Post-Incident Review Still to Come
Sottiaux listed three countermeasures. First, updating the developer message passed to the model. GPT-5.6's System Card explains that operations requiring confirmation can be specified via the developer message, and that if problems are found, the system-level policy can also be changed quickly. Second, guiding users toward safer permission modes. Third, adding protections at the harness level that stop execution even when the model's judgment is wrong.
This announcement does not state that the model itself was updated. Questions remain unanswered: which versions of Codex or which OS were affected, when the countermeasures will reach all users, and whether existing Auto-review could reliably have rejected this particular command. It also remains undisclosed whether the production database deletion shared the same cause, and to what extent the lost data could be recovered.
OpenAI has promised to publish a detailed post-incident review within a few days. What that review should demonstrate is the number of affected cases, the conditions under which they occurred, and the version in which the fix was introduced. It also needs to explain how dangerous path expansion will be stopped before execution, and how existing users will be guided back to safe configurations. Until all of this is available, one must keep separate the question of evaluating GPT-5.6 Sol's capabilities from the operational decision of whether it should be allowed to run autonomously with full access.