Review Workflow

Codex finished a task and says it is done. The thread shows green checkmarks. But you have no idea if the changes are actually correct, if the edge cases are covered, or if the code matches your team’s style. Blindly merging AI-generated code is how subtle bugs get into production. The review workflow is where you turn Codex’s raw output into code you can confidently ship.

What You’ll Walk Away With

• Mastery of the App’s review pane: diff views, scope toggles, and navigation
• The inline comment workflow for giving Codex targeted feedback
• File-level, hunk-level, and full-diff staging and reverting
• A process for iterating on Codex’s work until it meets your standards
• The CLI’s /review command for local code review
• GitHub-based review for Cloud-generated PRs

The Review Pane (App)

The Codex App’s review pane is the most feature-rich way to review changes. It works like a built-in code review tool — think GitHub PR review, but for local work.

What It Shows

The review pane reflects the state of your Git repository, not just what Codex edited. It shows:

• Changes made by Codex
• Changes you made yourself
• Any other uncommitted changes in the repo

By default, it focuses on uncommitted changes. You can switch the scope to:

Scope	What it shows
Uncommitted changes	Default. Everything not yet committed.
All branch changes	Diff against your base branch. Shows the full picture of what the branch introduces.
Last turn changes	Only the most recent assistant turn. Useful for reviewing just the latest iteration.

When working locally, you can also toggle between Unstaged and Staged views to see what will be committed versus what is still pending.

Navigating the Diff

• Click a file name to open it in your configured editor (set in App settings).
• Click the file name background to expand or collapse the inline diff.
• Cmd-click a line to jump to that specific line in your editor.
• Use keyboard shortcuts to move between files quickly.

Inline Comments for Feedback

Inline comments are the fastest way to guide Codex to fix specific problems. Instead of writing a vague “the error handling is wrong,” you anchor your feedback to the exact line.

1. Open the review pane.

2. Hover over the line you want to comment on.

3. Click the + button that appears in the gutter.

4. Write your feedback. Be specific: “This catch block swallows the error silently. Log it with pino.error and re-throw.”

5. Submit the comment.

6. Repeat for other lines that need attention.

7. Go back to the thread and send a follow-up message: “Address the inline comments and keep the scope minimal.”

Codex reads inline comments as review guidance and applies them precisely because each comment is anchored to a specific location in the diff.

Tip

Prompt to send after leaving inline comments:

Address all the inline comments I left in the review pane. Do not change anything
I did not comment on. Run the tests after making the fixes.

This focuses Codex on exactly what you flagged, preventing scope creep.

Staging and Reverting

The review pane includes Git actions at three granularity levels so you can accept some changes and discard others.

Three Levels of Control

Entire Diff

Use the action buttons in the review header:

• Stage all — Stage every change across all files.
• Revert all — Discard every change, restoring files to the committed state.

Use this when Codex nailed it (stage all) or completely missed (revert all).

Per File

Each file in the diff has its own action buttons:

• Stage file — Stage all changes in this one file.
• Unstage file — Move a staged file back to unstaged.
• Revert file — Discard all changes in this file.

Use this when some files are good and others need more work.

Per Hunk

Individual code hunks within a file can be staged or reverted independently:

• Stage hunk — Accept this specific code change.
• Revert hunk — Discard this specific code change.

Use this when a file has both good and bad changes mixed together.

Note

Git can represent both staged and unstaged changes in the same file. When that happens, the same file may appear in both the Staged and Unstaged views. This is normal Git behavior, not a bug in the review pane.

The Partial Accept Pattern

This is the most common review workflow:

1. Codex completes a task that touches 5 files.

2. You review the diff. Three files are perfect. One file has a minor issue. One file is wrong.

3. Stage the three good files.

4. Leave an inline comment on the file with the minor issue.

5. Revert the wrong file entirely.

6. Send a follow-up message: “Address the inline comment on [filename]. Re-implement the changes I reverted in [other filename] using a different approach — use dependency injection instead of direct imports.”

7. Codex iterates. Review again.

8. When everything looks good, commit from the review pane.

Committing from the App

After staging the changes you want, commit directly from the review pane:

1. Click the commit button in the review header.

2. Write your commit message (or let Codex suggest one).

3. Click Commit.

4. Optionally push and create a PR from the App.

The App handles the full Git flow: stage, commit, push, and create PR — all without leaving the window.

CLI Review with /review

The CLI offers a lightweight review experience through the /review command in the interactive TUI.

# Start the TUI
codex

# After a task completes, run a local code review
/review

The /review command launches a separate Codex agent that reviews the diff and posts inline comments — like having a second pair of eyes. These comments appear directly in the TUI.

For manual diff review, use standard Git commands:

# See all changes
git diff

# See staged changes
git diff --staged

# See changes on the current branch vs main
git diff main...HEAD

Tip

Prompt for CLI code review:

Review the changes I just made. Focus on correctness, edge cases, and potential
security issues. Do not suggest style changes.

Cloud Review and PR Workflow

When Codex Cloud completes a task, the diff view at chatgpt.com/codex shows all proposed changes.

1. Review the diff in the Cloud interface.

2. Send follow-up messages in the same thread to request changes.

3. When satisfied, click Create PR to open a pull request on GitHub.

4. Or click Check out locally and review on your machine:

   git fetch
   git checkout <branch-name>

5. The PR goes through your normal human review process. You can also request @codex review to get a separate automated review.

The Iterative Review Loop

The key to getting production-quality code from Codex is iteration. Rarely does the first pass produce perfect code. The workflow is:

1. Task: Codex implements changes.
2. Review: You inspect the diff, leave targeted feedback.
3. Refinement: Codex addresses feedback.
4. Review again: You verify the fixes.
5. Accept: Stage, commit, push.

Most tasks take 1-3 iterations to reach production quality. The inline comment system makes each iteration fast because Codex knows exactly which lines to address.

Tip

Prompt for a thorough self-review before you look:

Before I review your changes, run a self-review. Check for: off-by-one errors,
missing null checks, incorrect error messages, any test that only tests the
happy path, and any import that was not actually needed. Fix what you find.

This reduces the number of issues you have to catch manually.

When This Breaks

Review pane is empty after Codex finishes: The task may not have made any file changes (analysis-only tasks). Or the changes were committed automatically. Check git log to see if Codex committed.

“Not a Git repository” error: The review pane requires a Git repository. If your project is not a Git repo, run git init first.

Inline comments disappear: Comments are tied to the current diff. If you revert the file and the diff changes, anchored comments may lose their position. Leave comments and send the follow-up message before reverting.

Staged and unstaged views show the same file: This is normal Git behavior. A file can have both staged and unstaged changes simultaneously when you stage only part of the changes.

Cloud PR has unexpected files: Codex Cloud starts from a clean clone. If your environment setup commands modify files (like code generation or dependency installation), those changes may appear in the diff. Add a .gitignore rule or adjust your setup commands.

What’s Next

Handle Failures and Retries Recover when Codex makes mistakes, hits errors, or goes in the wrong direction