Codex rollback · reviewed 2026-10-03

Verify the final repository state; do not trust a rollback label by itself.

Direct answer: When reverting Codex-generated changes, use Git/status/diff and, where needed, content hashes or tests to verify the repository reached the state you intended. Codex has native safety controls, but any rollback workflow should be judged by the resulting state rather than the UI message alone.

Start with Git as the source of truth for source changes

If the target state is a known Git commit or clean working tree, verify against that target directly. A line-count reversal is not, by itself, proof that file contents are identical.

Public issue reports show why verification matters

An open Codex GitHub issue filed May 20, 2026 reports a rollback/revert diff that was not symmetric with the original edit. Another public report describes an Undo operation leaving a tracked file modified. These are individual issue reports—not evidence of how common the behavior is—but they illustrate the value of checking the final repository state independently.

A practical recovery check

Identify the expected baseline commit/file state.
Inspect git status and git diff.
For high-value files, compare exact file content/hash with the baseline.
Run relevant deterministic tests after restoration.
Confirm unrelated files did not change.

StateHinge hypothesis

The current product thesis is to make accepted-state rollback and restored-hash proof an explicit part of the protected-run record. The local core has rollback evidence; the real host D14 demo is not yet closed.

Primary sources

Limitation

Do not infer from one issue that Codex rollback is generally unreliable. Treat issue reports as examples to test against, not prevalence estimates.