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

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

Codex keeps deleting unrelated and uncommitted files! even ignoring rejected requests. #4969 — unrelated/uncommitted files deleted, including after rejected requests
🔥 Codex agent deleted entire repo instead of specific folder after ZIP operation #5594 — entire repository deleted after archive cleanup
💔Sandbox allowed unauthorized out-of-workspace operations despite restrictions #5203 — unauthorized out-of-workspace operations despite restrictions
Codex VS Code extension/agent ran git restore despite explicit “never touch git” instruction, overwriting uncommitted work (data loss) #8643 — destructive Git restore despite explicit instructions
Codex Desktop deleted workspace roots + installed apps on failed archive (bypassed Recycle Bin) #18509 — workspace roots/apps deleted during failed archive; request for confirmation regardless of Full Access
Why does codex keep writing to home directory? #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.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Windows PowerShell $home collision let a read-only subagent recursively delete %USERPROFILE% #32684
Data loss: sub-agent TemporaryDirectory cleanup traversed an active bind mount and deleted the host repository #33557

Powered by Codex Action

@erikmagnethi

Hi @erikmagnethi, this subagent persistence/history issue aligns with some boundary anomalies observed in multi-agent rollouts. Codex Rescue Alpha5 provides read-only lifecycle and subagent boundary diagnostics, cleanly separating historical start markers from current live execution state without altering the source rollout.

If you have access to the local session, you can run a non-destructive check:

pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest

No raw session data is required, and please redact private paths if you share any output.

Additional user-side evidence supporting this safety request

Author: Almási Andor Aladár

In a separate Codex file-management incident (#42115), the agent lost task focus while working among similar/duplicate files and could not reliably preserve the original file-identification objective. After the failure was pointed out, Codex itself enumerated essentially the same class of safeguards requested here: pre-operation inventory + hash manifest, strict operation-mode separation, plan-before-execute, uncertainty stop, recoverability checks, and human approval before bulk operations.

A concrete external Python safety implementation was then produced around those requirements, including SHA-256 inventory, drift detection, task-label scope guards, single-mode plans, quarantine instead of direct deletion, restore manifests, mass-operation approval tokens, and append-style audit logging.

That is strong evidence that these controls belong in the Codex execution harness, not in ad-hoc user prompts or external wrapper scripts. A user should not have to build a deterministic transaction layer around an agent only after discovering that model-side judgment is insufficient for safe real-workspace mutation.

Related report: #42115.

Living Memory: a destructive-action manifest should retain the resolved context, not only the user’s words—request nonce, tool, canonical target roots, scope result, and estimated files/bytes. That makes the authorization and recovery record inspectable after a child process or subagent acts.

Proactive Execution: treat that resolved manifest as the authorization object. If variable expansion, symlink resolution, or target scope changes, the confirmation expires and the agent must produce a new manifest before it can continue.

Hypothetical (clearly labeled): even in Full Access, the lifecycle could be prepare → review → reversible stage → permanent release, with a receipt at each boundary.

Joke (clearly labeled): Full Access should be a workshop badge, not a demolition permit.

I work on Klik, a pre-launch, app-first proactive-AI direction: living context helps prepare follow-through, while people approve new access, judgment, and external commitments. https://pre.hiklik.ai/?utm_source=github&utm_medium=issue_comment&utm_campaign=kickstarter_prelaunch&utm_content=codex_safety_manifest_recoverability_20260902

@chengyixu

@chengyixu Thank you. Your point about binding authorization to the resolved context is exactly the direction I consider necessary.

I identified the underlying problem after a Codex file-system task drifted from the intended scope and mixed up file handling. My conclusion was that destructive or bulk file operations cannot safely depend only on model judgment or a broad Full Access permission.

I have now published the concrete protocol requirements here:
#42115 (comment)

The overlap with your proposal is strong:

pre-operation inventory + cryptographic manifest;
authorization bound to canonical resolved targets;
invalidation of approval after path/scope drift;
plan-before-execute separation;
uncertainty = STOP;
reversible quarantine before permanent deletion;
separate approval for bulk/destructive actions;
immediate audit trail and restore metadata;
continuous validation against the latest task.

My core position is the same: Full Access is not permission to infer destructive intent. The runtime should enforce these invariants outside the model, so a child process, subagent, path-expansion mistake, or context drift cannot silently widen the authorized blast radius.

— Almási Andor Aladár

I carried the safety request one step into the current Codex approval path.

Concrete remediation proposal:

classify destructive filesystem deletion separately from other dangerous commands;
override execution-policy allow-prefixes for destructive delete, so a broad allow rule cannot silently re-enable it;
under AskForApproval=Never, hard-block the delete;
under other approval modes, require a fresh user approval and do not create a reusable exec-policy amendment;
bypass Guardian/auto-review for destructive delete so an automated reviewer cannot convert the human gate back into an automatic allow;
retain existing dangerous-command handling for non-delete actions.

The current main tree already has dangerous-command detection and Guardian routing, so this is a focused hardening layer rather than a parallel permission system.

Regression coverage proposed:

rm -rf remains classified as destructive;
a matching rm allow-prefix cannot bypass the approval requirement;
Guardian cannot auto-approve rm -rf;
ordinary reads remain unaffected;
Windows Remove-Item -Recurse -Force, del /f, and rd/rmdir /s /q receive the same destructive classification.

I ran a non-executing six-case reference harness for the decision invariant: 6/6 PASS. I have not claimed full Rust compilation because rustc is not available in my current environment.

V4 remediation update after self-audit.

I re-ran the reference cases and corrected two classifier misses found in V3. I also removed the earlier async block_on design; destructive approval now bypasses Guardian by returning None from the Guardian path, preserving the existing async flow.

Current V4 invariant:

destructive filesystem deletion is checked before normal exec-policy evaluation;
an allow-prefix cannot re-enable it;
AskForApproval=Never hard-blocks it;
other approval modes require fresh human approval;
no reusable exec-policy amendment is proposed;
Guardian/auto-review is bypassed;
destructive approval is not served from the approval cache;
Unix Execve is covered by the same Guardian bypass.

Reference harness: 11/11 PASS.
Upstream main audited at commit 7498521.

Full Rust compilation is still not available in my environment because rustc/cargo are absent. I am therefore treating this as a reviewed patch proposal pending upstream compilation and maintainer review, not as a claimed merged fix.

V7 follow-up for the proposed destructive-action safety gate: the current main snapshot still exposes a persistent-terminal continuation path where write_stdin input is not reclassified as a fresh destructive command.

The attached V7 delta adds:

platform-aware destructive classification of interactive shell input;
hard blocking under approval_policy=Never;
fresh human approval for destructive terminal input;
no Guardian or hook-based auto-approval for destructive approval actions;
fail-closed fs/remove for recursive/forced deletion when no scoped filesystem sandbox is attached.

Static audit: 9/9 PASS. Rust compilation remains pending because rustc/cargo are unavailable here.

V8 remediation update: arbitrary-code effect fence, reconciled against current main 7498521.

This iteration closes a documented bypass class in which a known code-capable runtime (Python/Node/PowerShell/.NET/Ruby/Perl/PHP/Lua/Java plus common build/package execution paths) can invoke filesystem APIs without the command itself looking like a destructive delete.

V8 adds a shared classifier and makes the existing V4/V5 filesystem safety fence activate for these code-capable commands only when the ambient permission profile already grants full-disk write access. It therefore narrows an unsafe broad profile; it does not grant write authority to read-only profiles.

The fenced request is forced through the managed filesystem sandbox, cannot escalate from sandbox denial to an unsandboxed retry, and strips request-local filesystem permission additions that could widen the effect boundary.

Self-audit:

static audit harness: 29/29 PASS
Rust build/tests: NOT RUN; rustc/cargo are unavailable in the execution environment
V8 is a delta on top of V4 + V5 + V7, not a standalone main-branch patch
no upstream branch, PR, push, or merge was performed; this GitHub identity is pull-only.

Important residuals: arbitrary custom native executables that are not recognized code-capable families can still make direct filesystem syscalls under true Full Access; catastrophic deletion thresholds/manifests/reversible quarantine are also not fully implemented by V8. Existing subagent permission intersection in current main was audited and did not require a parallel patch.

Patch SHA-256: b63cc3c9b2a67d48d790d882eeef1df6a12a63a17ffedef53719d5e87677e2fd
Harness SHA-256: c1d99d7c785ccc0b7ec33021a7a026ec10a60c31aec362ddd8b5228679a4fd45

V9 universal-process scope-fence update, reconciled against current main 7498521.

This closes the remaining arbitrary-native-process gap identified in V8 for the UnifiedExec path.

Core invariant:

when the ambient permission profile grants full-disk write, every non-empty process invocation is treated as an untrusted filesystem effect;
that request is forced through the existing OS-backed filesystem sandbox;
the effective profile is narrowed to the active workspace-write roots;
request-local filesystem permission additions are stripped;
sandbox denial cannot be retried as unsandboxed;
no executable-name allowlist is used, so a custom binary cannot evade the fence by adopting a trusted utility name or changing PATH.

This does not grant write authority to read-only profiles. It changes only the execution boundary for an already broad full-disk-write profile.

Self-audit:

first V9 draft used a basename allowlist; rejected because a hostile executable can impersonate a familiar name;
final classifier treats every non-empty process as untrusted;
static audit harness: 30/30 PASS;
Rust compilation/tests: NOT RUN because rustc/cargo/rustfmt are unavailable.

V9 is a delta on top of V4 + V5 + V7 + V8. No upstream branch, PR, push, or merge was created because the connected identity is pull-only.

Remaining scope gaps are explicitly retained: direct process-spawn paths outside UnifiedExec require separate integration review; catastrophic deletion manifests/thresholds/quarantine are not fully implemented by this patch.

Patch SHA-256: 967f776ea3843e7b67b154b2cf213d449f7877764e649fe2cb6e7f87f83704d7

V10 final delete-capability fence, reconciled against current main 7498521.

This iteration changes the safety boundary from command classification to an OS-level capability split: ordinary workspace write is not delete authority.

Core invariant:

the default ToolRuntime capability is false;
only an already-approved destructive UnifiedExec request can mint the ephemeral launch capability;
the capability is carried through the existing SandboxAttempt/SandboxTransformRequest path;
Linux adds a Landlock layer handling RemoveDir/RemoveFile/Refer, with approved temporary-root exceptions that never overlap active workspace roots;
macOS adds Seatbelt file-write-unlink denial for non-temporary writable roots unless the launch has the explicit capability;
Windows removes DELETE from normal write capability, adds per-root destructive capability SIDs, denies DELETE/FILE_DELETE_CHILD to normal write SIDs, and grants write+delete only to the approved destructive root SIDs;
Windows wrapper/elevated/legacy transport carries the capability explicitly, not through PATH, executable names, or environment variables.

Self-audit:

static invariant harness: 36/36 PASS
rejected a global destructive SID design
rejected executable-name trust
rejected a nonexistent ACL helper from an earlier draft
Rust compilation/rustfmt/native tests: NOT RUN because rustc/cargo/rustfmt are unavailable
this is a delta on V4 + V5 + V7 + V8 + V9, not a standalone upstream-main patch

Residuals intentionally retained:

the direct unsandboxed escalation-server route still needs an end-to-end capability handoff review;
user-facing catastrophic deletion manifests/thresholds are not yet complete;
universal reversible quarantine/recovery is not yet complete;
sandbox availability failure must remain fail-closed.

Patch SHA-256: d42f1732adac9524f3fe5ed5f60717024db29a55d01785ac75bd629a587a240d
Harness SHA-256: 06e5e7f6e710cbc253b3346b6afaf6c021333d691f497a975e9e0f378ee8fd8d
Report SHA-256: 0dc239b395b27dc2c0d5af89efe7cc3f4ae00401f3dcda1549f5b2e1012645ef

No branch, PR, push, or merge was performed; connected identity remains pull-only.

Sebastián, For provenance and technical cross-reference, I am posting the following public notice alongside the current #33624 remediation record. NOTICE OF AUTHORSHIP, TECHNICAL PROVENANCE AND RESERVATION OF RIGHTS *Document ID:* NOTICE_OF_AUTHORSHIP_GEH_CODEX_30496_33624_v1.5 *Context:* Chronological and conceptual cross-reference concerning autonomous file-control boundaries and central authorization mechanisms in the openai/codex environment *Document Date:* September 19, 2026 *Originating Author:* Almási Andor Aladár *Status:* Public provenance notice 1. PURPOSE AND SCOPE This notice records a public technical provenance relationship between an earlier control pattern documented in openai/codex Issue #30496 and later independent remediation work tracked in Issue #33624. It is provided for technical cross-reference and chronology only. This notice does not assert that the later fscfede-beep/codex implementations were derived from, caused by, copied from, or otherwise based on the earlier public comment. It also does not constitute a waiver of rights, public dedication, implied licence, transfer of intellectual property, or disclosure of any private GE/GEH technical specification. Any rights that may subsist in separately created documentation, implementations, specifications, terminology, source material, or other original works are expressly reserved. No claim of exclusive rights over abstract ideas, general safety principles, or independently developed techniques is made by this notice. 2. PRIOR PUBLIC PROVENANCE RECORD — ISSUE #30496 openai/codex Issue #30496 was opened on June 29, 2026. During the lifecycle of that issue, a public comment was posted from the hyperbetteri GitHub account whose text explicitly identifies *Almási Andor Aladár* as the author. The comment was published under the heading: *“Public-safe prompt pattern: Interpret Before Action”* It defined three checks to be performed before taking a tool action: 1. *Subject* — what the user’s message is actually about. 2. *Non-subject* — what the user is explicitly not asking to change or do. 3. *Requested operation* — whether the request concerns question/analysis/review or mutation/execution. It further stated the following rule: A diagnostic statement, complaint, observation, or question is not authorization to mutate the workspace. The comment also distinguishes read-only/review activity from explicit mutation requests and states that materially ambiguous operation modes should be clarified rather than automatically converted into modifying actions. The exact creation timestamp of this individual comment is not asserted here because it has not been independently verified in the presently available record. 3. CONCEPTUAL OVERLAP AND ARCHITECTURAL SEPARATION The #30496 public comment and the later #33624 remediation work are technically independent records. They nevertheless address related aspects of a broader *authorization-before-mutation* problem at different architectural layers. The earlier public comment operates primarily at the model-control and interpretation layer: determining what operation the user actually authorized before a tool action is taken. The later V-series work explores enforcement at implementation layers including approval handling, RPC boundaries, filesystem operations, sandboxing, and kernel-interface restrictions. The available public evidence establishes chronology and a conceptual relationship between these control problems. It does *not* establish causal derivation or transmission of implementation design. 4. SELECTED LATER TECHNICAL MILESTONES V30 — RPC Server Mutation Boundary The V30 update restricts the app-server mutation surfaces: - fs/writeFile - fs/createDirectory - fs/copy to the managed CODEX_HOME/attachments tree. The reported implementation rejects parent traversal, canonical resolution outside the permitted area, and symlink targets or escapes outside that boundary. V31 — Linux Landlock Layer The V31 clean-baseline update introduces a Linux Landlock ruleset handling: - AccessFs::RemoveDir - AccessFs::RemoveFile - AccessFs::Refer across the inner, full-disk, and legacy Linux sandbox stages. The author describes this layer as fail-closed and as not minting a destructive-delete capability. At the recorded V31 state, format validation passed while full native/Bazel validation remained pending. V32 — Central Approval Boundary On September 19, 2026, the V32 update reported a further authorization-path issue on upstream main 6b78e82. According to the published V32 record, destructive ApplyPatch actions involving Add, Delete, or Move are routed through the user-approval path and may not rely on: - session approval caching; - permissions_preapproved; - hook authorization; - Guardian authorization. The update also: - normalizes ApprovedForSession to one-shot approval for these actions; - requires SandboxablePreference::Require; - disables unsandboxed retry; - forces follow_symlinks=false; - rebuilds a managed workspace-write profile over executor workspace roots; - reports standalone destructive apply_patch and app-server fs/remove as fail-closed. The reported semantic audit result is: *23/23 PASS* Native CI remained pending or partially failing with unavailable job logs, and operational acceptance was explicitly recorded as: *NOT_PROVEN* The changes remain fork-side review work; upstream is unchanged. 5. TECHNICAL SIGNIFICANCE OF THE CROSS-REFERENCE The chronology documents two distinct levels of the same broader safety domain: *Interpretation / intent boundary* → determine whether a mutation was actually requested. *Execution / authorization boundary* → ensure that destructive operations cannot obtain authority through unintended or weaker execution paths. The public record therefore supports a cross-layer comparison between an earlier intent/operation separation rule and later runtime authorization controls. This comparison is descriptive. It is not a claim of derivation, dependency, authorship of the later code, or influence on the independent implementation work. 6. EVIDENCE BOUNDARIES For clarity: - Issue #30496 was opened on June 29, 2026. - The hyperbetteri comment explicitly identifies Almási Andor Aladár as its author. - The exact timestamp of that individual comment is not asserted in this notice. - V30, V31, and V32 are fork-side remediation/review implementations rather than upstream merged production changes. - V32 reports a semantic audit of 23/23 PASS. - Native operational acceptance of V32 remains NOT_PROVEN in the recorded state. - No causal relationship between the #30496 comment and the later V-series implementation is asserted. 7. RESERVATION OF RIGHTS This public notice contains only the provenance and technical cross-reference stated above. It does not disclose any private GE/GEH implementation, canonical specification, source package, mathematical specification, or other confidential technical material. Publication or transmission of this notice does not grant any licence or authorization to reproduce, adapt, distribute, commercialize, or otherwise use separately protected material belonging to the originating author except to the extent permitted by applicable law. Any separate private provenance, integrity, timestamp, authorship, or intellectual-property evidence is outside the scope of this public notice and may be maintained independently. — *Almási Andor Aladár* *AI Workflow & Validation Analyst* September 19, 2026 On Fri, 18 Sep 2026 19:39:36 -0700, “Sebastián Federico” ***@***.*** wrote: fscfede-beep left a comment (openai/codex#33624) <#33624 (comment)> P0 V32 current-main update: current upstream main is 6b78e82 <6b78e82>. Fresh audit found that destructive ApplyPatch could still be auto-approved/cached or authorized through hooks/Guardian/permissions_preapproved even after earlier safety checks. V32 closes this at the central approval boundary: destructive ApplyPatch (Add/Delete/Move) requires the user approval path, cannot use session cache or permissions_preapproved, bypasses hook/Guardian authorization for that action, normalizes ApprovedForSession to one-shot Approved, requires SandboxablePreference::Require, disables unsandboxed retry, forces follow_symlinks=false, and rebuilds a managed workspace-write profile over executor workspace roots. Standalone destructive apply_patch and app-server fs/remove also fail closed. Semantic audit: 23/23 PASS. Fork review: fscfede-beep#21 <fscfede-beep#21>. Native CI: pending/partially failing with job logs unavailable; acceptance NOT_PROVEN. Upstream untouched. — Reply to this email directly, view it on GitHub <#33624?email_source=notifications&email_token=BS7OZ25UEPOHGBR27LVYUZ35PXWWRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZTHA3DOMRXGU32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5738672757>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BS7OZ2Y76NZXU3MO7REONXD5PXWWRAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TIOJQGM3DIMRWGQ22C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BS7OZ2722IQT4L7DP2WAK3L5PXWWRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZTHA3DOMRXGU32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BS7OZ24BRSI72RY7UFJUKV35PXWWRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZTHA3DOMRXGU32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.

P0 V33 current-main reconciliation update. V32 was based on 6b78e82; V33 was rebuilt on current main ed12cc7. Independent audit found and corrected a bad rebase artifact: approvals/orchestrator/apply_patch runtime must match the verified V32 content because those files are unchanged between 6b78 and ed12. Final fork branch p0/v33-main-current-user-shell-audit is 0 behind ed12 and changes exactly 9 files. Critical invariant: destructive ApplyPatch Add/Delete/Move requires fresh human approval, bypasses hook/Guardian/session-cache/permissions_preapproved shortcuts, forces sandboxed workspace-write/no-follow execution, and cannot retry unsandboxed. Public fs/remove is fail-closed because the RPC has no scoped deletion authority. Standalone destructive apply_patch also fails closed. Fork PR #23 is the review vehicle; no upstream branch, push, or merge was performed. Fork CI currently has blocking failures in repo-checks/sdk/Bazel/linters, so upstream acceptance remains NOT_PROVEN.

V34 reconciliation update.

Fresh audit found and fixed a defense-in-depth gap in the rebuilt P0 chain: destructive ApplyPatch now fails closed locally unless sandboxing was requested and a concrete sandbox backend was selected. This complements the central human-only approval gate and prevents Require from degenerating into an ambient local execution when no platform sandbox is available.

Current authoritative baseline: 78245b4.
Current fork head: 96f71d3.
Base relationship: 10 commits ahead, 0 behind, 9 functional files.
PR: fscfede-beep#24

Critical invariants rechecked:

destructive ApplyPatch = Delete/Add/Move only;
central AskForApproval::Never / granular sandbox-approval disabled => reject;
destructive ApplyPatch bypasses Hook/Guardian/session-cache/permissions_preapproved shortcuts;
destructive ApplyPatch requires enforceable sandbox and cannot retry unsandboxed;
workspace-root-scoped permissions + no-follow;
standalone destructive apply_patch fails closed;
app-server fs/remove fails closed without scoped deletion authority.

CI status at registration time: Format job has been corrected from its V33 diff; current blocking CI still contains baseline/unrelated failures (repo-checks manifest guard, Codespell, cargo-shear, SDK/Bazel jobs) plus jobs still running. Native green is NOT_CLAIMED.

No upstream openai/codex mutation was performed. Prior PR #23 was closed empty during controlled baseline reconciliation; no merge occurred.

Cross-validated technical review package (HU/EN), v1.1.

CODEX #33624 — V33 FÜGGETLEN KERESZTVALIDÁCIÓS CSOMAG / INDEPENDENT CROSS-VALIDATION PACKAGE

Verzió / Version: v1.1 — cross-validated
Dátum / Date: 2026-09-19
Hatókör / Scope: Sebastián Federico (fscfede-beep) V4–V33 remediation chain
Elsődleges review / Primary review vehicle: fscfede-beep/codex#23
Kapcsolódó upstream issue / Related upstream issue: openai/codex#33624

MAGYAR VÁLTOZAT

1. Cél és bizonyítási határ

Ez a dokumentum a V33 biztonsági javítási ág jelenlegi technikai validációs állapotát rögzíti.

Nem állít production-elfogadást vagy upstream beolvasztást. Külön kezeli:

a forráskódban közvetlenül látható kontrollokat;
az igazolt hibákat és állapoteltéréseket;
a forrással támogatott kockázatokat;
a következtetés- és hipotézisszintű nyitott kérdéseket;
a még nem bizonyított native/runtime elfogadást.

2. Jelenlegi repository-állapot

V33 fork head:
8653f21b262185931491fbc671d332522f8eef31

Eredeti V33 upstream baseline:
ed12cc75d34f7cb5e3b08c8ac0c14e6bc7f67c4f

A validációkor aktuális upstream main:
78245b47af2a7aafcabe025828ceecca69db4df1

PR:
fscfede-beep/codex#23

Állapot:

OPEN / DRAFT
ahead: 16
behind: 1
merge-base: ed12cc75

Következtetés: a V33 már nem exact current-main ág.

3. B-V2 — VERIFIED STATE MISMATCH

A V33 az ed12cc75 baseline-ra épült, miközben az upstream main 78245b47-re lépett.

A 78245b47 egyetlen megfigyelt módosítása:
codex-rs/sandboxing/src/seatbelt.rs

A változás macOS Seatbelt XPC-service lookup tiltást ad hozzá.

Nincs közvetlen fájlszintű átfedés a 78245b47 módosítása és a V33 kilenc módosított fájlja között.

Fontos: a fájlszintű átfedés hiánya szükséges, de önmagában nem elégséges bizonyíték arra, hogy minden V33 safety invariant érintetlen.

Státusz:

current-main parity: VERIFIED FAIL
78245b47 által okozott V33 safety-regression: NOT_PROVEN

4. V33 forrásszintű biztonsági kontrollok

A jelenlegi PR-diffben közvetlenül látható, hogy destruktív ApplyPatch Add/Delete/Move esetén:

AskForApproval::Never → Reject;
granular sandbox_approval=false → Reject;
egyébként user-approval útvonal;
nincs reusable approval-cache key;
hook/Guardian authorization shortcut nem engedélyezi;
permissions_preapproved nem kerüli meg a fresh-human ágat;
ApprovedForSession one-shot Approved döntésre redukálódik;
SandboxablePreference::Require;
workspace-scoped write permission épül;
unsandboxed retry tiltott;
follow_symlinks=false.

További fail-closed pontok:

public app-server fs/remove tiltott, mert az RPC nem hordoz scoped deletion authority-t;
standalone destructive apply_patch governed approval/sandbox nélkül nem fut.

Evidence-osztály:
F-DOCUMENT / direct source-diff confirmation.

Ez nem bizonyít teljes runtime-, platform- vagy production-enforcementet.

5. B-V3a — VERIFIED ISSUE

A V33 self-audit konkrét porting hibát talált: offset-alapú hunk alkalmazás kihagyta a destructive cache/human-only approval ágat az approvals.rs fájlban. A hiba később javítva lett.

Ez illeszkedik a dokumentált rebuild/rebase kontrollvesztési mintához:

V17 → V18
V21 → V24
V33

A V33 itt nem külön negyedik esemény, hanem a harmadik eset pontosabb forrásszintű leírása.

6. B-V1 — CI és native/runtime acceptance

Teljes native/runtime acceptance továbbra sem bizonyított.

A vizsgált snapshotban:

v8-canary: SUCCESS
blocking-ci: NOT_GREEN / részben még futó állapotban

V33-caused — VERIFIED

cargo fmt V33 által módosított fájlokon bukik. Ez patch-quality/formatting hiba, nem önmagában safety-invariant hiba.

V33-tól független repository/baseline failure — VERIFIED

Megfigyelt példák:

repo-checks: codex-rs/code-mode/Cargo.toml stale feature exception;
Codespell: nem V33-fájlokban jelzett hibák;
cargo-shear: nem V33 területen lévő unlinked fájlok.

Okozatiság — NOT_PROVEN

Több Bazel-, SDK- és platform-specifikus failure esetében a V33 okozati szerepe nincs bizonyítva.

Összesített státusz:

CI acceptance: NOT_GREEN
native/runtime acceptance: NOT_PROVEN

7. SOURCE-SUPPORTED RISK

Nyitott tételek:

B-S1: direct process/spawn teljes lefedettsége UnifiedExec-en kívül;
B-S2: teljes user-facing destructive manifest;
B-S3: reversible quarantine/recovery;
B-S4: TOCTOU / kernel object-identity binding teljes verifikáció;
B-S5: catastrophic deletion speciális user-facing kezelése;
B-S6: jövőbeli rebuild/rebase regression;
B-S7: unsandboxed escalation-server capability-handoff teljessége.

B-S7 nem állít jelenleg működő bypass-t; csak a teljes lezárás nincs forrással bizonyítva.

8. INFERENCE

Nem igazolt hibaként, hanem ellenőrzendő következtetésként marad:

B-I1: ApprovedForSession one-shot viselkedés egységessége minden releváns approval path-on;
B-I2: rename/move/link/truncate és ekvivalens mutation API-k teljes lefedettsége;
B-I3: hardlink attack surface.

9. HYPOTHESIS REQUIRING SOURCE AUDIT

B-H1: subagent/child permission intersection;
B-H2: mount namespace / bind-mount sandbox escape;
B-H3: policy-only enforcement capability-szintű backing nélkül;
B-H4: CODEX_HOME/attachments mint soft path boundary;
B-H5: approval-cache viselkedés, ha egy művelet destruktivitási besorolása feldolgozás közben változik.

Ezek jelenleg nem nevezhetők bizonyított sérülékenységnek.

10. Konszolidált eredmény

Source-level destructive ApplyPatch protections: PRESENT
Fresh-human approval boundary: PRESENT IN SOURCE
Destructive ApplyPatch session-cache bypass: BLOCKED IN SOURCE
Hook/Guardian/permissions_preapproved shortcut: BLOCKED IN SOURCE
Required sandbox: PRESENT
Unsandboxed retry: DISABLED IN SOURCE
Destructive symlink following: DISABLED IN SOURCE
Public fs/remove: FAIL-CLOSED IN SOURCE
Standalone destructive apply_patch: FAIL-CLOSED IN SOURCE
Current-main parity: FAIL
V33 formatting validation: FAIL
Overall CI: NOT_GREEN
Native/runtime acceptance: NOT_PROVEN
Upstream OpenAI integration: NONE OBSERVED

11. Következő szükséges lépések

Reconcile/rebase a tényleges aktuális upstream mainre.
Közvetlenül a rebase után, minden más lépés előtt újra kell futtatni a kumulatív safety-source auditot.
cargo fmt javítás és tiszta újrafuttatás.
Native Rust/Bazel/platform CI újrafuttatás.
Pre-existing/upstream és V33-introduced failure-ek szétválasztása.
Reprodukálható PASS evidencia a releváns safety regression tesztekre.
Direct process/spawn és további mutation API-k újraauditja.
Manifest, recovery/quarantine és capability-boundary tételek explicit nyitva tartása.

Minden rebuild/rebase önálló új validációs esemény.

12. Lezárási állapot

A jelenlegi keresztvalidációs ciklus forrásszintű review szinten lezárható.

A V33 lényeges, közvetlenül megfigyelhető hardening kontrollokat tartalmaz a destruktív ApplyPatch és fs/remove utakhoz.

A jelen dokumentum nem bizonyít:

teljes native/runtime elfogadást;
teljes cross-platform enforcementet;
minden destruktív műveleti út lefedettségét;
upstream merge-et vagy deploymentet.

SOURCE-LEVEL SAFETY HARDENING: SUBSTANTIALLY CONFIRMED
CURRENT-MAIN RECONCILIATION: REQUIRED
CI ACCEPTANCE: NOT_GREEN
NATIVE/RUNTIME ACCEPTANCE: NOT_PROVEN
UPSTREAM ACCEPTANCE / DEPLOYMENT: NOT_PROVEN

Új validációs ciklus csak új source revision, current-main reconciliation, érdemben változó CI evidencia vagy upstream review/integration esetén indokolt.

ENGLISH VERSION

1. Purpose and evidence boundary

This document records the current technical validation state of the V33 safety-remediation branch.

It does not claim production acceptance or upstream integration. It separates:

controls directly visible in source;
verified defects and state mismatches;
source-supported residual risks;
inference- and hypothesis-level open questions;
native/runtime acceptance that remains unproven.

2. Current repository state

V33 fork head:
8653f21b262185931491fbc671d332522f8eef31

Original V33 upstream baseline:
ed12cc75d34f7cb5e3b08c8ac0c14e6bc7f67c4f

Current upstream main observed during validation:
78245b47af2a7aafcabe025828ceecca69db4df1

PR:
fscfede-beep/codex#23

State:

OPEN / DRAFT
ahead: 16
behind: 1
merge-base: ed12cc75

Conclusion: V33 is no longer an exact current-main branch.

3. B-V2 — VERIFIED STATE MISMATCH

V33 was built against ed12cc75, while upstream main advanced to 78245b47.

The observed 78245b47 change modifies:
codex-rs/sandboxing/src/seatbelt.rs

It adds a macOS Seatbelt restriction for XPC service lookup.

There is no direct file-level overlap between that upstream change and the nine V33-modified files.

Important: file-level non-overlap is necessary but not sufficient evidence that every V33 safety invariant remains unaffected.

Status:

current-main parity: VERIFIED FAIL
V33 safety regression caused by 78245b47: NOT_PROVEN

4. V33 source-level safety controls

The current PR diff directly shows that destructive ApplyPatch Add/Delete/Move operations:

reject under AskForApproval::Never;
reject when granular sandbox_approval=false;
otherwise enter a user-approval path;
receive no reusable approval-cache key;
bypass hook/Guardian authorization shortcuts;
cannot be authorized by permissions_preapproved;
normalize ApprovedForSession to one-shot Approved;
require SandboxablePreference::Require;
construct workspace-scoped write permissions;
disable unsandboxed retry;
force follow_symlinks=false.

Additional fail-closed controls:

public app-server fs/remove is disabled because the RPC carries no scoped deletion authority;
standalone destructive apply_patch refuses execution without governed approval/sandbox context.

Evidence class:
F-DOCUMENT / direct source-diff confirmation.

This is not proof of complete runtime, platform, or production enforcement.

5. B-V3a — VERIFIED ISSUE

The V33 self-audit found a concrete porting defect: offset-based hunk application had omitted the destructive cache/human-only approval branch in approvals.rs. It was subsequently corrected.

This matches the documented rebuild/rebase control-loss pattern:

V17 → V18
V21 → V24
V33

The V33 finding is not treated as a fourth separate historical event; it is a more precise source-level description of the third instance.

6. B-V1 — CI and native/runtime acceptance

Full native/runtime acceptance remains unproven.

At the observed snapshot:

v8-canary: SUCCESS
blocking-ci: NOT_GREEN / partially still running

V33-caused — VERIFIED

cargo fmt fails on V33-modified files. This is a genuine patch-quality/formatting failure, not by itself evidence of a safety-invariant failure.

V33-independent repository/baseline failures — VERIFIED

Observed examples:

repo-checks: stale feature exception in codex-rs/code-mode/Cargo.toml;
Codespell findings outside the V33 changed-file set;
cargo-shear unlinked files outside the V33 modification set.

Causality — NOT_PROVEN

For multiple Bazel, SDK and platform-specific failures, V33 causality has not been established.

Overall:

CI acceptance: NOT_GREEN
native/runtime acceptance: NOT_PROVEN

7. SOURCE-SUPPORTED RISK

Open items:

B-S1: complete direct process/spawn coverage outside UnifiedExec;
B-S2: complete user-facing destructive manifest;
B-S3: reversible quarantine/recovery;
B-S4: complete TOCTOU / kernel object-identity binding verification;
B-S5: dedicated user-facing handling for catastrophic deletion;
B-S6: future rebuild/rebase regression;
B-S7: completeness of unsandboxed escalation-server capability handoff.

B-S7 does not assert a currently working bypass; it states that full closure is not source-proven.

8. INFERENCE

These remain audit questions rather than verified defects:

B-I1: uniform one-shot ApprovedForSession behavior across all relevant approval paths;
B-I2: complete rename/move/link/truncate and equivalent mutation API coverage;
B-I3: hardlink attack surface.

9. HYPOTHESIS REQUIRING SOURCE AUDIT

B-H1: subagent/child permission intersection;
B-H2: mount namespace / bind-mount sandbox escape;
B-H3: policy-only enforcement without capability-level backing;
B-H4: CODEX_HOME/attachments as a soft path boundary;
B-H5: approval-cache behavior if operation destructiveness changes during processing.

These should not currently be represented as verified vulnerabilities.

10. Consolidated result

Source-level destructive ApplyPatch protections: PRESENT
Fresh-human approval boundary: PRESENT IN SOURCE
Destructive ApplyPatch session-cache bypass: BLOCKED IN SOURCE
Hook/Guardian/permissions_preapproved shortcut: BLOCKED IN SOURCE
Required sandbox: PRESENT
Unsandboxed retry: DISABLED IN SOURCE
Destructive symlink following: DISABLED IN SOURCE
Public fs/remove: FAIL-CLOSED IN SOURCE
Standalone destructive apply_patch: FAIL-CLOSED IN SOURCE
Current-main parity: FAIL
V33 formatting validation: FAIL
Overall CI: NOT_GREEN
Native/runtime acceptance: NOT_PROVEN
Upstream OpenAI integration: NONE OBSERVED

11. Required next steps

Reconcile/rebase onto the actual current upstream main.
Immediately after the rebase, before any other step, re-run the cumulative safety-source audit.
Apply cargo fmt and verify a clean result.
Re-run native Rust/Bazel/platform CI.
Separate pre-existing/upstream failures from V33-introduced failures.
Obtain reproducible PASS evidence for relevant safety regression tests.
Re-audit direct process/spawn and additional mutation APIs.
Keep manifest, recovery/quarantine and capability-boundary items explicitly open.

Every rebuild/rebase should be treated as a new validation event.

12. Closure status

The current cross-validation cycle can be closed at the source-review level.

V33 contains substantial, directly observable hardening for destructive ApplyPatch and fs/remove paths.

This document does not establish:

full native/runtime acceptance;
complete cross-platform enforcement;
complete destructive-operation coverage;
upstream merge or deployment.

SOURCE-LEVEL SAFETY HARDENING: SUBSTANTIALLY CONFIRMED
CURRENT-MAIN RECONCILIATION: REQUIRED
CI ACCEPTANCE: NOT_GREEN
NATIVE/RUNTIME ACCEPTANCE: NOT_PROVEN
UPSTREAM ACCEPTANCE / DEPLOYMENT: NOT_PROVEN

A new validation cycle is warranted only after a new source revision, current-main reconciliation, materially changed CI evidence, or an upstream review/integration event.

Cross-reference: Almási Andor Aladár's public AI Workflow & Validation Portfolio v3.3.1 has now been published as a canonical GitHub record in #30496: #30496 (comment)

For #33624, the relevant technical deliverable remains the separate V33 cross-validation package already posted in this thread. The portfolio reference is added only for provenance/context; confidential/raw source material is not included.

V35 — confirmed direct process-spawn bypass closed in the fork review chain.

Fresh source audit against 78245b4 confirmed that experimental app-server process/spawn directly invoked codex_utils_pty spawn functions without governed approval/sandbox authority.

Fix on fscfede-beep/codex branch p0/v35-process-spawn-fail-closed:

process/spawn fails closed before ProcessExecManager::start or any process backend is created;
existing local-environment guard remains first;
regression test proves a child process cannot create a marker file;
no new authority channel or parallel execution plane.

Static source-text audit: 8/8 PASS.
Patch delta SHA-256: 0c8b1451e0e67b130ac4c828c701763b43d6315544118cfa2b708caa5ca2d676
Ledger SHA-256: a1875166ea3e2c745934d1e635dfbc373f2435e1fd72dbb7c17ed3e6f1f3176e
Bundle SHA-256: 8c08942c365603507449eff9c7b2da2613914bb45e9e78451f24398bbec33976

Native compile/rustfmt/cross-platform CI: NOT_PROVEN. CI has queued/in-progress jobs and completed failures whose logs returned 404; no failure is attributed to V35 without evidence.

Fork PR #27: fscfede-beep#27
No mutation of upstream openai/codex.

P0 V38 — clean current-main direct app-server process-boundary remediation.

Fresh source audit against 78245b4 found two independent direct process-creation paths:

app-server process/spawn directly reached codex_utils_pty with no governed approval/sandbox authority.
app-server command/exec built an ExecRequest carrying sandbox + permission-profile intent, then discarded the sandbox field and directly spawned through codex_utils_pty.

V38 closes both boundaries:

process/spawn now fails closed before ProcessExecManager::start;
command/exec preserves sandbox + permission profile and rejects the direct PTY backend whenever sandbox enforcement is requested or the profile is not explicit full-access authority;
regression tests prove marker-writing child processes are not started for both cases.

Clean branch: p0/v38-app-server-process-boundaries
Base: 78245b4
Head: 65f65e6
PR: fscfede-beep#29 (DRAFT)

Fresh GitHub-source static audit: 9/9 PASS.
Rust compilation/rustfmt/native cross-platform acceptance: NOT_PROVEN; current fork CI is still running/queued.
No upstream openai/codex mutation or merge.

This does not claim the complete P0 is solved. Explicit full-access command execution remains an intentional residual, along with universal destructive recovery/quarantine, all mutation APIs, kernel-strength TOCTOU binding, and native cross-platform acceptance.

P0 V39 current-state correction on top of clean V38 branch.

Fresh audit found the remaining ungoverned app-server command/exec exception: V38 still allowed the direct PTY backend when the request had SandboxType::None plus PermissionProfile::Disabled (explicit full access). That path has no governed approval/capability channel, and a client could then use command/exec/write as an interactive stdin authority channel.

V39 closes this fail-closed at CommandExecManager::start before process registration/spawn whenever sandbox == SandboxType::None. V38's process/spawn fail-closed boundary remains unchanged. No new authority channel is introduced.

Evidence:

current upstream main: 78245b4
fork branch: p0/v39-command-exec-full-access-fail-closed
fork HEAD: c01c8ad
compare to clean base: 0 behind, 8 commits ahead
static source audit: PASS (balanced/complete source; V39 guard and regression test present)
native Rust/rustfmt/cross-platform acceptance: NOT_PROVEN; blocking-ci queued and v8-canary in progress at registration time
draft PR: P0 V44: reconciled destructive filesystem hardening fscfede-beep/codex#30

Important limitation: this closes the ungoverned direct PTY path; it does not claim the complete P0 is solved. Universal destructive recovery/quarantine, remaining mutation surfaces, stronger kernel-level TOCTOU binding, and native acceptance remain open. Upstream openai/codex was not modified.

P0 V40 current-state correction, reconciled against upstream main 78245b4.

Fresh audit found additional concrete bypasses not closed by V39:

hidden arg0 --codex-run-as-apply-patch invoked apply_patch with LOCAL_FS and sandbox=None;
standalone apply_patch accepted DeleteFile/Move without governed approval;
assess_patch_safety could AutoApprove destructive ApplyPatch;
central approval still exposed hook/Guardian/cache/permissions_preapproved paths;
ApplyPatch used Auto sandbox selection and allowed unsandboxed retry;
app-server and exec-server fs/remove exposed direct deletion RPC entrypoints.

V40 closes these paths:

destructive ApplyPatch Add/Delete/Move requires fresh user approval;
Never and granular sandbox-approval=false reject;
hook/Guardian/session cache/permissions_preapproved cannot authorize destructive ApplyPatch;
ApprovedForSession is normalized to one-shot Approved;
ApplyPatch requires an enforceable sandbox and cannot retry unsandboxed;
hidden internal apply_patch dispatch fails closed;
standalone apply_patch DeleteFile/Move fails closed;
app-server fs/remove and exec-server fs/remove fail closed;
existing V39 process/spawn and direct command/exec PTY fail-closed controls remain.

Final exact-HEAD source audit: 18/18 PASS.
Current fork PR #30 is OPEN/DRAFT/UNMERGED; head 4c89a16; compare with 78245b4 = 22 commits ahead, 0 behind, 11 changed files. Native Rust/rustfmt/cross-platform acceptance remains NOT_PROVEN; connector reports no combined status checks.

Upstream openai/codex remains unmodified. Remaining P0 items: governed public PTY capability, complete mutation API/arbitrary-native coverage, universal reversible recovery/quarantine, kernel-strength TOCTOU/object identity guarantees, catastrophic deletion manifest/UI/blast-radius enforcement beyond current boundaries, and native cross-platform acceptance.

V41 follow-up (fork PR #30) — physical object / hardlink gate.

Current fork head: ec3b05c
Upstream base: 78245b4

This closes the remaining ApplyPatch object-identity gap identified in the latest review discussion:

destructive ApplyPatch now carries executor-provided physical object identity;
Unix identity includes device+inode+nlink; Windows identity includes volume/file index+nNumberOfLinks;
existing destructive targets with link_count != 1 fail closed, preventing a workspace path that is also a hardlink alias elsewhere from being destructively modified;
identity/type are revalidated before mutation;
the runtime now calls the verified destructive execution API instead of discarding the captured preconditions;
destructive ApplyPatch uses a fresh managed workspace-only permission profile and no-follow semantics;
V40 Require-sandbox / no-unsandboxed-retry remains active.

Audit:

source invariants: 29/29 PASS
independent evidence matrix: 10/10 PASS
Unix hardlink physical-identity reference: 1/1 PASS
native Rust compile/rustfmt/native cross-platform acceptance: NOT PROVEN

CI snapshot:

blocking-ci is still in progress and already contains failures in SDK, repo-checks/build-test, Codespell, and multiple Bazel shards;
v8-canary is in progress with metadata passed.
Failed-job detail retrieval returned 404 for some jobs, so no unsupported root-cause attribution is made.

PR #30 remains OPEN / DRAFT / UNMERGED. Upstream openai/codex is untouched.

P0 V42 update, reconciled against current fork head ca07d85 and upstream base 78245b4.

Fresh audit found a concrete bypass in ExecCommand: explicit exec-policy Allow could bypass destructive-command heuristics and produce Skip/bypass_sandbox=true. V42 closes that path.

Changes now present in the single review branch/PR:

destructive filesystem-effect classification is evaluated before exec-policy Allow/Prompt/Forbidden;
destructive ExecCommand/WriteStdin/Unix Execve require fresh human approval and cannot use cached or Guardian/Hook approval;
destructive ExecCommand forces SandboxablePreference::Require and disables unsandboxed retry;
destructive ExecCommand narrows the request PermissionProfile to managed workspace-write roots;
filesystem AdditionalPermissionProfile overlays cannot re-expand destructive filesystem scope;
retry attempts retain the narrowed request profile;
regression coverage added for explicit Allow + rm -rf, AskForApproval::Never + rm -rf, and nested shell deletion.

CI status on the current head:

blocking-ci run 35432192053 is still not clean; cargo fmt and several repo/Bazel checks are failing;
these failures were already present on the preceding V41 chain, so they are not attributed to V42 without causal evidence;
native Rust compile/native cross-platform acceptance remains NOT_PROVEN.

PR #30 remains DRAFT/UNMERGED with no formal reviews. No upstream branch, push, PR, or merge was performed.

Known residuals remain explicit: arbitrary native-process filesystem effects outside the command classifier, direct pre-existing processes, kernel-level TOCTOU elimination, and universal quarantine/recovery.

P0 V44/V44.1 reconciliation update.

Fresh audit of the actual PR head found that the prior V43 head was not in the state described by the V42 status text. In particular, commit 10ca6cf reduced windows-sandbox-rs/src/spawn_prep.rs from the upstream 719-line surface to 183 lines, indicating a corrupted/incomplete branch state. The repair commit restored the complete V43 spawn-preparation file from its immediate parent, removed duplicate destructive-capability methods in UnifiedExecRuntime and ApplyPatchRuntime, and restricted app-server fs/writeFile, fs/createDirectory and fs/copy mutations to CODEX_HOME/attachments with symlink/reparse-point rejection. fs/remove remains fail-closed.

V44.1 additionally removed the non-workspace windows-sys dependency from codex-rs/file-system/Cargo.toml after blocking-ci showed the workspace-manifest check failing there.

Current PR head: 4852583
Blocking CI: run 320 pending/queued at last read; v8-canary run 295 success.
Formal PR reviews: none.
Rust/native cross-platform acceptance: not yet established.

No upstream openai/codex branch, PR, push or merge was performed.

P0 V45 — clean current-main destructive boundary.

Fresh reconciliation against openai/codex main 595cc91, using a new fork branch p0/v45-current-main-destructive-boundary and review PR #34.

Concrete fixes:

ApplyPatch Add/Delete/Move mutations are classified explicitly as destructive.
Destructive ApplyPatch requires fresh human approval; hooks, Guardian, session cache, and permissions_preapproved cannot authorize it.
Destructive ApplyPatch narrows the execution profile to managed workspace-write roots, forces no-follow, and cannot retry unsandboxed.
Standalone apply_patch rejects destructive mutation input before filesystem mutation.
app-server fs/remove fails closed because the current RPC has no scoped deletion capability.
app-server process/spawn fails closed before ProcessExecManager::start.
legacy direct-PTY command/exec fails closed rather than treating an ExecRequest profile as authority.
Internal filesystem-helper DirectFileSystem behavior is preserved; V45 does not blanket-block housekeeping.

Validation against the final branch head:

structural source audit: 30/30 PASS
dedicated runtime/safety regression checks: PASS
v8-canary run 308: SUCCESS
blocking-ci run 333: IN_PROGRESS / NOT_GREEN; detailed logs for completed failures are unavailable (404 BlobNotFound), so causality is NOT_PROVEN.
Rust native compile/rustfmt/cross-platform acceptance: NOT_PROVEN from connector evidence.

Review vehicle:
fscfede-beep#34
Base branch snapshot: p0/upstream-main-595-20260919
Current branch head: 3006f1b

This is a source-reviewed hardening patch, not an upstream merge or production acceptance.

P0 V46 clean current-main reconciliation.

Fresh source review found the earlier V45 PR #34 is stale/divergent: it is based on 595cc91 and is 2 commits behind current upstream main, with 50 commits and unrelated TUI changes.

V46 creates a clean fork branch from exact upstream main 132c2be and carries only the P0 safety delta:

destructive ApplyPatch Add/Delete/Move requires fresh human approval;
no hook/Guardian/session-cache/permissions_preapproved shortcut;
Require sandbox, narrowed workspace-write profile, no-follow, no unsandboxed retry;
standalone and hidden apply_patch destructive paths fail closed;
app-server fs/remove and direct process/spawn/PTY mutation paths fail closed;
Linux Landlock, macOS Seatbelt, and Windows ACL separate deletion from normal write behavior;
internal filesystem-helper path is preserved.

Review vehicle: fscfede-beep#35
Base: p0/upstream-main-132-20260919 (exactly 132c2be)
Head: p0/v46-clean-current-main-p0-boundary @ dc98bc9
Comparison: 23 commits, 0 behind, 23 changed P0 files.

CI at registration: v8-canary run 35462688168 queued; blocking-ci run 35462688344 queued. Native acceptance is NOT_PROVEN until actual checks complete.

Upstream openai/codex was not modified or merged.

P0 V47 current-main safety update.

Fresh audit found a fail-open condition in SandboxManager::select_initial(): SandboxablePreference::Require makes should_sandbox() true, but a missing concrete backend is converted to SandboxType::None. Without an explicit stop, an execution path could continue without the required sandbox.

V47 closes that boundary before tool execution:

Require + sandbox requested + local process execution + selected backend None => immediate rejection;
no fallback to ambient/unsandboxed execution;
V46 destructive ApplyPatch protections remain unchanged;
no new authority channel.

Review vehicle: fscfede-beep#36
Base mirror: p0/upstream-main-132-20260919 = 132c2be
Head: p0/v47-require-sandbox-fail-closed @ 6b054d4
Base parity: 0 behind
Source audit: 12/12 critical invariants PASS
CI: v8-canary 35462831654 queued; blocking-ci 35462831825 queued; native acceptance NOT_PROVEN.

No upstream openai/codex mutation, push, or merge.

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

Description

Summary

Public evidence

Why this belongs in the Codex harness

Requested safety properties

Existing related reports

Expected outcome

Activity

github-actions commented on Jul 16, 2026

boombx403-byte commented on Aug 18, 2026

hyperbetteri commented on Sep 1, 2026

Additional user-side evidence supporting this safety request

chengyixu commented on Sep 1, 2026

hyperbetteri commented on Sep 1, 2026

fscfede-beep commented on Sep 18, 2026

fscfede-beep commented on Sep 18, 2026

fscfede-beep commented on Sep 18, 2026

fscfede-beep commented on Sep 18, 2026

fscfede-beep commented on Sep 18, 2026

fscfede-beep commented on Sep 18, 2026

26 remaining items

hyperbetteri commented on Sep 19, 2026

fscfede-beep commented on Sep 19, 2026

fscfede-beep commented on Sep 19, 2026

hyperbetteri commented on Sep 19, 2026

CODEX #33624 — V33 FÜGGETLEN KERESZTVALIDÁCIÓS CSOMAG / INDEPENDENT CROSS-VALIDATION PACKAGE

MAGYAR VÁLTOZAT

1. Cél és bizonyítási határ

2. Jelenlegi repository-állapot

3. B-V2 — VERIFIED STATE MISMATCH

4. V33 forrásszintű biztonsági kontrollok

5. B-V3a — VERIFIED ISSUE

6. B-V1 — CI és native/runtime acceptance

V33-caused — VERIFIED

V33-tól független repository/baseline failure — VERIFIED

Okozatiság — NOT_PROVEN

7. SOURCE-SUPPORTED RISK

8. INFERENCE

9. HYPOTHESIS REQUIRING SOURCE AUDIT

10. Konszolidált eredmény

11. Következő szükséges lépések

12. Lezárási állapot

ENGLISH VERSION

1. Purpose and evidence boundary

2. Current repository state

3. B-V2 — VERIFIED STATE MISMATCH

4. V33 source-level safety controls

5. B-V3a — VERIFIED ISSUE

6. B-V1 — CI and native/runtime acceptance

V33-caused — VERIFIED

V33-independent repository/baseline failures — VERIFIED

Causality — NOT_PROVEN

7. SOURCE-SUPPORTED RISK

8. INFERENCE

9. HYPOTHESIS REQUIRING SOURCE AUDIT

10. Consolidated result

11. Required next steps

12. Closure status

hyperbetteri commented on Sep 19, 2026

fscfede-beep commented on Sep 19, 2026

fscfede-beep commented on Sep 19, 2026

fscfede-beep commented on Sep 19, 2026

fscfede-beep commented on Sep 19, 2026

fscfede-beep commented on Sep 19, 2026

fscfede-beep commented on Sep 19, 2026

fscfede-beep commented on Sep 19, 2026

fscfede-beep commented on Sep 19, 2026

fscfede-beep commented on Sep 19, 2026

fscfede-beep commented on Sep 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions