Claude Code unveils two ways to auto-review every pull request

Claude Academy, run by Anthropic, has released the seventh lesson in its nine-part Claude Code course, this time covering how to get Claude to automatically review every pull request. A pull request is the process where a developer's code changes get checked by a colleague before being merged. There are two ways to plug Claude into that process: turning on Code Review, a managed service Anthropic runs itself, or setting up the Claude Code GitHub Action, which development teams configure on their own.

A managed service you just switch on

Code Review is a service that reviews pull requests through the Claude GitHub app and posts its findings as inline comments on the relevant lines of code. An organization admin turns the feature on in the Claude Code admin settings, installs the Claude GitHub app, and then chooses which repositories to watch and when reviews should run. The options are: when a pull request opens, on every push, or whenever someone comments "@claude review." The actual review work is handled by multiple review agents running on Anthropic's infrastructure, which analyze the changes against the full codebase, tag issues by severity, post them as inline comments, and attach a summary table to the check run. It's designed to filter out duplicates and prioritize what matters, so developers see a short list of things actually worth their attention instead of a pile of minor nitpicks. The service is currently available as a research preview for Team and Enterprise plans.

No approvals, no automatic fixes

What's worth noting is what Code Review does not do. The service never makes the call to approve or block a pull request — that judgment always stays with a human. It also doesn't fix the issues it finds; its job ends once the comments are posted. To actually apply those fixes to the code, a developer has to run the "/code-review" command in their own terminal to re-review the diff, then add the "--fix" flag to apply the changes to the working tree. Automated review stops there; a human has to check and execute the rest.

For anything beyond review, use the GitHub Action

If you want to go further than review — fixing code based on comment instructions, generating reports on a schedule, or reacting to specific GitHub events — you need to set up the Claude Code GitHub Action yourself. Setup starts by running the "/install-github-app" command inside Claude Code, which requires repository admin permissions. Running the command walks you through installing the GitHub app and registering your Anthropic API key as a secret in the repository.

The action is called "anthropics/claude-code-action@v1," and it takes the following inputs: a required Anthropic API key; a GitHub token, which defaults to "secrets.GITHUB_TOKEN"; a trigger phrase that determines what comment text the action responds to (the default is "@claude"); a prompt carrying the instructions to execute; and Claude arguments, a CLI argument string passed straight through to Claude Code. Organizations using Bedrock or Vertex can also switch the provider to those instead.

A workflow example you can copy directly

Drop these values into ".github/workflows/claude.yml" and you get a workflow that listens for "@claude" in pull requests and issue comments. If someone writes "@claude implement the spec in the linked Linear issue" on a pull request, the action picks that up, has Claude push a commit, and comments back on what it did. You can set up a daily report workflow the same way — a cron job fires at 9 a.m. UTC, Claude compiles the results and posts them — and adding a "workflow_dispatch" trigger lets you also run it manually from the Actions tab.

The finer details get tuned in the Claude arguments line. In the video, the example sets "max-turns" to 5 to cap how many turns the agent can loop through, sets "permission-mode" to "don't ask" to run in an unattended mode without human confirmation, and for read-only reporting tasks, opens "allow-tools" only as wide as that task actually needs.

Comparing the two approaches

Item	Code Review (managed)	GitHub Action (self-configured)
Who sets it up	Org admin enables it in settings	Repo admin installs it directly
Scope of execution	PR review only	Broader post-review work (implementation, reports, event handling)
Approve/block authority	None	Depends on workflow design
Auto-fix	None; local /code-review --fix only	Can commit changes depending on the prompt
Requirements	Research preview, Team/Enterprise plans	Repo admin permissions and an API key

Editor's view

What this lesson shows is Anthropic splitting code review automation into two layers. The top layer is a managed service you just switch on, lowering the barrier to entry, while the bottom layer is an open-ended action where you touch Claude arguments and workflow events yourself, giving you full flexibility. That two-layer structure is a pattern we've seen repeat before, in the /design skill and the plugin marketplace covered earlier. Claude Code seems to be settling into a habit of shipping every feature with both a one-click path for beginners and a hands-on tuning path for power users.

Older generations of code review bots were mostly rule-based, catching style violations or lint errors and not much else. Code Review goes a step further by analyzing changes against the entire codebase and ranking them by severity — but notably, it deliberately withholds approve/block authority and auto-fix authority even as it takes on more capability. That's a narrower grant of power even as the capability grows, and it reads less like a safety feature bolted on and more like a realistic design choice for a function that hasn't yet earned full trust.

For development teams in Korea, splitting usage across the two paths makes sense. When first adopting this, it's reasonable to turn on managed Code Review under a Team or Enterprise plan and spend a few weeks watching how useful the inline comments actually are. If what you really need is automation beyond review — say, handing off implementation through issue comments or generating regular reports — that's the natural point to move to the GitHub Action. When you do set up the action, it's much easier to build in habits like capping runs with max-turns and opening allow-tools only as wide as the task requires from the start, rather than trying to walk back overly broad permissions later.

In the coming weeks, it wouldn't be surprising to see the managed service drop its research-preview label, expand to more pricing tiers, or gain an auto-fix option. But the decision to hand pull request approval authority over to AI will almost certainly come much later, and much more cautiously.