Of all the MCP servers available for Claude Code, the GitHub integration gets used the most. Once it's configured, Claude can read PR diffs, post review comments, create and search issues, and check CI status — all without leaving your terminal session. It turns Claude Code from a local coding assistant into something that can actually participate in your team's review process.
Setting up the GitHub MCP server
You'll need a GitHub Personal Access Token. Use a fine-grained token (not a classic token) — they let you scope permissions precisely.
Go to GitHub Settings → Developer settings → Personal access tokens → Fine-grained tokens and create a token with:
- Repository access: Select specific repos, or All repositories if you work across many
- Permissions:
- Repository:
Contents(read) - Repository:
Pull requests(read and write) - Repository:
Issues(read and write) - Repository:
Metadata(read — required) - Repository:
Checks(read — for CI status)
- Repository:
Don't grant write access to Contents unless you need Claude to push commits via the MCP server directly. Most workflows use Claude Code's built-in file tools for edits and git via Bash for commits — the MCP server handles the GitHub API layer.
Add the server to your global settings so it's available in every project:
claude mcp add github --global \
-e GITHUB_PERSONAL_ACCESS_TOKEN=ghp_your_token_here \
-- npx -y @modelcontextprotocol/server-github
Or manually in ~/.claude/settings.json:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here"
}
}
}
}
Restart Claude Code, then verify it's working:
What GitHub tools do you have available?
You should see a list of tools like get_pull_request, create_issue, list_pull_requests, search_code, and more.
What Claude can do with GitHub access
Once connected, you're not crafting API calls or reading raw JSON. Claude understands the semantics of GitHub objects — it knows what a PR diff means, what an issue label implies, and how review comments relate to specific lines of code.
Read PR diffs and file changes
Claude can fetch the full diff for a PR, understand which files changed, and reason about the changes in context.
Post PR review comments
Claude can post inline comments on specific lines, submit review summaries, and request changes — all via the API.
Create and update issues
Pass Claude a description of a bug and it'll create a properly formatted issue with reproduction steps.
Search and filter issues and PRs
List open PRs by author, find bugs older than 30 days, search for issues mentioning a specific function name.
Check CI status
Claude can read the check runs on a commit or PR to see which checks are failing and surface the relevant log output.
Search code across repos
GitHub's code search API lets Claude find usages of a function, pattern, or string across your entire organization.
Practical workflow 1: PR review
This is where the GitHub integration earns its keep. Instead of context-switching to the GitHub UI, you can have Claude review a PR while you stay in your terminal:
Review the diff in PR #142 in myorg/myrepo. Look for:
- Security issues (especially in auth-related code)
- N+1 query patterns in database calls
- Missing error handling
- Any changes that break the existing API contract
Post your findings as a PR review with inline comments on the specific lines.
Claude will:
- Fetch the PR metadata and full diff
- Analyze the changes against your criteria
- Post inline comments on specific files and lines
- Submit a review summary
The quality depends on the diff size. PRs under ~500 lines of changes get thorough reviews. Very large PRs (2000+ lines) benefit from narrowing the focus: "Only review the changes in src/auth/."
Reviewing for a specific concern
Sometimes you don't want a full review — you want one focused question answered:
Look at PR #89 in myorg/api-service. Does the new rate limiting middleware
correctly handle the case where Redis is unavailable? Show me the relevant code
and explain whether the fallback behavior is safe.
This is often more useful than an open-ended review. Claude stays focused and gives you a concrete answer.
Practical workflow 2: Issue triage
Issue backlogs accumulate fast. Claude can help you get on top of them without reading every ticket:
List all open issues in myorg/myrepo labeled "bug" that were created more than
30 days ago. Summarize each one in one sentence, group them by which part of
the codebase they affect (auth, payments, notifications, other), and tell me
which three look most critical based on the description.
Or for a daily standup prep:
What GitHub issues and PRs were updated in myorg/myrepo in the last 24 hours?
Give me a quick summary of what's moving.
Practical workflow 3: Creating issues from conversations
When you find a bug while working, you can capture it as a GitHub issue without context-switching:
We just found a memory leak in the WebSocket connection handler — connections
aren't being cleaned up when clients disconnect unexpectedly. Create a GitHub
issue in myorg/myrepo with:
- A clear title
- Description of the bug
- Steps to reproduce (use what we just discussed)
- Expected vs actual behavior
- Label it "bug" and "performance"
Claude creates the issue with all the context from your current conversation. No copy-pasting, no reformatting.
Claude Code in GitHub Actions
You can run Claude Code as a step in your CI/CD pipeline. The most common pattern: trigger a Claude Code review when someone comments on a PR.
Here's a GitHub Actions workflow that does exactly that:
name: Claude Code Review
on:
issue_comment:
types: [created]
jobs:
claude-review:
# Only run if the comment is on a PR and mentions @claude
if: |
github.event.issue.pull_request &&
contains(github.event.comment.body, '@claude')
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Install Claude Code
run: npm install -g @anthropic-ai/claude-code
- name: Get PR diff
id: pr-diff
run: |
gh pr diff ${{ github.event.issue.number }} > pr_diff.txt
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Run Claude Code review
run: |
claude --headless --print \
"Review this PR diff and post a summary comment on PR #${{ github.event.issue.number }}.
Focus on correctness and potential bugs.
$(cat pr_diff.txt)" \
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
GITHUB_PERSONAL_ACCESS_TOKEN: ${{ secrets.GITHUB_TOKEN }}
The --headless flag is important — it makes Claude Code non-interactive, suitable for automated pipelines. The --print flag outputs Claude's response to stdout instead of an interactive terminal.
Security for CI/CD
Keep permissions minimal:
permissions:
contents: read # Read the code
pull-requests: write # Post review comments
# Nothing else
Never use permissions: write-all. Store the ANTHROPIC_API_KEY as a repository secret (Settings → Secrets and variables → Actions). Never hardcode it in the workflow file.
Using the gh CLI as an alternative
Even without the MCP server, Claude Code can interact with GitHub using the gh CLI through its Bash tool. The gh CLI is pre-installed on GitHub-hosted runners and is straightforward to install locally.
Use `gh` to list all open PRs in this repo that are more than 3 days old
and have no reviewers assigned.
Claude will construct and run the appropriate gh commands:
gh pr list --state open --json number,title,createdAt,reviewRequests \
| jq '[.[] | select(.reviewRequests | length == 0) |
select((now - (.createdAt | fromdateiso8601)) > 259200)]'
The gh approach works well for ad-hoc queries. The MCP server is better for workflows where you're repeatedly interacting with GitHub across a session — it gives Claude richer context about available operations and more reliable structured outputs.
For evaluating how well your GitHub-integrated workflows actually perform, the approaches in evaluating agents apply directly: define success criteria upfront, test with real PRs and issues, and measure whether Claude's reviews are catching the bugs you care about.
Common issues and fixes
"Resource not accessible by personal access token"
Your token doesn't have the right permissions for that operation. Fine-grained tokens need explicit permission grants per repo and per operation type. Check the token's permission configuration on GitHub.
Claude doesn't know about a recently created PR
The MCP server uses the GitHub API in real time, so this usually isn't a caching issue. More likely Claude is looking at the wrong repo — confirm you're specifying owner/repo in your prompt.
Review comments posted to wrong lines
GitHub's line commenting API uses position values from the diff, not file line numbers. The MCP server handles this translation, but very large diffs or binary file changes can confuse it. If comments land in wrong places, switch to a review summary comment instead of inline comments.
Rate limits
The GitHub API has rate limits: 5,000 requests/hour for authenticated requests. If you're hitting limits in CI (multiple workflow runs in parallel), consider using a GitHub App token instead of a personal access token — Apps get higher rate limits.