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

Tares runs a challenger session, where Claude Code builds your Python backend and the Codex CLI on your laptop critiques the plan and reviews every commit. A blocking finding sends Claude back to fix the work and amend the same commit. If you disagree with a finding, /tares:challenger-waive waives it. Put your test coverage expectations in the plan so Codex has them to judge.

How it works

A challenger session has two models. Claude Code plans and builds as usual. Codex reviews, locally, through hooks in the Tares plugin for Claude Code.

• Plan check. When you approve the 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. Missing verification is the part to lean on for test coverage. It tags each finding [P1] (the plan fails as written), [P2] (will cause rework) or [P3] (advice).
• Commit check. After every git commit, the plugin has Codex review that commit.
• Blocking. [P1] and [P2] findings on a commit block Claude. Claude must fix them and fold the fix into the same commit with git 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.
• Not blocking. [P3] findings are context only. A Codex timeout, an error or an inconclusive review never blocks. A plan critique never blocks either. Even a [P1] on a plan only asks Claude to revise or to tell you why it disagrees.
• Caps. The loop stops at 8 rounds per commit and 5 turn ends per session. After that, the findings come back as context.

The review runs on your laptop against your OpenAI account, and Tares never calls Codex. Tares receives the results as events on one timeline per session. A challenge_plan event carries the verdict, the finding count, the blocking count and the duration. A challenge_commit event carries the same plus the commit sha and the round. A challenge_waived event carries the finding count.

Set it up

1. Run Tares with its MCP endpoint next to it, or use a Tares Cloud instance, which serves the endpoint itself.

   uv tool install tares     # or: brew install glassflow/tap/tares
   tares up
   tares mcp --transport streamable-http

2. In Claude Code, install the Tares plugin, version 0.2 or later. The install asks for the Tares URL and the MCP endpoint. On a secured instance it also asks for a read + ingest API key.

   /plugin marketplace add glassflow/tares
   /plugin install tares@tares

3. Install the Codex CLI and log it in. Codex is billed to your OpenAI account.

4. Make sure the summarizer has an Anthropic API key, under Settings > Model providers or as ANTHROPIC_API_KEY. Tares Cloud instances come with one.

5. Open Claude Code in your Python repo 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 the work in plan mode and state the coverage you expect in the request, so it lands in the plan Codex critiques. Approve the plan, then let Claude implement and commit.

7. Waive a finding you disagree with. /tares:challenger-waive lists the blocking findings and waives one or all of them. The waiver is remembered for that finding on later rounds.

8. Optional plugin options:

   • Set challenger_mode to advise to make commit findings advisory instead of blocking.
   • Set codex_sandbox to workspace-write or danger-full-access when Codex needs to run the project’s commands. The default is read-only.

Python repos get one extra check in the software factory. tares factory doctor finds Python from pyproject.toml, setup.py, setup.cfg, Pipfile or requirements.txt. It tells you how to add the pyright language server for Claude Code. If you also want a crew to build and merge, see Get started. It lists Codex as an optional way to have a second model check every commit.

What you get

• Every commit in the session gets a second opinion before Claude moves on, and the plan gets one before any code is written.
• Blocking findings turn into a fix inside the same commit, so the history stays clean.
• You keep the last word. Waive a finding and the loop stops asking about it.
• On the project page, Sessions lists each session with its plan outcome and one badge per reviewed commit, Findings (N) or Pass. Open a session to read the Claude and Codex exchange as one thread.
• A Tares agent writes a session summary when you /exit. It includes what Codex caught in each commit and up to five Memory proposals about the repo. Nothing reaches memory until you accept it, and accepted decisions reach the next session in that repo as context.
• A Tares that is down or slow never blocks a review. The plugin retries shipping on the next hook.

The full walkthrough, the event list and the plugin options are in the challenger workflow guide.

When something else fits

• If you want review to guide rather than gate, set challenger_mode to advise. Commit findings then arrive as context and never stop Claude.
• If you want a whole project built into merged pull requests by a crew, with a reviewer holding every change to a fixed bar, use the software factory. The challenger session suits one Claude Code session on your laptop.

Related