I would judge a Codex change by the diff and the evidence, not by the length of its completion message. A short summary can accompany excellent work; a detailed summary can accompany a calculation nobody ran.
My review habit is to keep three objects visible together: the request, the patch and the check. If they do not describe the same change, the task still needs work.
Start with the repository state
Before a task, inspect git status and the current branch. Existing changes may belong to you, another tool or earlier work. Record that state so a later diff does not become a misleading account of what Codex changed.
In the app, the review pane reflects the repository’s state, including edits made outside Codex. Current scopes include unstaged changes, staged changes, a commit, a branch comparison and the last turn. Choose the view deliberately rather than assuming every visible line belongs to the latest request.
For the fictional campaign-report fix, the expected scope might be one calculation file, one fixture test and the regenerated report. An unrelated homepage edit should prompt a question even if it is harmless. Scope is easier to preserve when you know where you started.
TipRead git status before and after the task; do not use a blanket reset to clean up unfamiliar changes.
Define what the reviewer should look for
A review request is more useful when it names the intended behavior and meaningful risks. For the campaign report, ask whether aggregate CPL uses summed spend and leads, whether zero denominators are handled and whether source data remains unchanged.
This is different from asking whether the code looks good. A concrete criterion helps the reviewer connect implementation details to the business outcome. It also gives a human a basis for deciding whether a finding matters.
Include the relevant base branch or change scope. Reviewing a whole repository for general quality is a different task from checking the small patch you intend to ship. Keep the first review focused enough that findings can be acted on without starting a new project.
TipPut the acceptance criteria beside the review request, not only in an earlier chat.
Run a dedicated Codex review
In supported local clients, /review starts the review workflow. The CLI offers scopes such as uncommitted changes, comparison against a base branch, a selected commit and custom review instructions. The app and IDE expose their supported choices in the interface.
The documented review behavior reports prioritized findings without changing the working tree. A finding is a proposed issue with supporting reasoning, not an automatic patch. Inspect it, ask for evidence when needed and request a focused correction separately.
For an unfamiliar code path, ask the reviewer to explain a concrete failure scenario. “This may be wrong” is less useful than “a zero-lead campaign reaches this division and raises an error.” The latter gives you a behavior to reproduce and a check to preserve.
TipDistinguish a review finding from a verified reproduction of the bug.
Match each check to the risk
A unit test can verify a calculation with known inputs. An integration check can verify that the generator reads the intended file and writes the expected output. A browser or document inspection can reveal clipped labels or unreadable tables. These checks overlap, but none is a universal substitute for the others.
For Cedar Metrics, verify the known totals and overall CPL, then open the generated report. If the change also affects a chart, inspect its axes and labels. A correct number displayed under the wrong heading can mislead the team as effectively as a wrong formula.
Ask Codex to state which checks actually ran and whether any were unavailable. A command that failed because a dependency was missing is not a passing test. Keep the limitation visible in the review and completion note.
TipChoose checks that could detect a meaningful failure introduced by the change.
Read the patch after fixes
A review can lead to a correction, and that correction creates a new patch. Inspect the final diff after the fix rather than relying on the earlier review. Confirm that the intended issue was addressed without changing unrelated behavior.
For content or generated sites, look at both source and output. The source should contain the durable change, and regeneration should produce the expected page. Large generated diffs can hide a small source mistake, so identify the source change before scanning hundreds of output lines.
I would also check whether the explanation matches the code. If the completion note says missing values are reported but the implementation silently substitutes zero, the mismatch deserves resolution before a commit. The narrative should describe evidence, not an aspiration.
TipAfter a material correction, rerun the relevant check rather than repeating every unrelated test.
Stage and commit the intended work
Git’s staging area defines what enters the next commit. Inspect git diff for working changes and git diff --cached for staged changes. Add specific intended paths when the repository contains unrelated work; a broad add can accidentally include files outside the task.
A commit creates a local checkpoint with a message describing the final behavior. For the report fix, a useful message could explain that aggregate CPL now uses weighted totals and handles zero denominators. Avoid a vague message that only says the AI updated things.
Before committing, inspect for accidental credentials, temporary output and unrelated edits. This is a practical final check on the artifact being recorded. It should be tied to the actual diff rather than becoming a long ritual disconnected from the change.
TipRead the staged diff, because the working diff alone does not show exactly what the commit will contain.
Treat push and deployment as separate steps
Pushing sends commits to a remote repository. Depending on the project, a push may also trigger CI, a preview or a production deployment. Understand that repository’s behavior before treating push as merely a backup button.
A pull request can provide another review boundary with a description of the problem, resulting behavior and validation. Keep the description aligned with the final implementation. If the scope changed during development, update the summary rather than preserving an obsolete plan.
For a production site, verify the deployed artifact after the authorized release. A successful local build and a successful deployment are different pieces of evidence. The same principle applies to a scheduled report whose output must reach a particular destination.
TipCheck what the target branch triggers before pushing a change there.
Where review workflows go wrong
The first failure is reviewing the wrong diff: all local changes instead of the intended patch, or an old commit instead of the final correction. The second is accepting findings without checking their reasoning. Automated review can be useful and still be mistaken.
The third is letting green tests stand in for the whole outcome. Tests can cover the wrong behavior or miss a broken layout. Pair them with the inspection appropriate to the deliverable. For the campaign report, that includes the meaning of the metric labels.
Keep the request, patch and check aligned through the final commit. That is a manageable review standard even for a small team. Which claim in the completion note can you point to a specific check to support?
How to set it up
Inspect the starting state
Read git status and identify the branch and preexisting changes.
Review the intended diff
Use /review with a suitable scope and concrete acceptance criteria.
Resolve and verify
Evaluate findings, make focused corrections and rerun checks that cover the changed behavior.
Create the checkpoint
Inspect and stage only intended changes, review the staged diff and commit. Push or deploy according to the authorized release workflow.
Frequently asked questions
Does /review edit files?
The documented review workflow reports prioritized findings without changing the working tree.
Does the app diff include my own edits?
Yes. It reflects repository state, not only Codex-authored changes.
What does staging do?
It selects the changes that will enter the next Git commit.
Is a commit the same as a push?
No. A commit records a local checkpoint; a push sends commits to a remote repository.
Can pushing deploy the site?
Yes, if the repository is configured that way. Check the target branch’s automation.
Should I accept every review finding?
Inspect its evidence and failure scenario. Automated reviewers can make mistakes.
Are passing tests enough?
Use checks appropriate to the outcome, including diff and visual inspection when needed.
What belongs in the completion note?
The resulting behavior, relevant changed files, checks actually run and material limitations.
Sources & further reading
ChatGPT and Codex change quickly. This page was last reviewed September 22, 2026; verify time-sensitive details against the official docs above before relying on them.