On a WooCommerce store, the bugs that cost real money rarely live in the diff. The pull request reads clean, the template renders, and checkout breaks on the one gateway and shipping zone combination nobody tested. I kept thinking about that gap while reading Eivind Kjosbakken’s piece on Towards Data Science, where he runs Claude Code and Codex together: Claude Code as the main coding agent, Codex as the reviewer on pull requests.
Why the Claude Code and Codex split works
His loop: Claude Code plans and writes the change, Codex gets tagged on the pull request to review it, and the two iterate until Codex finds nothing. I’d copy it, for a reason the article doesn’t stress much: the reviewer reads the diff cold, without the rationalizations that come from having just written the code. A second model with no stake in the first model’s reasoning catches what the first model talks itself out of.
The role split also matches how the tools behave. Claude Code is good at planning and at asking about ambiguities before committing to an approach, which matters on WordPress work where “add a field to checkout” can mean three different implementations. Its CLI features are ahead too, worktrees in particular, which let me run one agent per client site without edits colliding. Codex follows literal instructions well, which is the temperament you want in a reviewer. Kjosbakken also keeps Codex because Claude Code’s uptime has been poor lately, and the public status page supports that. Fair, but uptime is the weaker reason. A tool you only open when the other one is down gets used now and then, but a reviewer wired into every pull request gets a look at every change.
Give the reviewer WordPress rules
Codex reviews get sharp once the reviewer knows your rules. OpenAI’s guidance on custom review rules is to put a few of them in AGENTS.md, which Codex reads when reviewing, and keep mechanical checks in CI. On WordPress repos mine look like this:
# AGENTS.md
- Flag direct SQL on wp_posts or wp_postmeta that skips WP_Query or wc_get_products().
- All email goes through wp_mail(), never mail() or PHPMailer directly.
- New settings must register a sanitize_callback via the Settings API.
- Any write to the database needs a current_user_can() check. Flag it if missing.The advice to keep phpcs and the test suite in CI matters more than you’d think. An agent reviewer will flag a spacing issue on one pass and skip it on the next, but the pipeline flags it every time. Repo rules are for the judgment calls a human reviewer would otherwise raise on every pull request: escaping, capabilities, data access patterns.
If you want a loop like this on a client repo, writing the AGENTS.md rules and wiring review and CI into an existing WordPress codebase is work I take on. It’s cheaper to do before the repo accumulates years of diffs than after.
Where the loop stops
What the loop doesn’t cover is behavior. A diff reviewer can catch a missing current_user_can() call, and that’s worth having. It won’t catch a filter that fires twice because two plugins hook the same thing, an object cache interaction, or transactional email quietly going to spam. Those are the regressions I see on stores, and the diff is clean in every one of them.
So treat the review as one gate and staging as the second. After Codex approves, push the branch to staging and run the boring checks: place a test order, or script it with wp wc order create if WooCommerce CLI is available, confirm both customer and admin emails arrive, and compare totals on an order with a coupon and shipping. I haven’t found a clean way to script that last part for multisite, where one codebase runs sites with different plugins active, so it stays manual there. Claude can write a PHPUnit test for some of it and Codex can review the test, but the final check still runs against a real install with the real plugins loaded.
