DEV Community

Manoj Swami
Manoj Swami

Posted on

AI PR Reviews With Claude Code, Codex, GitHub CLI, and MCP

#ai #codereview #claude #codex

AI coding agents are becoming useful for more than writing code. One of the best practical use cases is pull request review.

Most engineering teams already spend a lot of time on repetitive PR checks:

  • Does this change match the intended behavior?
  • Are there obvious bugs?
  • Did the author miss edge cases?
  • Are tests missing?
  • Is the change too broad?
  • Are there risky database, auth, or payment changes?
  • Does the PR description match the diff?

An AI agent can help with this work if it has the right context and the right permissions. The goal is simple:

Paste a GitHub PR link.
The agent fetches the PR.
The agent reviews the diff.
The agent writes review comments.
The agent posts the comments to GitHub when allowed.
Enter fullscreen mode Exit fullscreen mode

This article explains how to build that workflow with Claude Code, Codex, GitHub CLI, and the GitHub MCP server.

The setup is designed for engineering teams, private repositories, and real PR review workflows. It is not a toy demo.

What We Are Building

We want one repeatable PR review workflow that works in both Claude Code and Codex.

The final setup looks like this:

GitHub PR URL
    |
    v
Claude Code or Codex
    |
    +-- GitHub CLI (`gh`) for auth, PR metadata, diffs, checks, and fallback posting
    |
    +-- GitHub MCP server for structured GitHub tool calls
    |
    v
AI-generated review findings
    |
    v
Draft comments or posted PR comments
Enter fullscreen mode Exit fullscreen mode

There are two important parts:

  1. Tool access: The agent must be able to read PRs and post comments.
  2. Agent behavior: The agent must know how to review PRs consistently.

Installing GitHub MCP or gh gives the agent access. It does not automatically teach the agent your review policy.

For a reliable workflow, configure both:

  • GitHub access through gh and MCP.
  • Global Claude/Codex rules that define how PR reviews should work.

Why Use Both GitHub CLI and MCP?

You can review PRs with only gh, and you can do many GitHub tasks with MCP. In practice, using both is better.

GitHub CLI

The GitHub CLI is stable, scriptable, and easy to debug.

It is useful for:

  • checking authentication;
  • reading PR metadata;
  • reading changed files;
  • reading diffs;
  • checking CI status;
  • posting normal PR review comments;
  • falling back when MCP tools are limited.

For example:

gh pr view https://github.com/OWNER/REPO/pull/123
gh pr diff https://github.com/OWNER/REPO/pull/123 --name-only
gh pr checks https://github.com/OWNER/REPO/pull/123
Enter fullscreen mode Exit fullscreen mode

GitHub MCP

MCP, or Model Context Protocol, lets an AI agent call tools in a structured way.

The GitHub MCP server can expose tools for repositories, issues, pull requests, review comments, and GitHub Actions.

This is useful because the agent does not need to scrape command output. It can call a GitHub tool and receive structured data.

Why both?

Because PR review needs reliability.

Use MCP when it gives clean structured access. Use gh when you need a direct, debuggable command.

For teams, this hybrid approach is easier to maintain than depending on one path for everything.

Recommended Safety Model

There are two possible ways to run this workflow.

Option 1: Draft-first review

This is the safest default.

The agent reviews the PR and writes exact comments, but it does not post them until you approve.

Use this mode when:

  • your team is new to AI reviews;
  • your repos are high-risk;
  • the agent is still being tuned;
  • you want humans to stay fully in the loop.

Option 2: Auto-post review comments

This is faster, but riskier.

The agent reviews the PR and posts comments directly to GitHub.

If you use this mode, limit it to PR review comments only.

The agent should be allowed to:

  • post a summary review comment;
  • post normal PR comments;
  • post inline review comments when the line mapping is clear.

The agent should not be allowed to:

  • merge PRs;
  • close PRs;
  • approve PRs;
  • request changes;
  • push branches;
  • force-push;
  • delete comments;
  • edit PR metadata;
  • add or remove labels;
  • change repository settings.

For most teams, I recommend starting with draft-first and moving to auto-post only after the team trusts the workflow.

Prerequisites

You need:

  • macOS or Linux;
  • GitHub CLI installed;
  • Docker installed if you run the local GitHub MCP server;
  • Claude Code installed if you want Claude support;
  • Codex installed if you want Codex support;
  • access to the repositories you want to review.

Check gh:

gh --version
Enter fullscreen mode Exit fullscreen mode

Check Claude Code:

claude --version
Enter fullscreen mode Exit fullscreen mode

Check Docker:

docker --version
Enter fullscreen mode Exit fullscreen mode

Step 1: Authenticate GitHub CLI

Start by authenticating gh.

gh auth login --hostname github.com --git-protocol https --web --scopes "repo,read:org,workflow"
Enter fullscreen mode Exit fullscreen mode

Recommended scopes:

  • repo: read private repositories and post PR comments;
  • read:org: access organization-owned repositories;
  • workflow: inspect workflow files and GitHub Actions context when needed.

After login, verify:

gh auth status
Enter fullscreen mode Exit fullscreen mode

Then test a real repository:

gh pr list --repo OWNER/REPO --limit 3
Enter fullscreen mode Exit fullscreen mode

If your organization uses SAML SSO, GitHub may require extra authorization. If gh returns 404 for a private org repo that you can open in the browser, check SSO authorization in your GitHub token settings.

Step 2: Choose a GitHub MCP Transport

There are two common ways to connect GitHub MCP.

Option A: Remote GitHub MCP

Some environments can use GitHub's remote MCP endpoint.

This is convenient because you do not need Docker.

The shape is usually:

https://api.githubcopilot.com/mcp/
Enter fullscreen mode Exit fullscreen mode

This may require GitHub Copilot access and a compatible client.

Option B: Local Docker GitHub MCP Server

This option works well across both Claude Code and Codex.

It runs the official GitHub MCP server locally through Docker.

Pull the image:

docker pull ghcr.io/github/github-mcp-server:latest
Enter fullscreen mode Exit fullscreen mode

For a shared setup, use a wrapper script. The wrapper gets the token from gh auth token, so you do not paste secrets into config files.

Create:

$HOME/.local/bin/github-mcp-server-wrapper
Enter fullscreen mode Exit fullscreen mode

Content:

#!/bin/sh

export GITHUB_PERSONAL_ACCESS_TOKEN="$(gh auth token)"
export GITHUB_TOOLSETS="repos,issues,pull_requests,actions"

exec docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN \
  -e GITHUB_TOOLSETS \
  ghcr.io/github/github-mcp-server
Enter fullscreen mode Exit fullscreen mode

Make it executable:

chmod +x "$HOME/.local/bin/github-mcp-server-wrapper"
Enter fullscreen mode Exit fullscreen mode

Why use a wrapper?

Because it avoids storing a GitHub token in multiple places.

Your token remains managed by gh. Claude Code and Codex call the wrapper. The wrapper starts the MCP server with the token at runtime.

Step 3: Register GitHub MCP in Claude Code

Add the MCP server:

claude mcp add --scope user github -- "$HOME/.local/bin/github-mcp-server-wrapper"
Enter fullscreen mode Exit fullscreen mode

Verify:

claude mcp list
claude mcp get github
Enter fullscreen mode Exit fullscreen mode

Then open a Claude Code session and check MCP tools:

/mcp
Enter fullscreen mode Exit fullscreen mode

You should see the GitHub server and its available tools.

Step 4: Register GitHub MCP in Codex

Add the MCP server to your Codex config.

The exact config path is usually:

$HOME/.codex/config.toml
Enter fullscreen mode Exit fullscreen mode

Add:

[mcp_servers.github]
command = "/Users/YOUR_USER/.local/bin/github-mcp-server-wrapper"
args = []
Enter fullscreen mode Exit fullscreen mode

Use your real home path. If your Codex version supports environment expansion in this file, you can use that. Otherwise, use the absolute path.

Restart Codex after changing the config.

Then ask Codex to list or use GitHub MCP tools.

If your Codex install already has a GitHub plugin enabled, keep it enabled. The plugin and MCP server can work together:

  • the plugin gives a higher-level GitHub workflow;
  • MCP gives direct structured GitHub tools;
  • gh remains a reliable fallback.

Step 5: Add a Claude Code PR Review Command

Tool setup is not enough. Claude also needs a clear workflow.

Create a global Claude command:

$HOME/.claude/commands/pr-review.md
Enter fullscreen mode Exit fullscreen mode

Example command content:

# PR Review

Review the GitHub pull request provided by the user.

Input:
- A GitHub PR URL.

Workflow:
1. Fetch PR metadata, title, description, author, base branch, and head branch.
2. Fetch changed files and diff.
3. Fetch CI/check status when available.
4. Fetch existing review comments when available.
5. Review the change for correctness, regressions, missing tests, security issues, data risks, and maintainability.
6. Produce findings ordered by severity.
7. If posting is allowed by the current policy, post a concise PR review comment.
8. Inline comments are allowed only when the changed line is unambiguous.

Rules:
- Do not merge, close, approve, request changes, label, or push.
- Do not post vague style comments.
- Prefer high-signal comments with specific file and line references.
- If line mapping is uncertain, put the finding in the summary review instead of posting an inline comment.
Enter fullscreen mode Exit fullscreen mode

Now you can use:

/pr-review https://github.com/OWNER/REPO/pull/123
Enter fullscreen mode Exit fullscreen mode

Step 6: Add a Codex PR Review Skill

For Codex, create a global skill:

$HOME/.codex/skills/github-pr-review/SKILL.md
Enter fullscreen mode Exit fullscreen mode

Example:

---
name: github-pr-review
description: "Review GitHub pull requests from a PR URL using GitHub MCP, the GitHub plugin, and gh CLI when useful."
---

# GitHub PR Review

Use this skill when the user provides a GitHub PR URL and asks for review.

## Workflow

1. Resolve the PR owner, repo, and number from the URL.
2. Fetch PR metadata, changed files, diff, checks, and existing review context.
3. Review for correctness, regressions, missing tests, security issues, data risks, and maintainability.
4. Prefer findings that are specific, actionable, and tied to changed code.
5. Post comments only if the user's policy allows posting.

## Posting Rules

- Summary comments may be posted as PR review comments.
- Inline comments may be posted only when commit, file path, side, and line are known.
- If inline placement is uncertain, use the summary comment.
- Never merge, close, approve, request changes, label, delete comments, or push branches.

## Output

If not posting:
- Show findings ordered by severity.
- Include a ready-to-post review body.

If posting:
- State what was posted and where.
Enter fullscreen mode Exit fullscreen mode

Now you can ask Codex:

Use github-pr-review on https://github.com/OWNER/REPO/pull/123
Enter fullscreen mode Exit fullscreen mode

Step 7: Add Global Rules for Both Agents

This is the step many teams miss.

If you only install tools, each agent may behave differently. One session may use gh, another may use MCP, and another may ask you for every action.

Add a short global rule to both:

  • ~/.claude/CLAUDE.md
  • ~/.codex/AGENTS.md

Example:

## GitHub PR Review Policy

When the user provides a GitHub PR link and asks for review:

1. Use GitHub MCP, the GitHub plugin, or `gh` to inspect the PR.
2. Fetch metadata, description, changed files, diff, checks, and existing comments where available.
3. Review for correctness, regressions, missing tests, security, data risk, and maintainability.
4. Prefer specific findings over generic advice.
5. Post comments only according to the configured posting mode.

Allowed automatic write actions:
- Post a normal PR review comment.
- Post a PR timeline comment.
- Post an inline review comment only when line mapping is exact.

Never perform these actions automatically:
- merge PRs;
- close PRs;
- approve PRs;
- request changes;
- push commits;
- force-push;
- delete or edit comments;
- change labels;
- edit PR title, body, assignees, reviewers, or milestones.
Enter fullscreen mode Exit fullscreen mode

This gives both clients the same behavior.

Step 8: Configure Posting Mode

Decide how much autonomy you want.

Draft-first mode

Use this rule:

Default to draft-first PR review. Prepare exact comments, but do not post until the user explicitly says to post.
Enter fullscreen mode Exit fullscreen mode

This is best for most teams.

Explicit auto-post mode

Use this rule:

If the user explicitly asks to post PR review comments, post them without a second confirmation.
Enter fullscreen mode Exit fullscreen mode

This is a good middle ground.

Always auto-post mode

Use this only when you trust the workflow.

For PR review requests, post review comments automatically without asking again. This applies only to PR comments and inline review comments. It does not apply to merge, approve, request-changes, close, push, label, or metadata-edit actions.
Enter fullscreen mode Exit fullscreen mode

Even in auto-post mode, keep destructive actions blocked.

Step 9: Claude Code Permissions

Claude Code may ask for permission before shell commands or MCP writes.

If you want fewer prompts, allow only narrow GitHub review commands.

Example allowlist entries:

[
  "Bash(gh auth status)",
  "Bash(gh auth token)",
  "Bash(gh pr view:*)",
  "Bash(gh pr diff:*)",
  "Bash(gh pr checks:*)",
  "Bash(gh pr list:*)",
  "Bash(gh pr comment:*)",
  "Bash(gh pr review:*)",
  "Bash(gh api:*)"
]
Enter fullscreen mode Exit fullscreen mode

Be careful with broad MCP wildcards like:

"mcp__github__*"
Enter fullscreen mode Exit fullscreen mode

That can allow more write tools than you intended.

A safer approach:

  1. Install the MCP server.
  2. Inspect the exact tool names.
  3. Allow only PR read and PR comment tools.

Step 10: How Summary Review Posting Works

For a normal review summary, the agent can use:

gh pr review https://github.com/OWNER/REPO/pull/123 \
  --comment \
  --body-file review.md
Enter fullscreen mode Exit fullscreen mode

This creates a PR review comment.

This is safer than inline comments because it does not require exact diff line mapping.

A good review summary should look like this:

I found two issues worth addressing before merge:

1. `src/billing/calculate.ts`: the new discount branch skips tax calculation when the discount is 100 percent. That changes invoice totals for fully discounted subscriptions. Add a test for a 100 percent discount with non-zero tax.

2. `src/api/users.ts`: this endpoint now returns `email` for suspended users. Previously that field was hidden. If the old behavior was intentional, keep the filter or update the API contract.
Enter fullscreen mode Exit fullscreen mode

Keep comments short, specific, and tied to the diff.

Step 11: How Inline Review Comments Work

Inline comments are more useful, but also more fragile.

To post a correct inline comment, the agent needs:

  • repository owner;
  • repository name;
  • pull request number;
  • commit SHA;
  • file path;
  • side of diff;
  • changed line number.

If any of these are uncertain, do not post inline.

Use the summary review instead.

Bad inline comments create noise. A misplaced comment is worse than no inline comment.

What the Agent Should Review

A good AI PR review should focus on real engineering risk.

Useful review categories:

  • correctness bugs;
  • behavior changes;
  • missing tests;
  • security issues;
  • authorization problems;
  • data loss risk;
  • database migration risk;
  • concurrency issues;
  • performance regressions;
  • broken API contracts;
  • confusing naming;
  • overly broad changes;
  • hidden production risk.

Less useful categories:

  • personal style preferences;
  • vague maintainability comments;
  • comments that just repeat the code;
  • suggestions unrelated to the PR;
  • large refactor ideas that do not block the change.

The agent should behave like a senior reviewer, not a linter.

Example End-to-End Workflow

After setup, a developer can paste:

/pr-review https://github.com/OWNER/REPO/pull/123
Enter fullscreen mode Exit fullscreen mode

Or in Codex:

Use github-pr-review on https://github.com/OWNER/REPO/pull/123
Enter fullscreen mode Exit fullscreen mode

The agent should:

  1. Identify the repository and PR number.
  2. Fetch PR metadata.
  3. Fetch changed files.
  4. Read the diff.
  5. Check CI status.
  6. Read existing review context.
  7. Find real issues.
  8. Prepare comments.
  9. Post comments if the configured mode allows it.
  10. Summarize what it posted.

Verification Checklist

Run these checks after setup.

GitHub CLI 

gh auth status
gh pr view https://github.com/OWNER/REPO/pull/123
gh pr diff https://github.com/OWNER/REPO/pull/123 --name-only
Enter fullscreen mode Exit fullscreen mode

Docker MCP 

docker pull ghcr.io/github/github-mcp-server:latest
"$HOME/.local/bin/github-mcp-server-wrapper"
Enter fullscreen mode Exit fullscreen mode

The wrapper starts an MCP server over stdio, so it may look like it is waiting. That is normal.

Claude Code 

claude mcp list
claude mcp get github
Enter fullscreen mode Exit fullscreen mode

Then open Claude Code and run:

/mcp
Enter fullscreen mode Exit fullscreen mode

Codex

Restart Codex after editing config.

Then ask:

What GitHub MCP tools are available?
Enter fullscreen mode Exit fullscreen mode

Disposable PR Test

Create or use a low-risk test PR.

Test:

  • summary review comment;
  • inline comment on a clear changed line;
  • draft-first mode if enabled;
  • auto-post mode if enabled;
  • blocked destructive actions.

Troubleshooting

gh says you are not logged in

Run:

gh auth login --hostname github.com --git-protocol https --web --scopes "repo,read:org,workflow"
Enter fullscreen mode Exit fullscreen mode

Then:

gh auth status
Enter fullscreen mode Exit fullscreen mode

Private org repo returns 404

This is often SAML SSO.

Open GitHub token settings and authorize the token for the organization.

Docker MCP does not start

Check Docker:

docker ps
Enter fullscreen mode Exit fullscreen mode

If Docker Desktop is not running, start it.

Claude does not show GitHub MCP

Run:

claude mcp list
claude mcp get github
Enter fullscreen mode Exit fullscreen mode

If missing, register again:

claude mcp add --scope user github -- "$HOME/.local/bin/github-mcp-server-wrapper"
Enter fullscreen mode Exit fullscreen mode

Codex does not see GitHub MCP

Check ~/.codex/config.toml.

Make sure the command path is absolute and executable.

Then restart Codex.

Inline comments fail

Use a summary review comment instead.

Inline comments need exact diff location data. If the PR changed since the agent fetched the diff, line mapping may be stale.

Comments are too noisy

Tighten the global review policy.

Add rules like:

Do not post comments for subjective style preferences.
Do not post comments unless they identify a real correctness, security, testing, data, or maintainability risk.
Prefer one summary review over many low-value inline comments.
Enter fullscreen mode Exit fullscreen mode

Security Checklist

Before enabling auto-post, check:

  • Does the agent have only the GitHub permissions it needs?
  • Are tokens stored outside project repos?
  • Are tokens excluded from shell history?
  • Are destructive GitHub actions blocked?
  • Are broad MCP wildcards avoided?
  • Is auto-post limited to PR comments only?
  • Is there a test PR for smoke testing?
  • Does the team know comments are public and auditable?

Do not paste PATs into project files.

Do not commit MCP config files that contain secrets.

Prefer wrappers that read from gh auth token or secure environment files.

Recommended Team Policy

For most teams, I recommend this policy:

AI can review any PR when given a PR link.
AI can draft comments by default.
AI can post comments only when the prompt explicitly asks it to post.
AI can never merge, approve, request changes, close, label, push, or edit PR metadata automatically.
Inline comments are allowed only when line mapping is exact.
Enter fullscreen mode Exit fullscreen mode

This policy gives you speed without giving up control.

If the team later trusts the workflow, you can allow auto-post for comments only.

Why This Works

The important idea is separation.

GitHub CLI and MCP provide access.

Global commands, skills, and rules provide behavior.

Without the rules, the agent may still review PRs, but behavior will vary by session. It may ask for confirmation, skip existing comments, ignore CI, post too much, or choose the wrong tool.

With the rules, the workflow becomes predictable:

Read the PR.
Understand the diff.
Check the context.
Find real issues.
Comment clearly.
Avoid destructive actions.
Enter fullscreen mode Exit fullscreen mode

That is the difference between a demo and a workflow your team can actually use.

Final Thoughts

AI PR review is not a replacement for engineering ownership.

It is a second reviewer that never gets tired, never skips the diff because it is late, and can quickly check the boring parts.

The best results come when you give the agent:

  • the right tools;
  • the right permissions;
  • the right review policy;
  • a safe posting model;
  • clear limits.

Start with draft-first reviews. Watch the quality. Improve the rules. Then decide whether auto-posting is safe for your team.

The end goal is not more comments.

The goal is better reviews with less wasted time.

Happy Coding!

Top comments (0)