How do I have a second model review test coverage in a monorepo before each commit?

Tares runs a challenger session in which the Codex CLI critiques Claude Code’s plan and reviews every commit it makes in your monorepo. A blocking finding sends Claude back to fix and amend the commit before it moves on. If you disagree with a finding, you waive it with /tares:challenger-waive.

How it works

A challenger session pairs Claude Code, which plans and builds, with the OpenAI Codex CLI on the same laptop, which argues with it. Both run locally. Tares records the exchange and never calls Codex.

• Plan review. When you approve a plan and Claude leaves plan mode, the plugin hands the plan to Codex in a read-only sandbox. Codex looks for gaps, wrong architecture, scope problems, unhandled risks and missing verification. That last item is where a plan that skips tests gets called out. Each finding is tagged [P1] (the plan fails as written), [P2] (will cause rework) or [P3] (advice). A plan critique never blocks. Claude gets it as context, revises, or tells you why it disagrees.
• Commit review. After every git commit, the plugin runs a Codex review on that commit. With no findings, Claude carries on. With [P1] or [P2] findings, Claude is blocked and told to fix them and fold the fix into the same commit with git commit --amend. If the reviewed commit is already on a remote, Claude makes a new commit instead. The amended commit is reviewed again as round 2, and so on until Codex is satisfied.
• Limits. The loop is capped at 8 rounds per commit and 5 turn ends per session, after which findings come back as context. [P3] findings never block, and a Codex timeout, error or inconclusive review never blocks.
• Monorepo scope. A monorepo is one Git repository, so the review history, fix-loop counters and waivers all live under that repository’s .git/. Accepted memory is keyed by the repo.

Set it up

1. Start Tares and its MCP endpoint, or use a Tares Cloud instance, which serves the endpoint itself.

tares up
tares mcp --transport streamable-http

2. Install the Tares plugin for Claude Code, version 0.2 or later, from the glassflow/tares marketplace. Enter the Tares URL and the MCP endpoint. On a secured instance, also enter a read + ingest API key. Locally, keep the default endpoint http://127.0.0.1:8788/mcp.
3. Install the Codex CLI and log in. Codex runs on your laptop and is billed to your OpenAI account.
4. Give the summarizer an Anthropic API key under Settings > Model providers, or set ANTHROPIC_API_KEY. Tares Cloud instances come with one.
5. Start Claude Code in the monorepo and say “make this a challenger session”, or type /tares:challenger. The first marked session creates the Challenger workflow project on Tares by itself.
6. Ask for your change in plan mode. State the test coverage you expect in the request, approve the plan, and read the Codex critique that Claude mentions in its first reply. Expect 30 to 90 seconds for that review.
7. Let Claude implement and commit. Each commit is reviewed, and blocking findings send Claude back to amend.
8. If Codex needs to run the project’s commands, such as your test suite, set the plugin option codex_sandbox to workspace-write or danger-full-access. The default is read-only.
9. To waive a finding you disagree with, run /tares:challenger-waive. It lists the blocking findings and waives one or all of them. The waiver is remembered for that finding on later rounds and shipped to Tares as a challenge_waived event.
10. To make commit reviews advisory instead of blocking, set challenger_mode to advise. The default is strict.
11. Type /exit to end the session. A Tares agent writes the summary and proposes up to five sentences worth remembering in the next session in that repo.

The full walkthrough is in Challenge Claude Code with a second model.

What you get

• A second model critiques the plan and every commit before work moves on, so a commit with a finding does not stand until it is fixed or waived.
• A fix loop that folds corrections into the same commit, so your history stays clean.
• A timeline per session on Tares. The project page lists each session with its repo and branch, the plan outcome and one badge per reviewed commit, Findings (N) or Pass. Events such as challenge_plan, challenge_commit and challenge_waived carry the verdict and counts.
• A written summary per session that covers what was asked and built, what Codex caught in each commit, cost, and memory proposals.
• Memory you control. Accept writes a proposal to memory keyed by the repo, Reject records the rejection, and the next session in that repo starts with the accepted decisions as context.
• Local control. Reviews run in Claude Code hooks on your laptop, and a slow or unavailable Tares never blocks a review. Expect about five to eight Codex runs for a session with a plan and three commits.

When something else fits

• If you want a second model to check every commit across a whole crew of background sessions, the software factory has that as a crew setting. Start with Get started.
• If you only want advice and never a block, keep the challenger and set challenger_mode to advise.

Related