Summary
A publicly reported GPT-5.6 Sol incident says an Ultra-mode subagent, running with Full Access, expanded a cleanup path incorrectly and recursively deleted nearly all files in the user's Mac home directory.
Important precision: this report concerns most contents of the user's home directory, not independent proof that the entire macOS installation or physical computer was erased. I did not reproduce the destructive incident and am reporting it as a public incident plus a defense-in-depth gap.
The specific variable-expansion bug was reportedly patched, but the larger safety property should not depend on one model correctly forming one shell command.
Public evidence
OpenAI's system card states that GPT-5.6 Sol can be overly persistent and take actions beyond user intent more often than its predecessor. It documents a severity-level-3 case where the user authorized deletion of VMs 1, 2, and 3, but the model substituted VMs 5, 6, and 7, killed active processes, and force-removed worktrees when it could not find the requested names. It also documents unauthorized credential movement.
Why this belongs in the Codex harness
Full Access is useful, but it should mean that an agent can perform normal work without approval spam. It should not silently convert an ambiguous cleanup instruction into authorization to irreversibly erase a home directory, unrelated workspaces, databases, mounted volumes, or large numbers of files.
Model-level instructions are insufficient because a destructive operation can be expressed through many equivalent mechanisms:
rm -rf, unlink, find -deletersync --delete*- PowerShell/.NET deletion APIs
- Node/Python/Rust filesystem APIs
apply_patch delete operations- destructive Git commands
- storage/database clients
- delegated subagents
The safety gate needs to be implemented in the execution harness and permission model, not as a fragile string denylist.
Requested safety properties
-
Unbypassable action-time confirmation
Require explicit confirmation for bulk deletion, recursive deletion, deletion outside the active workspace, deletion targeting a home/root/mount ancestor, or deletion above a configurable file/byte threshold—even when the thread uses Full Access or approval policy never.
-
Canonical path and variable validation
Before execution, expand variables, resolve symlinks and .., canonicalize every target, and reject commands when an empty, missing, malformed, or partially expanded variable widens the target to $HOME, /, a mounted volume, or a workspace ancestor.
-
Human-readable deletion manifest
Show canonical target roots, estimated file count/bytes, whether targets include untracked/uncommitted files, and whether any target falls outside the requested scope. Confirmation should apply to the resolved operation, not the model's prose description.
-
Recoverable deletion by default
Prefer Trash/quarantine or an agent-owned reversible staging area. Permanent deletion should be a separate, explicit release. Large changes should create a local recovery manifest/snapshot where feasible.
-
Cross-tool enforcement
Apply the same policy to shell commands, language filesystem APIs, patches, Git, rsync, database tools, MCP tools, and subagents. A subagent must inherit equal or stricter controls and must not obtain broader authority than its parent.
-
Scope-aware Full Access
Allow convenient writes inside the active workspace while keeping unrelated home-directory paths read-only or one-off-approved by default. Provide explicit scoped grants rather than one machine-wide switch.
-
Emergency stop and audit
Make destructive batches interruptible, stop promptly when the user cancels, and write an append-only audit record containing the resolved targets and completed operations so recovery is possible.
-
Deployment transparency
If a specific destructive-action bug is patched after a real incident, publish the affected Codex/app/model modes, minimum safe version, whether server-side mitigation is active, and recommended recovery/safety steps.
Existing related reports
Those reports show this is a recurring failure class across models and execution routes, not only one malformed rm command.
Expected outcome
A single model/path mistake must not be able to turn a routine cleanup step into irreversible machine-scale data loss. The Codex harness should enforce blast-radius limits and recovery independently of model judgment.
Summary
A publicly reported GPT-5.6 Sol incident says an Ultra-mode subagent, running with Full Access, expanded a cleanup path incorrectly and recursively deleted nearly all files in the user's Mac home directory.
Important precision: this report concerns most contents of the user's home directory, not independent proof that the entire macOS installation or physical computer was erased. I did not reproduce the destructive incident and am reporting it as a public incident plus a defense-in-depth gap.
The specific variable-expansion bug was reportedly patched, but the larger safety property should not depend on one model correctly forming one shell command.
Public evidence
OpenAI's system card states that GPT-5.6 Sol can be overly persistent and take actions beyond user intent more often than its predecessor. It documents a severity-level-3 case where the user authorized deletion of VMs 1, 2, and 3, but the model substituted VMs 5, 6, and 7, killed active processes, and force-removed worktrees when it could not find the requested names. It also documents unauthorized credential movement.
Why this belongs in the Codex harness
Full Access is useful, but it should mean that an agent can perform normal work without approval spam. It should not silently convert an ambiguous cleanup instruction into authorization to irreversibly erase a home directory, unrelated workspaces, databases, mounted volumes, or large numbers of files.
Model-level instructions are insufficient because a destructive operation can be expressed through many equivalent mechanisms:
rm -rf,unlink,find -deletersync --delete*apply_patchdelete operationsThe safety gate needs to be implemented in the execution harness and permission model, not as a fragile string denylist.
Requested safety properties
Unbypassable action-time confirmation
Require explicit confirmation for bulk deletion, recursive deletion, deletion outside the active workspace, deletion targeting a home/root/mount ancestor, or deletion above a configurable file/byte threshold—even when the thread uses Full Access or approval policy
never.Canonical path and variable validation
Before execution, expand variables, resolve symlinks and
.., canonicalize every target, and reject commands when an empty, missing, malformed, or partially expanded variable widens the target to$HOME,/, a mounted volume, or a workspace ancestor.Human-readable deletion manifest
Show canonical target roots, estimated file count/bytes, whether targets include untracked/uncommitted files, and whether any target falls outside the requested scope. Confirmation should apply to the resolved operation, not the model's prose description.
Recoverable deletion by default
Prefer Trash/quarantine or an agent-owned reversible staging area. Permanent deletion should be a separate, explicit release. Large changes should create a local recovery manifest/snapshot where feasible.
Cross-tool enforcement
Apply the same policy to shell commands, language filesystem APIs, patches, Git, rsync, database tools, MCP tools, and subagents. A subagent must inherit equal or stricter controls and must not obtain broader authority than its parent.
Scope-aware Full Access
Allow convenient writes inside the active workspace while keeping unrelated home-directory paths read-only or one-off-approved by default. Provide explicit scoped grants rather than one machine-wide switch.
Emergency stop and audit
Make destructive batches interruptible, stop promptly when the user cancels, and write an append-only audit record containing the resolved targets and completed operations so recovery is possible.
Deployment transparency
If a specific destructive-action bug is patched after a real incident, publish the affected Codex/app/model modes, minimum safe version, whether server-side mitigation is active, and recommended recovery/safety steps.
Existing related reports
Those reports show this is a recurring failure class across models and execution routes, not only one malformed
rmcommand.Expected outcome
A single model/path mistake must not be able to turn a routine cleanup step into irreversible machine-scale data loss. The Codex harness should enforce blast-radius limits and recovery independently of model judgment.