How do I have a second model review dependency upgrades in a monorepo before each commit?
Tares runs a challenger session where Codex critiques the plan and reviews every commit, so each dependency upgrade in your monorepo gets a second model’s review. A blocking finding sends Claude Code back to amend the commit before it moves on. If you disagree with a finding, you waive it with /tares:challenger-waive.
How it works
In a challenger session, Claude Code plans and builds as usual and the OpenAI Codex CLI on your laptop acts as the critic. Tares records the exchange and never calls Codex itself.
- Plan critique. When you approve the plan and Claude leaves plan mode, the plugin hands the plan to Codex (
codex exec, read-only sandbox). Codex looks for gaps, wrong architecture, scope problems, unhandled risks and missing verification. It tags each finding[P1](the plan fails as written),[P2](will cause rework) or[P3](advice). The critique reaches Claude as context right after your approval. On a plan only[P1]counts as blocking, and even then Claude is asked to revise or to tell you why it disagrees. - Commit review. After each
git commit, the plugin runscodex exec review --commit <sha>on that commit. An upgrade commit is reviewed like any other commit Claude makes. - Blocking findings. On a commit,
[P1]and[P2]findings block Claude. It must fix them and fold the fix into the same commit withgit commit --amend, or make a new commit when the reviewed one is already on a remote. The amended commit is reviewed again as round 2, and so on until Codex is satisfied. - Limits. The loop stops at 8 rounds per commit and 5 turn ends per session. After that the findings come back as context.
[P3]findings are always context only. A Codex timeout, an error or an inconclusive review never blocks.
The reviews run in the Claude Code hooks on your laptop, against your OpenAI account. Review state, fix-loop counters, the review history and waivers live under the repository’s .git/. A slow or stopped Tares never blocks a review.
Set it up
-
Run Tares and its MCP endpoint, or use Tares Cloud, which serves the endpoint itself. Start with the Get started steps for the CLI.
tares up tares mcp --transport streamable-http -
In Claude Code, install the Tares plugin (version 0.2 or later). It asks for the Tares URL, the MCP endpoint and, on a secured instance, a
read + ingestAPI key. From plugin 0.4.0 the challenger reaches Tares through the MCP endpoint, which locally defaults tohttp://127.0.0.1:8788/mcp. -
Install the Codex CLI and sign in with
codex login. Codex is billed to your OpenAI account. -
Set an Anthropic API key for the summarizer under Settings > Model providers, or as
ANTHROPIC_API_KEY. Tares Cloud instances come with one. -
Open Claude Code in the monorepo and say “make this a challenger session”, or type
/tares:challenger. Claude calls theset_session_flowtool and the plugin marks the session. The first marked session creates the Challenger workflow project by itself. -
Ask for the upgrade in plan mode, approve the plan, then let Claude commit. Each commit is reviewed before Claude carries on.
-
If you disagree with a blocking finding, type
/tares:challenger-waive. It lists the blocking findings and waives one or all. The waiver is remembered for that finding on later rounds. -
To make commit reviews advisory instead of blocking, set the plugin option
challenger_modetoadvise. The default isstrict.
Codex runs read-only by default. If you want it to run the project’s own commands, set codex_sandbox to workspace-write or danger-full-access. If the Codex binary is not on your PATH, set codex_bin. /tares:challenger off turns the challenger off for the rest of the session.
What you get
- A critique of the upgrade plan before any file changes, with findings ranked
[P1]to[P3]. - A review of every commit. A clean one lands as a
challenge_commitevent with “no findings”. A blocked one is amended and reviewed again until it passes or hits the round cap. - A recorded waiver as a
challenge_waivedevent when you override a finding, so the decision stays visible. - One timeline per session on the project page. Sessions lists each session with its repo and branch, the plan outcome, and a
Findings (N)orPassbadge per reviewed commit. - A summary when you
/exit. Thechallenger_summarizeragent writes what was asked and built, what Codex caught in each commit, the cost, and up to five Memory proposals. You accept or reject each one, and accepted ones are handed to Claude at the start of the next session in that repo.
Cost is a Codex run for the plan and one for each commit review. A session with a plan and three commits is typically five to eight Codex runs.
When something else fits
- If you want a whole project built by a crew instead of one session, use the software factory for Claude Code.
tares factory crew upasks whether a second model checks every commit, and the challenger workflow guide covers the single-session setup in full. - If you only want Codex’s opinions without blocking, set
challenger_modetoadvise.
Related
- Build a software factory with Claude Code
- How do I have a second model review internal refactors in a Python backend before each commit?
- How do I have a second model review bug fixes in a monorepo before each commit?
- How do I have a second model review bug fixes in a Python backend before each commit?
Still stuck? Get help