Challenge Claude Code with a second model

Mark the session

Start Claude Code in a project and say “make this a challenger session”, or type /tares:challenger. Claude calls the set_session_flow tool of the Tares MCP server; the plugin sees that call in the transcript, marks the session on your laptop, and stamps every line it ships from then on with flow=challenger.

Nothing else to set up. The first marked session creates the Challenger workflow use case on Tares by itself: a view with one timeline per session, a trigger that fires when a challenger session ends, and the challenger_summarizer agent. It shows up under Use cases. You can also create it there first, if you want to set a Slack channel or a model.

/tares:challenger off turns the challenger off for the rest of the session. A session that was not marked is streamed like any other and nothing runs.

The plan gets challenged

Ask for something in plan mode. When you approve the plan and Claude leaves plan mode, the plugin hands the plan to Codex (codex exec, read-only sandbox). Codex critiques it for gaps, wrong architecture, scope, unhandled risks and missing verification, and tags each finding [P1] (the plan fails as written), [P2] (will cause rework) or [P3] (advice).

The critique comes back to Claude as context right after your approval, so Claude’s first message after the plan mentions the findings and adjusts. A plan critique never blocks: only [P1] counts as blocking on a plan, and even then Claude is asked to revise or to tell you why it disagrees. Codex takes 30 to 90 seconds on a plan, so that first reply is slower.

On Tares, a challenge_plan event lands on the session: “Challenger reviewed the plan x.md: 9 findings (2 blocking): [P1] …”.

Every commit gets challenged

Let Claude implement and commit. After each git commit, the plugin runs codex exec review --commit <sha> on that commit. Then:

• No findings: Claude carries on. A challenge_commit event with “no findings” lands on the session.
• [P1] or [P2] findings: Claude is blocked with the findings and told to fix them and fold the fix into the same commit with git commit --amend (or 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. The loop is capped at 8 rounds per commit and 5 turn ends per session; after that the findings come back as context instead.
• [P3] findings: context only, never blocking.
• A Codex timeout, error or an inconclusive review never blocks.

If you disagree with a finding, /tares:challenger-waive lists the blocking findings and waives one (or all); the waiver is remembered for that finding on later rounds and shipped to Tares as a challenge_waived event. To make commits advisory as well, set the plugin option challenger_mode to advise.

Read the exchange on Tares

Open the use case page. The Sessions tab lists every challenger session with its project and branch, the plan outcome, one badge per reviewed commit (Findings (N) or Pass) and whether the session is live, ended or summarized. Click a session: the Claude and Codex exchange reads as one thread (challenge events only), with a switch to the whole session read through the challenger_session view. Explore shows the same session next to everything else Tares knows.

End the session

/exit. The plugin ships a session_end line, the challenger_session_ended trigger fires, and challenger_summarizer reads the whole session and writes a finding with five sections: what was asked and built, the plan and how Codex changed it, each commit and what Codex caught, cost, and Memory proposals: up to five sentences about the project worth carrying into the next session.

The run appears on the Runs tab within a minute or two; the time opens it on the agent’s page. Summarize on a session row runs the summarizer on demand, on a live session too.

Accept what to remember

The Memory proposals panel on the Runs tab lists the open proposals with Accept and Reject. Accept writes the sentence to the agent_memory source as a decision keyed by the project; reject records a rejection there too, so the choice holds in every browser. Nothing reaches memory without an accept.

Start the next Claude Code session in that project. The plugin fetches the accepted decisions for the project at session start and hands them to Claude as context, before your first prompt:

Memory from earlier Tares sessions on this project (accepted by the user):
- Race conditions in async hooks are a recurring source of Codex findings in this repo; ...

Ask Claude “what do you remember about this project from Tares?” to see them.