OpenAI Codex: verifiable evidence is the real code-review feature

OpenAI introduced the cloud-based Codex research preview on 16 May 2025, powered by codex-1, a version of o3 optimised for software engineering. Tasks ran in separate environments preloaded with the repository. The dated system-card addendum described reading and editing files, running tests and providing citations to terminal logs and files. A later announcement on 15 September 2025 introduced GPT-5-Codex and emphasised code review. These are separate stages in the product history. This historical analysis is published on 25 October 2026. It does not establish current versions, prices, plan limits or availability. The distinction matters because a launch document records what was announced then, not the full behaviour of a service more than a year later. A deployment decision requires a fresh review of the actual configuration and contract. 1

A terminal citation allows a reviewer to inspect what was actually executed rather than accepting a narrative summary. But a successful command can still be irrelevant to the requested change. Require the exact test invocation, its outcome and any skipped checks. Distinguish tests that ran from tests the agent merely recommends running. A verifiable record reduces ambiguity; it does not remove the need to judge whether the evidence supports the claim.

The May system-card addendum described no internet access during task execution after setup. The launch page subsequently recorded a June update allowing users to provide internet access. It would therefore be misleading to repeat the original isolation statement as an enduring product guarantee. Evaluate the actual configured environment, network permissions and dependencies for each pilot. Security properties belong to a dated setup, not to a product name that continues to evolve.

To assess review quality, use changes containing known defects and measure which findings are valid, which important defects are missed and how long developers spend dismissing false alarms. Count severity as well as volume. A reviewer that produces many plausible comments may slow delivery without preventing consequential failures. Keep the authoring agent and the final approval decision separate. Asking the same system to praise its own patch is not an independent review method.

For a Codex evaluation, require more than a statement that tests passed. Each proposed change should identify the tested revision, exact commands, environment assumptions, exit status and relevant output. Distinguish checks actually executed from checks merely recommended or blocked by missing dependencies. Ask for a regression test that fails on the original defect and passes after the fix; otherwise a green suite may never exercise the changed behavior. Keep expected behavior anchored in company knowledge, and apply agent safety when tests need credentials or external services. Treat generated explanations as navigation aids for the reviewer, not substitutes for reproducible evidence about the patch.

A reviewer should inspect whether assertions prove the requirement or simply mirror the new implementation. Look for weakened expectations, deleted coverage, broad mocks and snapshots updated without an explanation. Reproduce the decisive check in a clean environment where feasible, and distinguish product failures from infrastructure failures without automatically excusing either. Include negative cases and compatibility boundaries when the change affects shared behavior. Record how often the evidence packet lets another engineer reach the same conclusion. AI advisory can help define a review acceptance rubric; an AI keynote can explain why plausible test narratives are not assurance. Adoption should depend on independently repeatable checks, not the confidence of a generated summary.