Codex Git Workflows & Collaboration Part 02 | What to Check After Codex Says 'Done': Diffs, Reviews, Pull Requests and Evidence

Codex may finish a task with a message like this:

Done. Fixed the retry bug and added tests.

That is a useful summary of what the agent believes it changed. It is not enough to decide whether the change should merge.

Take a payment-retry fix. The reviewer still needs to know which files changed, whether those changes are staged or committed, which tests actually ran, whether the review covered the latest diff, and what the repository requires before merge. If another commit lands after the tests or approval, some of that evidence may already describe an older version of the code.

Codex exposes much of this through diffs, review comments, terminal logs, test output, Git information and pull-request context.[1][3][4] The review becomes easier once each result is tied to the change it actually examined.

Start with the exact change

An uncommitted working tree can hold staged, unstaged and untracked changes at the same time. Before reviewing behaviour, establish which state is in scope.

The Codex app provides Git summaries, diffs, changed files and pull-request comments.[3][4] The terminal is often enough to confirm the same state:

git status --short --branch
git diff
git diff --staged

git status --short --branch shows the current branch and a compact view of staged, unstaged and untracked files. git diff shows working-tree changes that are not staged. git diff --staged shows the index relative to HEAD.

After the work is committed, review can target that commit or the head branch against its intended base. A pull request makes those boundaries explicit: base, head and changed files are visible to everyone reviewing the change.

For the retry task, suppose the diff contains:

src/payment/retry.ts
tests/payment/retry.test.ts

The next step is to read the hunks. Check the retry condition, error handling, the added test path and any unrelated files that travelled with the change. Codex supports in-thread review and diff comments; later app updates added inline and detached review modes, Git summaries and more pull-request context.[3][4]

The diff has still not executed the code or exercised its runtime dependencies.

Figure 1 | Diff, Git state, tests and checks, review, and pull-request policy expose different parts of the closure decision. Each result keeps the limits of the thing that produced it.

Read test results with their scope

Codex can run test harnesses, linters and type checkers, and can return terminal logs and test output with the task.[1] When one of those reports PASS, the command or job behind the result matters as much as the label.

For example:

pytest tests/payment/test_retry.py -q

If that command passes, a defensible statement is:

The focused payment retry tests passed in this run.

It says nothing about payment paths the test did not exercise, production configuration, external dependencies or timing failures.

GitHub checks add another layer. CI builds, tests, code scanning and deployment checks can all report against a commit, and branch protection can require selected checks before merge.[6][7] GitHub accepts success, skipped and neutral as successful conclusions for required checks.[6]

A required-check gate can therefore be satisfied even when a particular test path was skipped. If that path matters to the decision, inspect the workflow or job rather than relying on the status label alone.

Review findings and merge policy answer different questions

Codex code review can compare a pull request’s stated intent with the diff, reason over surrounding code and dependencies, and run code or tests while validating behaviour. On GitHub, @codex review can request that review explicitly.[2]

This can surface problems outside the focused test: implementation drift, regressions elsewhere, missing error paths, changed dependency interactions or security concerns. OpenAI describes Codex code review as an additional reviewer rather than a replacement for human review.[2] If the review reports no findings, that is the result to record; it does not establish that no bug exists.

The pull request adds repository enforcement. GitHub reviews can be Comment, Approve or Request changes. Rulesets and branch protection can require approvals, Code Owner review, status checks or an up-to-date branch before merge.[5][7]

Those are separate mechanisms. A reviewer may request changes without that state blocking merge in every repository; the configured rules decide whether it does.[5] Likewise, a repository that does not require an integration test, security scan or owner approval will not gain those checks merely because every configured merge requirement is satisfied.[7][8]

Codex also has a feature called Auto-review, but it belongs to a different workflow. For requests that cross the sandbox boundary, Auto-review can send the planned action and recent context to an auto-approval subagent that decides whether the action can proceed.[9] That is an approval mechanism for agent actions, not pull-request code review.

After another push, reassess the evidence

Suppose commit A has:

focused tests     PASS
review            APPROVED
required checks   PASS

A reviewer leaves feedback, the agent fixes it, and commit B is pushed.

The code under review has changed. Test output from A does not automatically cover B, and GitHub requires required status checks to apply to the latest commit SHA rather than an older head.[6]

Approvals can also depend on repository policy. A repository may dismiss stale approvals when new commits change the diff, or require approval of the most recent reviewable push.[7] Neither behaviour should be assumed unless that policy is configured.

Figure 2 | Commit B changes the artefact. Some checks may need to run again and some reviews may need to be repeated, depending on the change and repository policy. Evidence from A does not automatically cover B.

Match the review process to integration risk

Scratch work that will never enter a shared branch may need little more than a local diff and the checks relevant to the experiment. A one-line authentication or migration change can deserve substantially more review, even when the diff is tiny.

Situation	Sensible review path	Why
Throwaway experiment that will not enter a shared branch	Local diff plus the checks needed for the experiment	There is no shared integration boundary
Small, low-risk change in a single-owner repository	Diff, Git state and focused tests or lint	A full PR process may add more waiting than useful evidence
Change intended for a shared main branch	Branch or PR, review and repository checks	The change needs an explicit integration boundary
Parallel agent work	Keep each unit as a clear change set, then let an integration owner reconcile them	Independent execution does not remove integration work
Shared configuration, authentication, migrations or payments	PR, appropriate owner review and checks matched to the risk	The change can affect shared behaviour or data
Release or production path	Repository policy gates, evidence for the latest artefact and an explicit merge owner	The release decision needs evidence beyond the agent’s completion message

Before merge, check that the review still answers these questions:

• Which branch, commit or working-tree state is in scope, and does its diff match the task?
• Which behaviours were actually exercised by tests, lint, type checks or manual validation?
• Does the current review apply to the latest change, including any follow-up push?
• Which requirements does the repository enforce, and which risks sit outside those rules?
• Who owns the merge decision?

If one of those answers is missing, that identifies the next piece of evidence to collect before merging.

References

1. OpenAI, Introducing Codex. Test harnesses, linters, type checkers, terminal logs and test outputs as reviewable task evidence.
2. OpenAI, Introducing upgrades to Codex. Codex code review, @codex review, review behaviour and the recommendation to use Codex as an additional reviewer.
3. OpenAI, Introducing the Codex app. In-thread review of agent changes, diff comments and Git-oriented collaboration.
4. OpenAI, ChatGPT & Codex changelog. Review modes, Git summary and in-app pull-request workflow.
5. GitHub Docs, About pull request reviews. Comment, Approve, Request changes and required-review behaviour.
6. GitHub Docs, Status checks and Troubleshooting required status checks. Check conclusions and latest-commit-SHA requirements.
7. GitHub Docs, About protected branches. Required reviews, Code Owners, required checks, stale approvals and latest-push approval.
8. GitHub Docs, Merging a pull request. Repository requirements that govern merging into the upstream branch.
9. OpenAI, Running Codex safely at OpenAI. Auto-review as an approval mechanism for requests that cross the sandbox boundary.