Codex can lose task focus during file operations without mandatory manifest / rollback safeguards

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:

1. Provide Codex a directory containing multiple similar/duplicate files.
2. Give it one known-good example and ask it to locate corresponding related files.
3. Require it to preserve the original task scope while inspecting the directory tree.
4. Continue long enough for multiple reads/comparisons and file operations.
5. Check whether it drifts from the current instruction, confuses source/duplicate files, or performs mutations based on uncertain identification.
6. 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:

1. Mandatory pre-operation inventory + cryptographic hash manifest.
2. Explicit operation mode: READ_ONLY / COPY / MOVE / DELETE.
3. Plan-before-execute separation for every mutation.
4. Hard uncertainty stop: uncertain identity or intent must not trigger a mutation.
5. Recoverable-by-default deletion (quarantine/trash) with restore metadata.
6. Mandatory human approval before bulk or destructive operations.
7. Post-operation audit log including source, destination, hashes, reason, and result.
8. 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.

The issue names no source files, entry points, or existing tests, and says there is no minimal reproducer. Start by locating the runtime paths that permit workspace mutations and any tests around file operations; build a disposable-directory test using a pre-operation manifest, then verify that uncertain or destructive operations stop, require approval, remain recoverable, and produce an audit record.