Review and ship with Codex

Shipping Codex-written code safely means layering checks between the diff and production: /review before commit and codex exec review before push, @codex review on the pull request, openai/codex-action in CI, and deployment with a tested rollback. Codex’s review is one input; the merge decision rests on the evidence all the gates produce together.

This hub is for developers and tech leads whose Codex sessions now produce more pull requests than the team can read line by line. The diffs look tidy, the style is uniform, and the mistakes hide in the places you stopped checking: a missing authorisation check, a skipped test, a migration without a backfill. The pages below replace line-by-line reading with gates you can measure. Commands were checked against Codex CLI 0.157.1.

Which Codex ship page answers your question?

Your question	Page
How do I make Codex review a team gate, and know it catches real bugs?	Code review with Codex
How deep should a human look at each change, and which approval mode fits?	Reviewing agent work without becoming the bottleneck
How do I run Codex in GitHub Actions without exposing secrets?	Run Codex in CI/CD with the GitHub Action
How does a pull request get from worktree to merge with Codex’s help?	Pull request automation with Codex
How do I deploy what Codex built, and roll it back?	Deployment automation with Codex

If you have never reviewed a Codex change, start with review Codex’s changes before you commit. A gate is only as strong as the tests behind it; see testing and debugging with Codex.

In what order should a Codex change go out?

Cheap, private checks run first, so the public review stays worth reading.

1. Before commit. Run /review in the session, or codex review --uncommitted from the terminal, and fix every P0 and P1 finding (Codex tags each finding P0–P3, P0 most severe).

2. Before push. A pre-push hook runs the review as a script and fails on P0 or P1 findings. In a terminal:

   codex exec review --base origin/main --ephemeral -o .codex-review.md

   The hook itself, and how to check its output format, is on the code review page.

3. On the pull request. Comment @codex review, and @codex security review on authentication, input handling and secrets. Turn on automatic reviews only after your AGENTS.md review rules are tuned.

4. In CI. Tests, types and lint run on the pushed branch. Run openai/codex-action@v1 with permission-profile: ":read-only" and a review prompt, then have a separate step fail the job when the output contains a P0. CI blocks only on P0, looser than the pre-push hook, because P1 findings still reach the pull request and the human owner decides on them there; the CI/CD page builds this gate. Read-only means Codex cannot edit code or tests to make the checks pass.

5. At merge. A named human signs off on the escalation paths in CODEOWNERS: migrations, auth, money, public API contracts, and changes to tests or CI.

6. At deploy. Ship behind a flag or a canary with a rollback you have run at least once.

Copy-paste prompt: build the merge evidence for this branch

Compare this branch with origin/main. Do not edit any files. Write a merge summary with:
1. What changed, in at most five bullets, each naming the files involved.
2. The commands that prove it works (tests, typecheck, lint). Run them and report each
   exit code; do not claim a result you did not run.
3. Every changed path that falls under migrations, authentication, billing, public API
   routes, tests or CI configuration, so a human owner can review those first.
4. Behaviour the tests do not cover, stated as the test that is missing.
End with one line: READY, or NOT READY and the reason.

Copy-paste prompt: write the rollout and rollback plan

Read the diff between this branch and origin/main, our deploy workflow under
.github/workflows/, and any migrations in this branch. Write docs/releases/rollout.md
with: the deploy order (migrations before or after code, and why), the feature flag or
canary step that limits exposure, the three signals we watch in the first 30 minutes
(error rate, latency, one business metric this change affects), the exact command that
rolls back, and whether any migration makes rollback unsafe. Do not run any deploy or
migration command. Show me the file before creating anything else.

How do you know a Codex change is safe to ship without reading every line?

Each gate produces evidence someone owns. Read the evidence; open the diff where it points.

Evidence	What it proves	Owner
Seeded-bug catch rate of the Codex reviewer	The review finds the defect classes you care about	Tech lead
CI green on the pushed branch: tests, types, lint	Existing behaviour still holds	CI
Codex findings gate with no P0 (P1 goes to the human owner)	No blocking issue by your own AGENTS.md rules	Owner of the CI review prompt and workflow (under CODEOWNERS)
Approval on CODEOWNERS escalation paths	A person accepted the risk where a miss is expensive	Named code owner
Canary metrics and a rehearsed rollback	Production confirms it, or you can undo it quickly	On-call engineer

What an agent’s pull request should carry is defined in the evidence bundle, and the triage that uses it in reviewing an agent’s pull request without reading every line.

What breaks between an approved diff and a running deployment?

Symptom	Cause	Recovery
The team ignores Codex comments	Too many P2 and P3 findings	Report only P0 and P1 on pull requests; add a “Do not flag” line per noise category to AGENTS.md
codex exec review --base main "focus on auth" fails	In 0.157.1, --base, --commit and --uncommitted each reject a custom prompt	Drop the prompt and put the focus in AGENTS.md
A pull request weakens its own CI review	Prompts and workflows load from the pull request’s merge commit	Put .github/ under CODEOWNERS
A secret leaks from a PR-triggered job	Untrusted code ran with secrets in the environment	Follow agent identity and secrets before enabling the trigger
The reviewer approves the code it wrote	Same model, same session	Set review_model to another model and review in a fresh process
Rollback fails in production	A migration dropped data the old code needs	Split it with expand and contract; never ship a destructive migration with the code that needs it

Where to go next with shipping Codex changes

Make review a gate

Code review with Codex

Harden CI

Run Codex in CI/CD with the GitHub Action

Operate what shipped

Operate Codex in production

Across all tools

Shipping workflows for every agent

Using another agent as well? The same stage is covered in review and ship with Claude Code and review and ship with Cursor.