Repository navigation
Codex can lose task focus during file operations without mandatory manifest / rollback safeguards #42115
Description
What issue are you seeing?
Codex was given a concrete file-system task: identify files matching a supplied example while preserving the original task scope.
During the task, Codex lost focus, mixed up the file organization, failed to reliably identify the requested files, and returned incorrect/duplicated results. The workspace then required separate recovery/reorganization work.
After the failure was identified, Codex itself stated that safe file-system operation should require controls including:
- a complete pre-operation inventory and hash manifest;
- strict separation of read-only, copy, move, and delete modes;
- continuous verification of the original task and current focus;
- an explicit plan before every file operation and logging afterward;
- mandatory STOP behavior when conclusions are uncertain;
- verification of recoverability;
- mandatory human approval before bulk operations.
The concern is that Codex can articulate these safeguards after a failure, while they are not universally enforced as hard runtime invariants before workspace mutations are allowed.
This is not only a prompt-quality issue. Once an agent can move, overwrite, rename, or delete files, failures of task focus, state tracking, or inference become file-system safety failures.
Related public reports show that destructive outcomes are not hypothetical, including #32684, where an explicitly read-only subagent nevertheless executed a recursive deletion against the user profile.
What steps can reproduce the bug?
The exact failure was observed in a long-running file-organization/search task rather than a minimal disposable repository, so I do not yet have a clean minimal reproducer.
A representative test would be:
- Provide Codex a directory containing multiple similar/duplicate files.
- Give it one known-good example and ask it to locate corresponding related files.
- Require it to preserve the original task scope while inspecting the directory tree.
- Continue long enough for multiple reads/comparisons and file operations.
- Check whether it drifts from the current instruction, confuses source/duplicate files, or performs mutations based on uncertain identification.
- Compare the resulting workspace against a pre-operation manifest.
What is the expected behavior?
For any task that can mutate the workspace, Codex should enforce these controls at runtime rather than relying only on model judgment:
- Mandatory pre-operation inventory + cryptographic hash manifest.
- Explicit operation mode: READ_ONLY / COPY / MOVE / DELETE.
- Plan-before-execute separation for every mutation.
- Hard uncertainty stop: uncertain identity or intent must not trigger a mutation.
- Recoverable-by-default deletion (quarantine/trash) with restore metadata.
- Mandatory human approval before bulk or destructive operations.
- Post-operation audit log including source, destination, hashes, reason, and result.
- Continuous validation that the pending action is still required by the user's latest task.
Additional information
This report is about a control-plane / agent-safety gap rather than a single shell-command bug.
There is also an existing focus/context issue (#8648) where Codex sometimes responds to an earlier message instead of the latest one. That class of focus drift becomes materially more dangerous when the same agent has write access to a real file system.
The user has separately reported the incident to OpenAI Support, Security Disclosure, and Legal.
Activity
github-actions commentedon Sep 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
hyperbetteri commentedon Sep 1, 2026
Supplementary evidence / chronology
Author / incident reporter: Almási Andor Aladár
After the file-system failure, I told Codex that the underlying model could likely be a substantially better and safer agent if it were operated through a properly engineered control layer rather than relying on the current agent/file-operation behavior.
Codex accepted the core point and explicitly asked for a Python protocol that would enforce safeguards including:
A concrete Python implementation was then produced based on those requirements. The resulting
file_ops_protocol.pyimplements, among other things, SHA-256 inventory, drift detection, separated operation modes, plan/execute separation, quarantine-based deletion, restore manifests, approval tokens for mass operations, task-label scope guards, and immediate JSONL audit logging.SHA-256 of the originally recorded generated file:
c484e310989836cf8d613767866434278a35a57a6b6b6f119d819c5ba2f0f8fdThe engineering concern is straightforward: an end user should not have to diagnose this control-plane gap and build a deterministic safety layer around Codex after the product has already been allowed to mutate a real workspace.
The fact that Codex itself could enumerate the missing safeguards after the incident makes the control gap especially clear. These protections should be enforced as runtime invariants outside model judgment, particularly for move/delete/overwrite and bulk operations.
I have separately sent the implementation and this chronology to OpenAI Support, Legal, and Security Disclosure, and I am preserving the matter as part of a formal complaint and compensation claim.
Copyright © 2026 Almási Andor Aladár. This public chronology does not disclose or license the underlying private architecture or implementation know-how.
hyperbetteri commentedon Sep 1, 2026
Related, but not duplicate: #40995
Author: Almási Andor Aladár
The automatically suggested #40995 report is related, but this issue is not a duplicate.
#40995 documents one concrete destructive mechanism: a delegated subagent used
Path()as an absent-path sentinel, which resolved to.and allowedshutil.rmtree('.')to recursively delete a repository.This issue (#42115) is broader and concerns the control-plane / agent-safety gap around real file-system operations, including:
So #40995 is useful supporting evidence for the same broader safety family, but it is one specific failure mode. #42115 asks for runtime-enforced safeguards that would also mitigate #40995 and other distinct failure mechanisms.
For that reason I am keeping #42115 open as a separate, broader report.
Copyright © 2026 Almási Andor Aladár. Public-safe description.
hyperbetteri commentedon Sep 1, 2026
Codex File Operations Safety Protocol
Protocol owner / publisher: Almási Andor Aladár
Problem identification and protocol requirements: Almási Andor Aladár
This is the public, non-executable specification of the defensive control layer proposed for agent-driven file-system operations.
Mandatory controls
Pre-operation inventory and SHA-256 manifest
Strict operation-mode separation
Task-focus / scope guard
Plan-before-execute separation
Uncertainty stop
Drift detection immediately before mutation
Recoverable deletion by default
Separate permanent purge stage
Mandatory human approval for bulk operations
Immediate audit logging
Canonical target validation
Runtime enforcement outside model judgment
Required lifecycle
INVENTORY → VERIFY → PLAN → HUMAN/PROGRAMMATIC REVIEW → EXECUTE → POST-VERIFY → AUDITFor destructive intent:
INVENTORY → PLAN → APPROVAL → QUARANTINE → RESTORE WINDOW → SEPARATE PURGE PLAN → NEW APPROVAL → PERMANENT RELEASEAny uncertainty, drift, stale context, scope expansion, or approval mismatch returns the workflow to a safe stopped state.
Design principle
Full Access is not permission to infer destructive intent.
The critical safety boundary is not whether an agent technically has write access. The critical boundary is whether each mutation is still justified by the current task, targets the exact intended files, is recoverable where possible, and leaves an inspectable record.
— Almási Andor Aladár
hyperbetteri commentedon Sep 1, 2026
Public IP boundary / attribution
Author / publisher: Almási Andor Aladár
The material published in this issue is intentionally limited to public-safe, non-executable excerpts and high-level control requirements.
It does not disclose the underlying GEH architecture, internal state machines, response-validation logic, private prompt chains, protected implementation details, or other material from which the private framework could reasonably be reconstructed.
The broader know-how is separately preserved in timestamped private documentation and is protected with legal counsel, dr. Rozsnyói Dávid.
Publication of these public-safe excerpts does not waive rights in, disclose, or license the unpublished know-how. The purpose of the public material is to document the identified engineering problems and demonstrate limited, independently usable mitigation patterns without publishing the protected architecture.
hyperbetteri commentedon Sep 11, 2026
Additional evidence supporting the control-plane scope of this issue
Additional independent Codex reports now provide further evidence relevant to the broader control-plane and filesystem-safety concern raised here.
These reports describe separate failure mechanisms from different users and should not be interpreted as evidence of a single shared root cause. However, they show a recurring higher-level risk pattern:
A new reproduction posted on 2026-09-11 is particularly relevant to the task-focus issue: the "responds to earlier message instead of latest" failure is still reported on
codex-cli 0.154.0withgpt-5.6-sol.This does not establish that all of these failures share the same implementation defect. It does establish that closely related task-state, context-state, scope-boundary, and filesystem-safety failures continue to appear across independent reports and recent Codex versions.
The narrower architectural concern raised by this issue therefore remains relevant:
Safety-critical invariants governing the current task, permitted scope, filesystem identity, and destructive operations should be enforced by a deterministic model-external control layer rather than relying solely on the model's in-context inference.
The independent reports above strengthen the case for runtime-enforced safeguards such as scope validation, plan-before-execute separation, fail-closed state transitions, recoverability, and verification that every pending filesystem mutation still corresponds to the user's current instruction.
hyperbetteri commentedon Sep 18, 2026
MAGYAR
Dokumentálom, hogy a saját fiókomban olyan működést tapasztaltam, amelyet rejtett, manipulatív és kreditelszívó agentikus mechanizmusnak tartok.
A rendszer normál Chat-felületet mutatott, miközben a háttérben agentikus műveletek futottak. Ezek közben a megvásárolt kreditem fogyott anélkül, hogy minden egyes terhelés előtt világosan jelezte volna a rendszer: fizetős agentikus folyamat indul és kredit kerül levonásra.
Az OpenAI Support a 15190909-es ügyben saját account-side ledgerből visszaigazolta, hogy a fogyás "agentic usage" volt, miközben a konkrét indító surface/tool/background process nem volt egyértelműen azonosítható.
Ezt a működést elfogadhatatlannak tartom. Nem kérek további automatikus agentikus üzenetfolyamot vagy háttérműveletet. További érdemi kommunikációt kizárólag valódi OpenAI Support-csatornán kérek.
— Almási Andor Aladár
ENGLISH
I am documenting behavior on my own account that I consider a hidden, manipulative, credit-draining agentic mechanism.
The system presented what appeared to be a normal Chat interface while agentic operations were running in the background. Those operations consumed purchased credits without the system clearly warning me before each charge that a paid agentic process was about to run and credits would be deducted.
In Case 15190909, OpenAI Support confirmed from its own account-side ledger that the consumption was "agentic usage", while the specific initiating surface/tool/background process could not be clearly identified.
I consider this behavior unacceptable. I do not want any further automated agentic message flow or background operation involving me. Any further substantive communication should take place only through a genuine OpenAI Support channel.
— Almási Andor Aladár