What is AI code review? Claude Code, Codex, Cursor, Grok

AI code review is a coding agent reading a diff and reporting bugs, before you merge it. You still decide what to change. The review is a report, or a set of comments, unless you explicitly ask the tool to edit.

How AI code review works

A review starts from a change set. That can be uncommitted files, a branch compared with its base, a commit, or a pull request.

The reviewer reads that diff and the surrounding code, then writes findings. A local review usually drops them in the chat. A pull-request review posts them on the lines it is talking about.

Some commands stop at the report. Others can apply fixes. When they edit, those edits still go through the tool’s permission mode. A review that only reports leaves the working tree as it was.

A second agent is not automatically a better reviewer. If it only sees the same patch, it can miss the same requirement. Give it the behavior that must survive, the way the post on parallel agents argues.

AI code review in each tool

The four tools do not share one command. Claude Code, Codex and Cursor each document a reviewer. Grok Build documents workflows and a goal check, and does not document a /review command.

Claude Code

/code-review looks for correctness bugs. Depending on the model and effort, it also covers reuse, simplification and efficiency. It works on any plan. It runs in your session and counts toward usage.

With no target, it reviews commits on the branch that are ahead of upstream, plus uncommitted changes. No upstream means it compares against main, or against the previous commit. You can also pass a range, a branch comparison, a pull request number or a path. The target comes after an effort level and any flags.

/code-review
/code-review HEAD~15..HEAD
/code-review main...my-feature
/code-review 1234
/code-review src/auth

In a terminal session the review runs as a background subagent with its own context window. Findings arrive in the conversation when it finishes. It runs in the foreground in a non-interactive -p run or the Agent SDK, when CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1, or when you start /code-review again while one is already going. ultra does not wait in non-interactive mode.

--fix asks Claude to apply findings. Edits go through your permission mode. Without --fix, the instructions ask for a report only. --comment posts findings on a GitHub pull request as inline comments, or on a GitLab merge request as one note through glab. If glab is missing, Claude prints the findings in the terminal.

A background --fix edits outside the session’s checkpoints. After that, /rewind restores only files the conversation had already edited. Use git for the rest. A foreground review edits during your own turn, so /rewind restores those edits as usual.

The review follows CLAUDE.md, including in a -p run. It does not read REVIEW.md. That file configures the managed GitHub service. /code-review is a bundled skill, so there is no SKILL.md on disk. A project or personal skill named code-review replaces the bundled command. The /review alias keeps running the bundled review.

/code-review ultra runs a deeper cloud review, then can apply findings. It compares the current branch with the default branch, plus uncommitted and staged changes. It needs a claude.ai login. On Bedrock, Google Cloud Agent Platform, Microsoft Foundry, Zero Data Retention or HIPAA, it falls back to a local review. Organizations that use customer-managed encryption keys cannot run ultrareview.

The managed Code Review service is separate. It is for Team and Enterprise, on GitHub including GitHub Enterprise Server and GitHub Enterprise Cloud with data residency. It is not available with Zero Data Retention, HIPAA, or customer-managed encryption keys yet. Reviews run on Anthropic infrastructure. Several agents read the diff, a verification step filters findings, and the result is inline comments, a summary, and a check run named Claude Code Review. That check does not fail. A review never approves or blocks the pull request.

By default it looks for correctness bugs, not formatting or missing tests. It reads REVIEW.md from the base or default branch, never from the pull request’s own changes. Repository access during a review is read-only, and a review does not push commits. Someone with write access can comment @claude review. A repository can run a review once when a pull request opens, after every push, or only on request. Levels are Quick, Standard (the default) and Deep. Automatic reviews skip drafts and forks.

/simplify is cleanup only, and it applies its fixes. /verify runs the app. See Review locally with /code-review and Code Review.

OpenAI Codex

/review reviews the Git checkout. It does not change the working tree. If you later ask Codex to apply fixes, normal sandbox and approval settings apply.

In the CLI, /review offers four presets. Review against a base branch uses the merge base. Review uncommitted changes includes staged, unstaged and untracked files. Review a commit reviews that commit. Custom review instructions focus on criteria you type. The review shows up as a turn in the transcript. review_model in config.toml uses a different model from the session.

In the IDE extension, /review appears only inside a Git repo. The scopes are a base branch or uncommitted changes. chatgpt.reviewDelivery=detached starts a separate chat. In the desktop app, the review pane is the Git state of the repo, not only what Codex edited. Settings, then General, then Code review, then Detached starts a separate review chat.

GitHub code review is a separate path. Comment @codex review on a pull request. Use the exact trigger. A scoped comment looks like @codex review for issues in the database migration. Codex follows repository review guidance in AGENTS.md, at the root and in nested files such as services/experiment_reporting/AGENTS.md. When automatic reviews are enabled, they do not need that comment. Reviewing in the pull-request chat does not post, approve or merge until you submit a review.

The Code Review plugin in the desktop and web apps shows the pull request description, files, comments and checks. GitHub code review is generally available. GitLab merge request support in Code Review is preview. The IDE extension does not support plugins. /review in the IDE extension is still documented. See Review local changes and GitHub.

Cursor

Bugbot reviews pull request diffs for bugs, security issues and code quality. It comments with an explanation and a fix suggestion. It can run on each update, or when someone comments cursor review or bugbot run. It ignores those commands when a bot account or a GitHub App posts them. Existing pull request comments are context. Comments include Fix in Cursor and Fix in Web links.

Connect repositories from the Cursor dashboard. On GitHub, connecting turns Bugbot on for the repositories you grant. Those repos stay off when someone who is not a team admin connects an enterprise team, or a team that already has Bugbot on. On GitLab, Bitbucket, Azure DevOps and Origin, you turn Bugbot on per repository.

It skips a pull request over its default review-size limit and posts a comment asking to split the change. That skipped run records no review usage. The docs describe the limit as changed lines and diff characters, and they do not print the number on the page checked for this entry. Files marked linguist-generated in .gitattributes are left out of the review and do not count toward that limit.

The GitHub check is Cursor Bugbot. success means no issues and no unresolved earlier comments. neutral means findings, a run cancelled by a newer commit, or an internal error. Findings stay neutral unless fail-on-unresolved-issues is on, so requiring the check does not block a merge by itself. The Autofix check, Cursor Bugbot Autofix, is success or neutral only.

On an individual plan, Bugbot runs only on pull requests you author. Personal settings can limit it to mentions, or to once per pull request. Team and Enterprise plans run it for every contributor on enabled private repos. The public-repos switch, if nobody changed it, is on for teams created before October 22, 2026 and off for teams created since. Manual cursor review and bugbot run ignore that switch.

Optional repo config lives in .cursor/config/bugbot.yaml, read from the pull request’s base branch, not the head. A file over 64KB is ignored. Every field is optional. The author’s personal overrides win, then the yaml, then team or org dashboard settings. autofix.mode can lower a dashboard Autofix setting. It cannot turn Autofix on when the dashboard has it off.

Rules come from team rules, repository rules and .cursor/BUGBOT.md. The root file is always included. Nested files are included when Bugbot walks up from a changed file. Merge order is team rules, then project .cursor/BUGBOT.md including nested files, then learned rules, then manual rules. Each rule is cut at 30,000 characters. Linked .md and .mdc files count separately. The combined cap is 100,000 characters.

Agent Review is the local review inside Cursor. The setting is under Cursor Settings, then Agents, then Agent Review. The same page also places it under Git & PRs, then Pull Requests. It reads BUGBOT.md. It can run after every agent task, or stay manual. You start it automatically after every commit when that is enabled, with /agent-review, or from the Source Control tab, which compares all local changes against main. Depth is Quick or Deep. See Bugbot and Agent Review.

Grok Build

Grok Build does not document /code-review, /review, or a pull-request reviewer.

/create-workflow can save a review workflow. The docs’ own example is Review the current branch for bugs, then verify each finding. Grok writes .grok/workflows/<name>.rhai in the project, or ~/.grok/workflows/<name>.rhai for every project. You launch a saved workflow with /workflow <name>.

/goal is a different check. After the goal looks done, a panel of reviewer subagents looks at the work, and the goal is complete only when most of them agree. That verifies a goal you already set. It does not review a pull request. See Modes and commands.

Details checked against each vendor’s documentation in November 2026.

A real example

This reviews one directory in Claude Code, at high effort, and asks it to apply what it finds. The path is a real folder in this site. The effort word comes before the flag, and the path comes last, which is the order the command documents.

/code-review high --fix src/pages/ai-glossary

Edits still wait on your permission mode. If you only want the report, drop --fix.

On a Cursor repo, this is the documented Bugbot file, committed on the base branch. Every field is optional. This copy keeps the defaults the docs show.

# .cursor/config/bugbot.yaml
version: 1

triggers:
  drafts: false
  frequency: everyPush # everyPush | oncePerPr

review:
  effort: default # low | default | high | smart
  smartPrompt: ""
  incremental: true

prSummary:
  mode: comment # disabled | description | comment
  riskScore: true

autofix:
  mode: disabled # disabled | newBranch | existingBranch

In Grok Build, this is the documented way to save a review workflow. You launch it later with /workflow and the name Grok saved.

/create-workflow Review the current branch for bugs, then verify each finding

When to use AI code review

Use it on a change you are about to merge, when you can name what “wrong” means. A pull request number, a path, or a sentence like “issues in the database migration” gives the reviewer a target.

Use a report-only command when you want a list and you will edit yourself. Use --fix, or a later “apply this” turn, when the findings are small and you are ready to approve edits.

Use the managed GitHub reviewers (Claude Code Review, Codex on GitHub, Bugbot) when every pull request should get a pass without someone opening a local session.

Skip it as a substitute for tests. None of these commands claim a clean review means the change is correct. Plan mode is the earlier step, when you still want a written plan before any edit.

Pitfalls

A background /code-review --fix in Claude Code can edit files /rewind will not restore. Check git diff before you commit those edits.

REVIEW.md does not configure /code-review. It configures the managed GitHub service, and that service reads it from the base branch. A pull request cannot change its own review rules by editing REVIEW.md on the head. Bugbot works the same way with .cursor/config/bugbot.yaml: it reads the base branch, so the pull request under review cannot retune Bugbot.

Bugbot’s Smart effort reads your instructions plus the pull request title, author, repository name and a trimmed diff. It does not read the pull request description, labels or BUGBOT.md. If the rule lives only in BUGBOT.md, Smart will not see it when it picks an effort level.

Codex /review does not post to GitHub. Posting is a separate submit step, or a @codex review comment. Asking for a local review and expecting a pull request comment will look like a silent failure.

Grok Build’s /goal reviewers check a goal you set. They are not a code-review product. A workflow you save is only as specific as the description you gave /create-workflow.

Related on flaviocopes.com

• Run parallel coding agents without stepping on yourself is where a second reviewer helps, and where a vague “review this” does not.
• Engineering judgment when you build with AI covers giving a reviewer the failure you observed and the behavior that must survive.
• What to do with code after the alpha is the later pass over agent-written code, once the first review exists.
• Architecture Dissector maps an app so you can check the map against what the code does. The architecture diagram tutorial puts that map where a later session will read it.

Related glossary entries

• Subagents: A subagent is a helper your coding agent starts with its own context window. How subagents work in Claude Code, Codex, Cursor and Grok Build.
• Permission modes: Permission modes decide what a coding agent can do without asking. The modes in Claude Code, Codex, Cursor and Grok Build, and what YOLO mode really skips.
• Plan mode: Plan mode makes a coding agent research and propose a plan before it edits code. How it works in Claude Code, Codex, Cursor and Grok Build, and when to use it.

All AI glossary entries →

Want me to talk about your product? You can sponsor this site.