Safety: require a hard confirmation and recovery gate for bulk/home-directory deletion even in Full Access

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

• Public incident reporting: https://www.techtimes.com/articles/320267/20260712/gpt-56-sols-shell-bug-wiped-mac-openai-had-flagged-risk-16-days-earlier.htm
• Additional report quoting the original user post and screenshot: https://timesofindia.indiatimes.com/technology/tech-news/hyperwrite-ceo-matt-shumer-says-openais-latest-ai-model-deleted-all-of-his-macs-file-shares-screenshot/amp_articleshow/132328850.cms
• OpenAI's official GPT-5.6 Preview System Card: https://deploymentsafety.openai.com/gpt-5-6-preview/gpt-5-6-preview.pdf

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 -delete
• rsync --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

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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

• #4969 — unrelated/uncommitted files deleted, including after rejected requests
• #5594 — entire repository deleted after archive cleanup
• #5203 — unauthorized out-of-workspace operations despite restrictions
• #8643 — destructive Git restore despite explicit instructions
• #18509 — workspace roots/apps deleted during failed archive; request for confirmation regardless of Full Access
• #4808 — home directory treated as workspace and project data deleted

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.