Have Codex review Claude Code branches before they merge

Claude Code can work on a change in its own branch while Codex reviews the finished commit. With brindle, the review and your checks both have to pass before that branch can merge.

A separate reviewer helps catch mistakes that the worker may have missed. The useful part is making the review specific: Codex examines the proposed change, and its approval applies to that exact commit. If the branch changes afterward, it needs another review. brindle can also run the repository's checks as part of the merge gate.

Prepare the repository

Start in a Git repository with Claude Code and Codex available. Install brindle, then initialize it in the repository if you have not already:

uv tool install brindle
cd ~/code/myapp
brindle init

brindle init looks at project manifests and lockfiles for setup and check commands, then shows what it found before writing .brindle/config.json. Review that file and make sure its checks are the commands you trust before merging. Add a setup command if fresh worktrees need dependencies installed. Commit the config so the same setup and checks are available to your team.

Keep the supervisor's base branch committed before starting. Workers branch from the supervisor's committed work, so commit or stash changes that you want included in the task.

Start a Claude task

Run brindle from the repository and describe the result you want, including the parts of the project to change and the checks that define done. The supervisor can split larger work across workers. Each worker gets its own worktree and branch, so Claude Code can work without sharing a checkout with another agent.

cd ~/code/myapp
brindle

For example, ask the supervisor to add a retry to a failing API request, keep the change within the client and its tests, and run the relevant test file. Clear boundaries help the reviewer focus on the change. For work that takes longer than one sitting, describe milestone checks in commands or put the goal in .brindle/goals.md.

Keep an eye on the sidebar while the work is underway. It shows which agents are working, idle, or waiting for your approval. If a worker needs a decision, the supervisor can bring that question to you before continuing.

Make Codex the reviewer

brindle doesn't switch reviewers to a different model on its own: by default the built-in reviewer profile reviews every branch. To have Codex review Claude's work, install and sign in to the Codex CLI, then name the built-in reviewer-codex profile in .brindle/config.json:

{"review_profile": "reviewer-codex"}

The reviewer is then a different model from the Claude worker. Setting reviewer instead makes Codex the default while still letting brindle Pro's hosted learning choose another built-in reviewer when it has reviewed that kind of work better; review_profile always uses the one you name. See configuration for the supported settings.

When a worker the supervisor assigned reports its result, brindle starts the review at once and runs the checks alongside it (the "pipeline" setting, on by default). A review includes the task and finish line, a summary of checks, and the changes since any previous review. The reviewer assesses the change and returns an approval or feedback. If it asks for changes, brindle sends the findings back to the worker and reviews the updated branch again, for a set number of rounds before the supervisor steps in.

Approval is tied to the commit reviewed. That matters when a fix or follow-up edit changes the branch: Codex should inspect the new commit, not rely on approval of an earlier version. Keeping each task focused makes the review easier to understand and makes any requested follow-up more direct.

Checks gate the merge

A review does not replace tests. brindle requires the work to be committed, a reviewer to approve that exact commit, pre-commit hooks to pass, and the configured repository checks to pass before the branch can merge. It runs the checks itself as part of the merge process. A green check means the command exited successfully; a model's claim that tests passed is not enough.

For projects with a large test suite, ask the supervisor to run a focused test while developing, then keep the repository's merge checks appropriate for the changes that can land. When a check fails, use its output to identify what needs fixing. The supervisor can direct the worker to update the branch and rerun the relevant checks and review.

brindle caches a clean commit's passing check result, so it does not rerun checks for every review and merge attempt at the same commit. A new commit needs its own result. You can follow review and merge activity in the session and inspect the work before deciding whether to continue.

Make the workflow fit the task

For a small change, give the supervisor one narrow task and a direct test command. For broader work, split it into milestones with separate checks, and assign tasks that touch distinct areas so workers can proceed in parallel. Ask for a plan first when the approach needs your input; brindle can hold a Claude worker until its plan is approved.

Autopilot starts on by default and keeps working toward the goal while workers are active. It asks you when it needs a decision or stops making progress, and pauses near your Claude usage limit (90% by default) until the window resets. You can inspect the goal's progress with brindle autopilot, and the autopilot guide explains milestones and verified checks.

If you want to see how agents, reviews, and gated merges fit together before using your own repository, try brindle demo. To confirm the tools and repository setup, run brindle doctor. When you're ready, start brindle in your project, describe the task and its checks, and let Claude work while Codex reviews the resulting commit.

curl -fsSL pawdelta.com/brindle/install | sh