Codex CLI replaces the recommended stack's Claude Code. Then the differentiator: Codex Cloud takes a ticket from the queue, opens a PR autonomously, and pings you when it's ready for review. Pair it with Claude reading the diff and the human reviewer mostly approves clean diffs.
Codex CLI handles the same role Claude Code does: terminal agent with file system access. Codex Cloud is the ChatGPT-bundled cloud lane that takes a task and opens a PR while you do something else. Use both: hands-on for the work you're thinking about, cloud for the cleanup tickets in the queue.
Cloud PRs especially want a second model reading the diff. Claude is a different lineage than Codex, so it catches things Codex's self-review wouldn't (different priors on idiomatic code, different blind spots). Paste the PR diff + the ticket, ask for a structured review.
If you're already thinking about the change, run the CLI. If it's a clear ticket from the backlog (refactor, dep bump, doc update), send it to Cloud and move on.
`codex` in your repo. Same shape as Claude Code: scope, plan, implement, run tests.
Plan first, then implement. Ask 1 to 2 clarifying questions before you start writing if anything is genuinely ambiguous.
Ticket / problem:
"""
{{paste ticket}}
"""
Constraints:
- Smallest viable diff.
- Match the existing code style. Read nearby files before introducing a new pattern.
- Run the project's test command. Don't report done if it fails.
- Treat AGENTS.md / CLAUDE.md / .cursorrules at the repo root as authoritative.
When done: print the file list, the test result, and a 2-line summary I can paste as the commit message.From ChatGPT, hand off the ticket with the repo selected. Cloud reads the repo, plans, opens a draft PR, and pings you. Read the PR description first; reject and retry if scope drifted.
Paste the PR diff + the original ticket into Claude. Ask for a structured review (coverage, edge cases, regressions, naming, idiomatic-code drift). For Cloud PRs especially, this catches drift the autonomous lane introduced. A different model lineage notices things the same vendor's self-review wouldn't.
Review the PR below as a skeptical senior engineer who didn't write it.
Original ticket:
"""
{{paste ticket}}
"""
Diff:
"""
{{paste git diff}}
"""
Output:
1. Does the diff actually solve the ticket? Anything missing?
2. Edge cases or failure modes the implementation doesn't handle (pick the 3 most likely).
3. Naming / idiomatic-code drift. Flag anything that looks like cross-vendor pattern leakage.
4. Specific lines I should re-read.
5. Verdict: ship / fix list / scrap and re-prompt.
Be specific (line refs, not vibes). Don't pad.For CLI work: paste Claude's findings into the same Codex session. For Cloud PRs: kick the same task back via the Cloud `Address review feedback` action with the findings as the new prompt.
Half the PRs (the ones requiring product judgment) went through Codex CLI. The other half (dep updates, type-error cleanups, doc touch-ups) ran on Codex Cloud while the engineers worked on real product. The Cloud lane shipped 22 PRs in one week with 3 needing a retry for scope drift.
Autonomous lanes occasionally rewrite the world. Always read the PR description before the diff; if the description says 'also refactored…', kill the PR and retry with a tighter ticket.
Cloud tasks are metered separately from the chat subscription. A team that sends 30 cloud tasks/day will exceed the bundled budget within a week. Track it.
Codex CLI is supervised; Cloud isn't. The same prompt works very differently in the two lanes. Don't copy a CLI prompt into Cloud and expect the same result.
