How do I have a second model review framework migrations in a Python backend before each commit?

Tares runs a challenger session in which Codex critiques the plan and reviews every commit Claude Code makes, including the commits that carry your framework migrations in a Python backend. A blocking finding sends Claude back to amend the commit before it moves on. If you disagree with a finding, you waive it and the session continues.

How it works

Claude Code plans and builds as usual, and the Codex CLI on your laptop acts as the second reviewer. Tares records the exchange and never calls Codex itself.

• Plan critique. When you approve a plan and Claude leaves plan mode, the plugin hands the plan to Codex in a read-only sandbox. Codex tags each finding [P1] (the plan fails as written), [P2] (will cause rework) or [P3] (advice). For a migrations plan, that is where gaps, unhandled risks and missing verification surface before any code exists. A plan critique never blocks. Claude revises, or tells you why it disagrees.
• Commit review. After each git commit, the plugin has Codex review that commit. A commit holding a migration file goes through the same review as any other commit.
• Blocking findings. [P1] and [P2] findings block Claude. It is told to fix them and fold the fix into the same commit with git commit --amend, or to 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 after 8 rounds per commit and 5 turn ends per session. Then the findings come back as context. [P3] findings are context only, and a Codex timeout, error or inconclusive review never blocks.
• Waivers. A finding you disagree with can be waived, and the waiver holds on later rounds.

The reviews run in the Claude Code hooks on your laptop and are billed to your OpenAI account. A Tares that is down or slow never holds up a review.

Set it up

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

   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. The install asks for the Tares URL, the MCP endpoint and, on a secured instance, a read + ingest API key. Locally, keep the default MCP address http://127.0.0.1:8788/mcp.

3. Install the Codex CLI and log in to it. Codex runs on your laptop.

4. Set an Anthropic API key for the summarizer under Settings > Model providers or as ANTHROPIC_API_KEY. Tares Cloud instances come with one.

5. In Claude Code, inside your Python backend repo, 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 migration change in plan mode. Approve the plan, read Codex’s findings in Claude’s first reply, and let Claude implement and commit.

7. When Codex blocks a commit, let Claude amend it. If the migration check needs to execute your project’s commands, set the plugin option codex_sandbox to workspace-write or danger-full-access. The default is read-only.

8. If you think a blocking finding is wrong, type /tares:challenger-waive. It lists the blocking findings and waives one or all of them. Tares records a challenge_waived event.

9. To make commit reviews advisory, set the plugin option challenger_mode to advise. The default is strict.

10. Type /tares:challenger off to turn the challenger off for the rest of the session.

For a wider setup around the same laptop, see Get started. The full option list is in the challenger workflow guide.

What you get

• A second model reads your migration plan before you build and every migration commit after it, so problems are caught while the commit is still open to amending.
• A blocking finding turns into a fix inside the same commit instead of a follow-up you have to remember.
• A way out when Codex is wrong: waive one finding or all of them, and the waiver is shipped to Tares as an event.
• One timeline per session on the project page. Each session shows its plan outcome and a Findings (N) or Pass badge per reviewed commit. The Claude and Codex exchange reads as one thread.
• A summary when you end the session with /exit. It covers what was asked and built, how Codex changed the plan, what it caught in each commit and the cost. It also lists up to five memory proposals about the repo, and nothing is remembered until you accept it.
• Accepted proposals are handed to Claude as context at the start of the next session in that repo.

When something else fits

• Use challenger_mode set to advise when you want Codex’s commit notes without any blocking.
• If you have no OpenAI account, or do not want Codex runs billed to it, the challenger does not fit. A session with a plan and three commits is typically five to eight Codex runs.
• If you want a crew of sessions to take whole projects to merged pull requests, the software factory in Get started is the better route.

Related