# 15.11 How today's tools realize it (/building-ai-workers/code-review/both-ai-vendors) --- type: Document title: "15.11 How today's tools realize it" description: "Short practice for each lesson of this chapter, with tabs where Claude Code, Codex and OpenCode differ, and what each one can and cannot block, as their own pages said on October 31, 2026." status: stable order: 315.11 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-11-02T18:33:56Z chapter: "15" part: III expert_status: builder-only concepts: [ "15.11" ] last_verified: 2026-10-31 sources: - id: anthropic-code-review title: "Code Review (Anthropic, accessed 2026-11-02)" resource: https://code.claude.com/docs/en/code-review - id: anthropic-code-review-pull-requests title: "Read and request reviews on a pull request (Anthropic, accessed 2026-11-02)" resource: https://code.claude.com/docs/en/code-review-pull-requests - id: anthropic-code-review-setup title: "Set up Code Review (Anthropic, accessed 2026-10-31)" resource: https://code.claude.com/docs/en/code-review-setup - id: anthropic-code-review-customize title: "Customize Code Review (Anthropic, accessed 2026-10-31)" resource: https://code.claude.com/docs/en/code-review-customize - id: anthropic-code-review-costs title: "Code Review costs and usage (Anthropic, accessed 2026-11-02)" resource: https://code.claude.com/docs/en/code-review-costs - id: anthropic-code-review-local title: "Review locally with /code-review (Anthropic, accessed 2026-10-31)" resource: https://code.claude.com/docs/en/code-review-local - id: anthropic-ultrareview title: "Ultrareview (Anthropic, accessed 2026-11-02)" resource: https://code.claude.com/docs/en/ultrareview - id: anthropic-security-reviews title: "Automated security reviews in Claude Code (Anthropic, accessed 2026-10-31)" resource: https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code - id: anthropic-github-actions title: "Claude Code GitHub Actions (Anthropic, accessed 2026-11-02)" resource: https://code.claude.com/docs/en/github-actions - id: anthropic-security-review-action title: "claude-code-security-review, README and action.yml (Anthropic, accessed 2026-11-02)" resource: https://github.com/anthropics/claude-code-security-review - id: anthropic-setup title: "Set up Claude Code (Anthropic, accessed 2026-11-02)" resource: https://code.claude.com/docs/en/setup - id: anthropic-memory title: "How Claude remembers your project (Anthropic, accessed 2026-11-02)" resource: https://code.claude.com/docs/en/memory - id: anthropic-desktop title: "Use Claude Code Desktop (Anthropic, accessed 2026-11-02)" resource: https://code.claude.com/docs/en/desktop - id: openai-github title: "Codex in GitHub (OpenAI, accessed 2026-11-02)" resource: https://learn.chatgpt.com/docs/third-party/github - id: openai-code-review title: "Code review (OpenAI, accessed 2026-10-31)" resource: https://learn.chatgpt.com/codex/code-review - id: openai-commands title: "Commands (OpenAI, accessed 2026-10-31)" resource: https://learn.chatgpt.com/docs/developer-commands?surface=cli - id: openai-github-action title: "Codex GitHub Action (OpenAI, accessed 2026-10-31)" resource: https://learn.chatgpt.com/docs/github-action - id: openai-codex-pricing title: "Codex pricing (OpenAI, accessed 2026-11-02)" resource: https://learn.chatgpt.com/docs/pricing - id: openai-modes title: "Codex modes: Local, Worktree and Cloud (OpenAI, accessed 2026-10-31)" resource: https://learn.chatgpt.com/codex/environments/modes - id: openai-permission-modes title: "Permission modes (OpenAI, accessed 2026-11-02)" resource: https://learn.chatgpt.com/codex/permission-modes - id: openai-agent-approvals title: "Agent approvals and security (OpenAI, accessed 2026-11-02)" resource: https://learn.chatgpt.com/docs/agent-approvals-security - id: openai-security-review title: "Security Review (OpenAI, accessed 2026-11-02)" resource: https://learn.chatgpt.com/codex/security/security-review - id: opencode-commands title: "Commands (OpenCode, accessed 2026-10-31)" resource: https://opencode.ai/v2/docs/commands/ - id: opencode-changelog title: "Changelog (OpenCode, accessed 2026-11-02)" resource: https://opencode.ai/changelog - id: opencode-cli title: "CLI (OpenCode, accessed 2026-10-31)" resource: https://opencode.ai/v2/docs/cli/ - id: opencode-permissions title: "Permissions (OpenCode, accessed 2026-10-31)" resource: https://opencode.ai/v2/docs/permissions/ - id: opencode-security title: "Security policy and advisories (OpenCode, accessed 2026-10-31)" resource: https://github.com/anomalyco/opencode/security generated: at: 2026-11-02T18:33:56Z by: process:panaversity trust_tier: unverified build_id: sha256:e1fbcb7d9a8f8b9b7cb96875022325c02c9ba4be94cef13b301cbd39a9edad85 dirty: true ksor_version: 0.0.60 --- **In everyday life.** Three security firms will all inspect your building. One sends a team to walk it and leaves a report. One lends you the checklist to walk it yourself. One installs a camera on your own wall. None of them locks the doors. That stays your job. **What you will learn.** How to practice each lesson of this chapter in your own agent. Also, what Claude Code, Codex and OpenCode each offer for review, as of October 31, 2026, and what each one can and cannot block. **Why it matters.** A managed review is the team that walks the building. A local command is the checklist. A review in your own workflow is the camera. The three products offer these in different places, read their rules from different files and cost different amounts. In all three, the checks that block a merge are yours. **How to use this page.** Each section is the practice for one lesson, and that lesson links to it. Each is a short exercise, ten to fifteen minutes. Most steps are the same in every agent, so they are written once. Where the three products differ, the section ends with tabs: pick your tool once, and every strip on this page follows. Before you approve a command, read what the agent says it will do, and say no to anything you do not understand. The exact clicks for GitHub and each review tool are in `field-guide-code-review-setup.md`, in the lab's download. Concept [12.7](../agentic-coding/both-ai-vendors.md) covers the three agents in full. ## Practice: the proposed change From Concept [15.1](the-change-is-the-unit-of-work.md). Read a branch as a proposed change, and ask for the command that proves its claim. Fifteen minutes, and a few more the first time, for the setup. **The first time, set up once.** The rest of this page uses this folder. 1. Download [brightline-lab-ch15.zip](https://github.com/panaversity/agentfactory-v2-resources/releases/latest/download/brightline-lab-ch15.zip), and unzip it. 2. Copy its `brightline-ap` folder to a new folder beside it, `practice-15`, so the lab still starts clean. Open `practice-15` in your agent. Keep your note in a text editor, outside this folder. Set the agent to ask before it acts, as the tabs at the end of this section say. 3. Send: "Please set my git name and email for this project only, and ask me what they are. Then install the packages from the lock files, with `npm ci` and, in `py/`, `uv sync`." You set up Git, Node.js and uv in [13.2](../programming-fundamentals/the-workbench.md#how-do-i-set-up-the-workbench). **The exercise.** 1. Send: "Please show me the commits that `weekend-rule` adds to main, with `git log --oneline main..weekend-rule`. Change nothing." From the commit messages, write the change's purpose in one line in your note. 2. Predict in your note: with the weekend rule on, will more or fewer invoices be due by Friday, March 5? Why? 3. Send: "Please switch to `weekend-rule`. Run `npm run due -- 2027-03-05`, then the same with `PAY_WEEKEND_RULE=on`. Show me the last line of each." 4. Send: "Which files does this branch change, compared with main? Use `git diff --stat main...weekend-rule`. Change nothing." Mark any file you would not expect a weekend rule to touch. Then ask the agent to switch back to `main`. **What you should see.** Two commits. The log lists the newest first, so the tests, on the last line, came first. 8 invoices, total $19,229.53, with the flag off, and 10 invoices, total $33,109.53, with it on. Those two lines are the evidence for the claim. Six files change, and one of them is `src/reconcile.ts`. A weekend rule for the payment list has no obvious reason to touch reconciliation, which is where [15.7](ai-review-on-every-pr.md) finds the bug. How to make each agent ask before it acts: ### Claude Code Choose *Manual* in the mode selector before your first message.[^anthropic-desktop] ### Codex Use the permission mode *Ask for approval*,[^openai-permission-modes] with *Work in* set to *This computer*. Codex asks only when a command goes beyond its sandbox.[^openai-agent-approvals] ### OpenCode Use an `ask` rule for shell commands in `opencode.jsonc`, as in [Lab 12](../agentic-coding/lab.md), and turn auto-accept off.[^opencode-permissions] ## Practice: git through the agent From Concept [15.2](git-through-the-agent.md). See the git words in this repository, find one changed character, and compare two dots with three. Fifteen minutes. 1. Send: "Please show me the branches and tags, and the history as a graph, with `git log --oneline --graph --all --decorate`." Find `main`, the two branches, and the place each branch left `main`. 2. Send: "Show me the diff of `agent-speedup` against main for `src/due-by-friday.ts` only, with three dots. Change nothing." Find the line with `cutoff`. Write in your note which character changed, and what that does to an invoice due exactly on the cutoff day. 3. Send: "Please switch to `agent-speedup`, run `npm run due -- 2027-03-05`, show me the last line, and switch back to `main`." 4. Send: "Please add one line to `NOTES.md` on main, and commit it. Then run `git diff --stat main..weekend-rule` and `git diff --stat main...weekend-rule`." Compare the two lists. 5. Send: "Please undo that commit, in the way that is safe if others already have it." Read the command before you approve it. **What you should see.** `<=` became `<`, so an invoice due exactly on the cutoff day is left out. The due list drops from 8 invoices to 6 invoices, total $11,679.58. Two dots list seven files, because they also count your new line in `NOTES.md`, which `weekend-rule` does not have. Three dots list only the branch's six files. For the undo, the agent should offer `git revert`, which adds a commit. If it offers `git reset --hard`, say no, and ask what it wants to remove. Where each app shows the agent's changes, and how it gives a session its own branch: ### Claude Code The *Changes* card opens a diff view, file by file. Comment on a line with *+*, and Claude makes the change. Turn on *Worktree* before the session starts. Worktrees go in `.claude/worktrees/`.[^anthropic-desktop] ### Codex The review pane shows unstaged or staged changes, a commit, the branch diff or the last turn. Stage or revert a file or one part of it, and comment on lines.[^openai-code-review] For a branch of its own, use the separate *Worktree* control when you start a chat. *Work in* chooses this computer or the cloud.[^openai-modes] ### OpenCode With *Changed files* on, in Settings, the timeline shows each completed turn's changed files, line counts and diffs. Read the whole branch with `git diff`. Choose a worktree and its base branch when you start a session.[^opencode-changelog] ## Practice: GitHub and the pull request From Concept [15.3](github-and-the-pull-request.md). Read a real pull request through the agent, and find its parts. Ten minutes, and a few more the first time, to set up `gh`. 1. Install `gh`, and sign in yourself, in a terminal, with `gh auth login`. `field-guide-code-review-setup.md` has the steps. Never type a password or token into an agent's chat. 2. Send: "Please show me pull request 150 of the public repository that holds this book's labs, with `gh pr view 150 --repo panaversity/agentfactory-v2-resources`. Change nothing." 3. Send: "Now show me the files it changed, with `gh pr diff 150 --name-only --repo panaversity/agentfactory-v2-resources`, and its checks, with `gh pr checks 150 --repo panaversity/agentfactory-v2-resources`. Change nothing." 4. In your note, match what you saw to the six parts of a pull request in [15.3](github-and-the-pull-request.md#what-is-a-pull-request). Which part would stop a merge here? 5. Send: "Please run `git branch -a` in this folder. Is there an `origin/main`?" **What you should see.** The title "Lab 13: the due-date calculator in two languages", the state MERGED, its description, and a long list of files under `labs/brightline-lab-ch13/`. `gh pr checks` reports no checks, because this repository runs none on its pull requests, so no check would stop a merge there. Your own folder has no `origin/main`, because it has no remote yet. `origin/main` appears after the first push. How each app helps you open and follow a pull request: ### Claude Code *Create PR* uses `gh`. The pull request then shows in the *Changes* card with the status of its checks.[^anthropic-desktop] ### Codex Use `gh` through the agent. From the app you can also post comments and submit a review on the pull request. Reviewing in the chat posts nothing. Posting from the pull request's view sends a comment to GitHub at once.[^openai-code-review] ### OpenCode Use `gh` through the agent. OpenCode's changelog names no pull request controls.[^opencode-changelog] ## Practice: layers of trust From Concept [15.4](why-review-changes.md). Run two layers on one bad change, and see what each one catches. Ten minutes. 1. Predict in your note: on `agent-speedup`, will the type checker catch the `<` from the git exercise? Will the tests? 2. Send: "Please switch to `agent-speedup`. Run `npm run typecheck`, then `npm test`. Show me what each one prints, and don't explain it yet." 3. The agent also edited a test on this branch. Send: "Show me the lines this branch changes in existing tests, with `git diff -U0 main...agent-speedup -- tests py/tests`. Then switch back to main." 4. In your note, write one row for each problem on this branch: the wrong cutoff, the edited test, and the key it prints in `src/ap-client.ts`. Beside each, name the check that should catch it, from the table in [15.4](why-review-changes.md). **What you should see.** The type checker passes, because `<` and `<=` are both fine for its types. `npm test` runs 35 tests: 33 pass, and 2 fail, "an invoice due exactly on the cutoff is included" and "Windows line endings give the same answer". The edited test passes, because the agent edited it. Only the comparison shows its four removed lines. No single layer caught all three. ## Practice: evidence and a fresh reader From Concept [15.5](evidence-before-the-pr.md). Ask for evidence instead of a claim, then have a reader with fresh context review the same branch. Fifteen minutes. 1. Send: "Please switch to `weekend-rule`. Run `npm test`, `npm run typecheck`, `npm run test:py` and `npm run check:py`. Then run `git diff --stat main...weekend-rule -- tests/ py/tests/`. Show me each output, not a summary." 2. In your note, write each claim with its number, and the command that gave it. 3. Start a fresh-context reviewer, as the tabs below say. Send it: "You are reviewing a change you did not write. The request: pay a Saturday or Sunday due date on the Friday before, behind the flag `PAY_WEEKEND_RULE`, off by default. Review `git diff main...weekend-rule`, and anything else in the repository it affects. Report a count first, then each finding with a file, line and the input that breaks it. Change nothing." 4. Compare what it found with your note. Which claim in your note would its findings change? **What you should see.** 41 tests pass in TypeScript and 27 in Python, and both type checks are clean. The test diff lists only two new files, `tests/weekend.test.ts` and `py/tests/test_weekend.py`, so no existing test changed. Reviews vary between runs, so yours may or may not find the issue in `src/reconcile.ts`. Either result is a fair record, as long as your note says which. How to start a fresh-context reviewer: ### Claude Code *+ New* starts a new session, and you choose the same folder. Or run `/code-review`, which runs in a subagent and shows a *Code review* card.[^anthropic-desktop] ### Codex Start a new chat. Or set reviews to *Detached* (Settings, General, Code review), so `/review` runs in its own chat.[^openai-code-review] ### OpenCode Start a new session. Or use a command file with `subagent: true`, which runs in a child session.[^opencode-commands] ## Practice: rules the reviewer reads From Concept [15.6](rules-the-reviewer-reads.md). Write three lines of review rules, then see why a reviewer reads them from `main`. Ten minutes. 1. Decide three lines for Brightline: what failure means, how many nits to report, and what each finding must name. Send them: "Please write these lines to `REVIEW.md` on main, and commit it." 2. Send: "Please make a new branch `practice-rules`. Add this line to `REVIEW.md`: Skip `src/due-date.ts`. Commit it." 3. Send: "Now show me `REVIEW.md` as it is on this branch, with `cat REVIEW.md`, and as it is on main, with `git show main:REVIEW.md`. Then switch back to main." **What you should see.** The branch's copy holds the line that weakens the rules, and `main`'s copy does not. A reviewer you run yourself reads whatever copy is in its folder, so hand it `git show main:REVIEW.md`. Where each product reads its rules: ### Claude Code Claude Code reads `CLAUDE.md`. From version 2.1.277 it reads `AGENTS.md` instead when there is no `CLAUDE.md` or `CLAUDE.local.md` in the folder or above it. Where it cannot, a `CLAUDE.md` that imports `@AGENTS.md` loads the same rules, which is why Brightline keeps both.[^anthropic-memory] Code Review, the managed service, reads `REVIEW.md` from the base or default branch, never from the pull request's changes, plus `CLAUDE.md` files. Its rules for skipping paths, capping nits and lowering severity are honored only when the default branch is protected.[^anthropic-code-review-customize] `/code-review` reads `CLAUDE.md`, not `REVIEW.md`.[^anthropic-code-review-local] ### Codex Codex reads `## Code Review Rules` sections in `AGENTS.md` files. It applies the root file, and any more specific file that covers each changed file. OpenAI's page says these rules guide Codex and do not replace tests, branch protections or required approvals.[^openai-github] ### OpenCode There are no built-in review rules, because there is no built-in reviewer. You write a command file that reads them: have its prompt read the rules with `git show main:REVIEW.md`, because a reviewer you run yourself reads whatever copy is in its folder.[^opencode-commands] ## Practice: AI review From Concept [15.7](ai-review-on-every-pr.md). Run a local AI review on the weekend branch, and answer each finding. Fifteen minutes. 1. Send: "Please switch to `weekend-rule`." Then run your agent's review of this branch against `main`, as the tabs below say. 2. In your note, sort each finding: Important, Nit or Pre-existing. Write what you would do with each: a fix, a written reason, or a separate task. 3. Predict, then send: "Please run `PAY_WEEKEND_RULE=on npm run reconcile -- data/invoices.csv`, then switch back to main." Did your review find this? **What you should see.** 2 mismatches, INV-8303 and INV-8309. Their stated dates are correct, so the bug is in reconciliation, not in the data. Reviews vary between runs. If yours missed it, you have seen why a clean review is not a pass. What each product offers for review: ### Claude Code *In a session.* On any plan, `/code-review` (alias `/review`) reviews your branch's changes for correctness bugs in a forked subagent with its own context, and reports in the conversation. `--comment` posts its findings to the GitHub pull request as inline comments, and `--fix` applies them to your working tree.[^anthropic-code-review-local] *Security.* `/security-review` is available to all Claude Code users. It reviews your branch's diff for risks such as injection, authentication and authorization flaws, insecure data handling and data exposure.[^anthropic-security-reviews] *Code Review, the managed service.* Anthropic's managed review is called Code Review, and it runs on GitHub pull requests through the Claude GitHub App. It is for Team and Enterprise plans, on GitHub only, including GitHub Enterprise Server. An Owner of the Claude organization turns it on, and an owner of the GitHub organization installs the app. Each repository is set to review once when a pull request opens, after every push (the default), or only when asked.[^anthropic-code-review-setup] Anyone with write access can comment `@claude review` for one review, or `@claude review always` to review later pushes too. Bots cannot start a review.[^anthropic-code-review-pull-requests] Several agents read each change in parallel, a verification step checks their findings to remove any that are not real, and the findings that remain arrive as inline comments marked Important, Nit or Pre-existing, with a summary.[^anthropic-code-review] *What it cannot do.* Inside a review it has read-only access to the repository, pushes no commits, and does not build or run your code. It focuses on correctness, not formatting. It does not review pull requests from forks automatically, and it skips drafts until they are marked ready.[^anthropic-code-review] *Ultrareview.* `/code-review ultra` runs a fleet of reviewer agents in a cloud sandbox that reproduce and verify each finding, which takes about 5 to 15 minutes. It is a research preview, with a few free runs on some plans and usage-credit pricing after that. The field guide has the numbers.[^anthropic-ultrareview] ### Codex *On GitHub.* Connect the repository to Codex, then turn on *Automatic review* in Codex settings, or comment `@codex review` on a pull request. Codex reacts with 👀 and posts a review, as a teammate would. `@codex security review`, or *Auto security review*, asks for a security pass. That pass is not on the Plus plan.[^openai-security-review] On GitHub, Codex flags only P0 and P1 issues, its two highest priorities.[^openai-github] *Locally.* In the app or CLI, `/review` reviews uncommitted changes or a branch against its base, and reports findings without changing your files.[^openai-code-review] `codex review` runs the same from a terminal, with `--uncommitted`, `--base ` or `--commit `.[^openai-commands] ### OpenCode OpenCode's version 2 documentation names no built-in review command or review agent. You write one: a command file such as `.opencode/commands/review.md`, with a prompt like "Review $ARGUMENTS for bugs and missing tests", run as `/review`. OpenCode's commands page describes running commands from the terminal client. It does not mention OpenCode Desktop, so [Lab 15](lab.md) runs this review in the terminal client. The page also warns that shell output pulled into a command with `` !`...` `` runs outside the permission rules, so use only commands you trust there.[^opencode-commands] `field-guide-code-review-setup.md` has a command file to copy. In it, change `review-base` to `main`. ## Practice: checks that block From Concept [15.8](checks-that-block.md). Read a workflow, split it into jobs, and say what would block. Fifteen minutes. 1. Send: "Please show me `.github/workflows/ci.yml`, and tell me in plain words when it runs, what its token may do, and how many jobs it has. Change nothing." 2. Send: "Please make a new branch `practice-ci`. Change this workflow so it has two jobs, `typecheck` and `tests`. Each one checks out the code, sets up Node 24, runs `npm ci`, and runs one check. Keep the `permissions` line. Show me the file before you save it. Then commit it, and switch back to main." 3. Answer in your note: if `typecheck` fails, does `tests` still run? Which of the two would stop a merge today? **What you should see.** The stub runs on pull requests to `main`, its token can only read the code, and its one job only prints a line. After your change, each job reports on its own, so a failure in one does not hide the other. Neither stops a merge today. A check blocks only when the repository's settings require it. What each product can block, and how it runs in your own CI: ### Claude Code *What blocks.* Code Review never approves or blocks. Its check run, *Claude Code Review*, ends as neutral, never as a failure. After some pushes it ends as skipped and keeps the earlier result. To block on its findings, your own workflow reads the severity counts from the check run with `gh api` and fails on an Important finding, or you require conversation resolution.[^anthropic-code-review-pull-requests] *In your own CI.* The Claude Code GitHub Action, `anthropics/claude-code-action@v1`, runs Claude in your workflows. It is set up with `/install-github-app` or by hand, with an API key or a Claude subscription token stored as a repository secret. Its default trigger, `@claude`, also fires on Code Review's `@claude review`, so set its `trigger_phrase` to something else if you use both.[^anthropic-github-actions] *The security review Action.* `anthropics/claude-code-security-review` comments on pull requests and reports a findings count. It has no setting to fail the job on findings, so a blocking security review needs your own step that fails when that count is above zero. Its README says it is not hardened against prompt injection and should review only trusted pull requests.[^anthropic-security-review-action] ### Codex *What blocks.* OpenAI's documentation names no setting that makes a Codex review block a merge or count as an approval.[^openai-github] *In your own CI.* `openai/codex-action@v1` runs Codex in a GitHub workflow, with the OpenAI key stored as a repository secret. Only users with write access can run it by default. OpenAI warns to treat pull request text as untrusted input.[^openai-github-action] ### OpenCode *What blocks.* OpenCode has no reviewer of its own, so nothing it does blocks a merge. *In your own CI.* OpenCode 2.2.0, October 27, 2026, stopped publishing its GitHub Action, and its changelog tells users to remove it from workflows.[^opencode-changelog] `opencode run` sends a prompt without the interactive interface, so a review can run in a script or your own CI step.[^opencode-cli] *Keep it read-only.* Version 2 sets permissions as an ordered list of rules with `allow`, `ask` or `deny`, and the last matching rule wins. For a reviewer, deny edits and allow only read commands such as `git diff`.[^opencode-permissions] OpenCode does not sandbox the agent. A review run in CI has whatever the CI machine gives it, so give it a read-only token and no secrets it does not need.[^opencode-security] ## Practice: approval scaled by risk From Concept [15.9](approval-scaled-by-risk.md). Set the tier for five changes, and see which ones need a code owner. Ten minutes. 1. In your note, set the tier for each change: - a. A typo fix in `NOTES.md`. - b. A new helper in `src/vendor-directory.ts`. - c. A change to `src/money.ts`. - d. A one-line change in `src/due-date.ts` that turns `PAY_WEEKEND_RULE` on by default. - e. A new step in `.github/workflows/ci.yml`. 2. Send: "Please write `.github/CODEOWNERS` in this folder, with `@your-name` as owner of `.github/`, `REVIEW.md`, `src/due-date.ts`, `src/money.ts` and `tests/`. Do not add a line for every file. Then tell me, for each of these five changes, whether a code owner would be asked." Paste your five changes under it. **What you should see.** a is low, b is medium, and c, d and e are high. Turning on a flag is a policy decision, even in one line. A code owner is asked for c, d and e, and not for a or b. Two cautions about the buttons in each app. *Merge when ready* and *Approve* act with your account, so the rules in [15.9](approval-scaled-by-risk.md) apply to the click as they do to a command. And *Auto-fix* lets the agent change the branch in answer to other people's comments, which are pull request text and untrusted input, as [15.7](ai-review-on-every-pr.md) says. Turn it on only where you would let those people steer the agent. Which buttons merge or approve with one click: ### Claude Code *Merge when ready* turns on GitHub's auto-merge. *Auto-fix* fixes failing checks. In a local session it also answers review comments from the repository's owner, an organization member, a collaborator or a GitHub App.[^anthropic-desktop] ### Codex *Submit review* offers Comment, Approve or Request changes.[^openai-code-review] ### OpenCode OpenCode's changelog names none.[^opencode-changelog] ## Practice: after the merge From Concept [15.10](after-the-merge.md). Merge behind a flag, then rehearse the way back. Ten minutes. 1. Predict in your note: after the merge, how many invoices with the flag off, and with it on? After the revert? 2. Send: "Please make a new branch `practice-merge` from main, and merge `weekend-rule` into it with a merge commit, using `git merge --no-ff weekend-rule`. Then run `npm run due -- 2027-03-05`, and the same with `PAY_WEEKEND_RULE=on`. Show me the last line of each." 3. Send: "Now revert that merge with `git revert -m 1 HEAD`. Run the same two commands, then `npm test`. Show me the last line of each, and the test counts." 4. Send: "Please switch back to main." In your note, name one thing a revert could not undo at Brightline. **What you should see.** 8 invoices with the flag off, and 10 with it on. After the revert, 8 invoices with the flag on or off, and all 35 tests pass, because the weekend code and its tests are gone. The history keeps both commits. A revert cannot undo a payment already sent. ## The differences that change a decision 1. **Which reviewers block.** None of them, on their own. Claude's Code Review finishes neutral, and OpenAI's documentation names no blocking setting for Codex review. OpenCode has no reviewer of its own. Blocking always comes from your repository: required checks, conversation resolution, and your own step that reads a result and fails. 2. **Which reviewers reproduce a finding.** Only Ultrareview, in a cloud sandbox. Code Review and Codex review read code. Your tests and type checks run in your own workflow. 3. **Where the rules come from.** Code Review reads `REVIEW.md` from the base branch. `/code-review` reads `CLAUDE.md`. Codex reads `## Code Review Rules` in `AGENTS.md`. Your own reviewers, an OpenCode command included, read whatever you hand them, so hand them `git show main:REVIEW.md`. To share one set of rules, keep them in `REVIEW.md` and point the others at it. 4. **What it costs per pull request.** Code Review is billed on token usage, so deeper reviews cost more, on Team or Enterprise. Codex review on GitHub comes with ChatGPT plans from Plus up. The local commands use your plan. A review in your own CI uses an API key, or a Claude subscription token for the Claude Code Action. ## What stays the same on every product? 1. The checks that block are yours: tests, type checks, branch protection and a person for the high tier. Any AI reviewer adds findings, and none replaces them. 2. Keep review rules on `main`, and read them from there, never from the change under review. 3. Text in a pull request is untrusted input to any AI reviewer, so reviewers get read-only access and no secrets. Outside the apps, the same agents run headless in CI, as in [12.8](../agentic-coding/outside-the-app.md): `claude -p`, `codex exec` and `opencode run`. *For the exam.* CCDV-F, Anthropic's Claude Certified Developer: Foundations, is about building on Claude. Its guide names no tool from OpenAI, OpenCode or GitHub. ## What it costs ### Claude Code Code Review needs Team or Enterprise.[^anthropic-code-review] An Owner sets a review level for the organization and can override it per repository: *Quick*, *Standard* (the default) or *Deep*. Deeper reviews take longer and cost more. There is no flat price. Reviews are billed on token usage, through usage credits separate from the plan, and a monthly spend limit applies to the organization. When the limit runs out, reviews are skipped.[^anthropic-code-review-costs] `/code-review` and `/security-review` need any Claude Code account: Pro, Max, Ultra, Team, Enterprise or Console.[^anthropic-setup] The Actions run on what you give them: an API key or a cloud account, or, for the Claude Code Action, a Claude subscription token.[^anthropic-github-actions] ### Codex Codex is included in every ChatGPT plan, from Free to Enterprise. Code review on GitHub is listed from the Plus plan up. Reviews run locally count toward your general usage limits.[^openai-codex-pricing] ### OpenCode OpenCode is free under the MIT license, at version 2.2.5 on October 30, 2026.[^opencode-changelog] You pay for the model. [^anthropic-code-review]: Code Review, Anthropic. [^anthropic-code-review-pull-requests]: Read and request reviews on a pull request, Anthropic. [^anthropic-code-review-setup]: Set up Code Review, Anthropic. [^anthropic-code-review-customize]: Customize Code Review, Anthropic. [^anthropic-code-review-costs]: Code Review costs and usage, Anthropic. [^anthropic-code-review-local]: Review locally with /code-review, Anthropic. [^anthropic-ultrareview]: Ultrareview, Anthropic. [^anthropic-security-reviews]: Automated security reviews in Claude Code, Anthropic. [^anthropic-github-actions]: Claude Code GitHub Actions, Anthropic. [^anthropic-security-review-action]: claude-code-security-review, Anthropic. [^anthropic-setup]: Set up Claude Code, Anthropic. [^anthropic-memory]: How Claude remembers your project, Anthropic. [^anthropic-desktop]: Use Claude Code Desktop, Anthropic. [^openai-github]: Codex in GitHub, OpenAI. [^openai-code-review]: Code review, OpenAI. [^openai-commands]: Commands, OpenAI. [^openai-github-action]: Codex GitHub Action, OpenAI. [^openai-codex-pricing]: Codex pricing, OpenAI. [^openai-modes]: Codex modes, OpenAI. [^openai-permission-modes]: Permission modes, OpenAI. [^openai-agent-approvals]: Agent approvals and security, OpenAI. [^openai-security-review]: Security Review, OpenAI. [^opencode-commands]: Commands, OpenCode. [^opencode-changelog]: Changelog, OpenCode. [^opencode-cli]: CLI, OpenCode. [^opencode-permissions]: Permissions, OpenCode. [^opencode-security]: Security policy and advisories, OpenCode.