Codex finishing a task is the start of acceptance, not proof that the change is ready to commit. A safe review must answer three separate questions: what changed, whether the change satisfies the request, and what evidence supports that conclusion.
OpenAI’s current code-review documentation notes that the review pane reflects the Git repository state, not only edits made by Codex. That distinction matters: staged, unstaged, untracked, earlier user work, and the latest assistant turn can represent different scopes. Review the right scope before judging the implementation.
Establish the baseline before reviewing
Start by recording the state you expected Codex to preserve:
- Which branch and repository are open?
- Were there uncommitted changes before the task began?
- Which files or behaviors were in scope?
- What acceptance criteria and validation commands were agreed?
- Did the task permit dependency, configuration, generated-file, or lockfile changes?
If you did not capture the initial state, do not assume every visible line belongs to Codex. Ask it to identify the changes from its latest turn, then compare that claim with Git history and the full working tree.
Choose the correct diff scope
Different review questions require different comparisons:
- Last turn: What did the assistant change most recently?
- Uncommitted changes: What would remain in the working tree if you stopped now?
- Staged changes: What is currently prepared for the next commit?
- Commit: What did one exact commit introduce?
- Branch against base: What would the whole branch contribute to a merge?
The Codex app, CLI, and IDE extension currently offer /review scopes for uncommitted changes, a selected commit, or a branch comparison. A dedicated review reports findings without modifying the working tree; any later request to apply fixes is a separate action under the normal permissions.
You can make the review criteria explicit:
Review the uncommitted changes against the original task. Do not edit files.
Prioritize correctness, regressions, security, accessibility, and missing tests.
For every finding, cite the file and line, explain a realistic failure scenario,
and suggest the smallest repair. Do not invent a problem when the diff does not
support one.Review the file list before individual lines
The file list reveals scope problems faster than a line-by-line reading. Ask why each file changed.
Pay special attention to:
- lockfiles or manifests when no dependency change was requested;
- environment, deployment, permission, or CI configuration;
- generated files that should not be edited by hand;
- locale files when visible copy changed;
- deleted tests, documentation, comments, or error handling;
- media, fixtures, snapshots, or large files that make the diff difficult to inspect;
- files outside the requested feature area.
An unexpected file is not automatically wrong. It is a question that must be answered before commit.
Read the diff in risk order
Do not review every line with equal attention. Start where a small mistake has the largest effect.
- Security and permissions: authentication, authorization, secret handling, file access, network access, command execution.
- Data and compatibility: schemas, migrations, public APIs, serialization, caching, and persistence.
- Control flow: error paths, cleanup, retries, concurrency, timeouts, and fallback behavior.
- User-facing behavior: accessibility, localization, validation, loading, empty, and failure states.
- Tests and documentation: whether they verify the intended behavior instead of merely matching the implementation.
- Style and naming: important for maintainability, but rarely a reason to miss a correctness problem.
For each changed block, ask what input reaches it, what output or side effect it creates, and what happens on failure. Then compare the answer with the original acceptance criteria.
Look for high-signal warning patterns
Common problems in AI-assisted changes include:
- broad refactors wrapped around a narrow fix;
- a new helper that duplicates an existing abstraction;
- exceptions caught and ignored without an observable failure;
- a test that asserts implementation details but not the reported behavior;
- hard-coded paths, locale text, IDs, dates, or credentials;
- validation performed only in the UI while the underlying operation remains unchecked;
- a feature added to one locale or route but not its real counterparts;
- comments or summaries claiming checks ran when no command output exists.
Search for removed code as carefully as added code. A deletion may remove a safeguard even when the new happy path looks cleaner.
Verify behavior with layered checks
Static review cannot replace execution, and a passing build cannot prove the feature works. Use the smallest useful layers:
1. Reproduce the original behavior or failure.
2. Run the focused test that covers the changed path.
3. Run the project's relevant lint and type checks.
4. Build or run a broader suite when shared contracts changed.
5. Exercise the user-facing flow, including one failure or boundary case.Record the exact command, result, and anything skipped. If a failure already existed, preserve evidence rather than automatically dismissing it. Decide whether it blocks this change based on relevance and risk.
Separate findings from questions and preferences
A useful review report distinguishes:
- Finding: Evidence shows a defect or regression with a credible scenario.
- Question: The requirement or repository evidence is insufficient to decide.
- Suggestion: The code is valid, but a smaller or clearer implementation may be preferable.
- Verification gap: A relevant check or environment was unavailable.
This prevents style preferences from burying real problems and prevents uncertainty from being reported as fact.
Ask Codex for prioritized findings, but verify them yourself. A plausible review comment can still misunderstand a caller, invariant, generated file, or framework convention.
Handle unwanted changes safely
Do not restore an entire file simply because one hunk is wrong; the same file may contain user work that predates the task. Identify the ownership of each hunk, preserve unrelated changes, and reverse only the edits you can attribute to this task.
Before accepting an automated revert, inspect its target and scope. For a mixed file, a small corrective edit is often safer than replacing the file with an earlier version.
After fixes, review the new diff again. The first review found problems in one change set; it did not automatically approve the repair.
Use a pre-commit acceptance record
Finish with a short evidence record:
- Requested outcome: one sentence;
- Changed files: expected files and explanation for any surprise;
- Behavior checked: reproduction or manual flow and result;
- Commands run: exact pass or failure status;
- Not checked: unavailable environments, browsers, platforms, or data;
- Residual risk: assumptions and follow-up work;
- Decision: ready to commit, needs repair, or requires user input.
The decision should follow the evidence. Do not commit just to clear the working tree or because the implementation is mostly complete.
To reduce review problems before they happen, use the Codex prompt-writing framework. New users can practice the full loop in the Codex getting-started tutorial. If you work mainly in a terminal, keep the Codex CLI command guide nearby.
Frequently asked questions
Is a clean /review report enough to commit?
No. An automated review can miss requirements, runtime behavior, or project-specific context. Confirm the intended behavior and relevant checks in addition to reading the findings.
Should I review the last turn or all uncommitted changes?
Use the last turn to isolate the latest assistant edit. Use all uncommitted changes to understand what would actually remain in the working tree or enter a commit. Compare both when pre-existing user work exists.
What should I do if tests fail for an unrelated reason?
Keep the command output, confirm whether the failure existed before this change when possible, and state the uncertainty. Do not silently remove, skip, or relabel the failure as a pass.
Can Codex fix the issues it finds?
Yes, if you ask it to, but that starts another modification step under the normal sandbox and approval settings. Review the repair as a new diff rather than assuming the reviewer validated its own fix.