Claude Code + GitHub: The Integration Patterns That Ship Real Code

Claude Code plugs into GitHub three ways. One, the terminal CLI uses the regular git binary, so any repo cloned locally already works. Two, the GitHub MCP server lets Claude read issues, comment on PRs, and triage from inside a session. Three, the anthropics/claude-code-action GitHub Action runs Claude on every PR or every @claude mention, directly inside Actions. At Formaum I run all three, one per layer of the workflow.

Most write-ups stop at "install the MCP server." That's the easy part. The real question is which pattern belongs at which layer, what token scopes you should actually grant, and how to wire it so Claude ships PRs without you babysitting it. That's what this post covers.

The 3 integration patterns

Pick the pattern by the layer of the workflow. They are not alternatives. I use all three on the same repo.

Layer                          Pattern
-----                          -------
Local build + commits          Claude Code CLI + git
Issue triage + PR comments     GitHub MCP server
Automated PR review            claude-code-action (GitHub Action)

The CLI is what runs on my laptop. The MCP server is what lets a local Claude session reach into GitHub without me leaving the terminal. The Action is what runs in the cloud, on every PR, without me being there at all.

Pattern 1: Claude Code in your terminal plus git CLI

This is the default. You install Claude Code, you cd into a repo, you run claude, and git is already there. No GitHub integration needed for the basic loop.

cd ~/repos/client-project
claude

> create a branch called fix/webhook-timeout
> the issue is in src/handlers/onboarding.ts, the retry logic
  fires after the timeout instead of before it. fix it, add a test,
  commit, and push the branch.

Claude runs git checkout -b, edits the file, runs your test command, commits with a real message, and pushes. From there I open the GitHub UI and open the PR by hand, or I let the MCP server do it (next section).

The rule for this layer: keep secrets in your local environment, not the Claude session. Claude Code reads .env if you let it. It should not. Add .env to .gitignore, and add it to .claude/settings.json as a denied path so the model cannot read it even on accident.

Pattern 2: GitHub MCP server

The MCP server is how Claude reads and writes GitHub without you tabbing to the browser. It exposes tools like list_issues, create_pull_request, add_comment, get_pr_files, and similar. Install it once, it works everywhere.

Install via the Claude Code MCP system:

claude mcp add github -s user -- npx -y @modelcontextprotocol/server-github

Then set the token in your shell environment:

export GITHUB_PERSONAL_ACCESS_TOKEN=ghp_xxx

What you can do now from inside Claude:

> list open issues on genevieve-ui/client-project labeled bug
> pick issue #42, read it, write a fix on a new branch, open a PR
  that closes it, and post a summary comment on the issue

The MCP server makes Claude a participant in the repo, not just a code generator on a file system. The use shift is real. I keep a triage session open in the morning and let Claude clear small bugs before I touch the bigger work.

Pattern 3: Claude Code GitHub Action

The Action is the cloud version. It runs Claude inside GitHub Actions on a trigger you choose. Two main modes: respond to @claude mentions in issues and PR comments, or run on every PR automatically.

Easiest setup is from the terminal:

claude
> /install-github-app

This installs the Claude GitHub App on the repo, adds your ANTHROPIC_API_KEY as a secret, and drops a workflow file into .github/workflows/. You need to be a repo admin to run it.

The minimal workflow for @claude mentions:

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
  issues:
    types: [opened, assigned]

permissions:
  contents: write
  pull-requests: write
  issues: write

jobs:
  claude:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

That's it. Someone comments @claude fix the failing test on this PR, Claude picks it up, pushes a commit to the PR branch, posts a summary. Reviews show up in a minute or two.

For automatic review on every PR (no mention required), add a separate workflow:

name: Claude PR Review
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Review this PR. Flag bugs, missing tests, and security issues. Skip style nits."
          claude_args: "--max-turns 8 --model claude-sonnet-4-6"

Two workflows. One responds to humans. One runs automatically. They live side by side.

Security: what token scopes you actually need

This is the part most tutorials skip. The Claude GitHub App, when installed via /install-github-app, asks for three permissions on the repo:

Contents:       Read & Write
Issues:         Read & Write
Pull requests:  Read & Write

That is the floor. Do not grant more. In particular:

Do not give Claude Actions write. That lets it edit your workflows. A model that can edit its own workflow file can grant itself more access. Keep workflow edits manual.

Do not give Claude Admin or Secrets scope. Ever. There is no workflow that requires it.

For the MCP server, use a fine-grained personal access token, not a classic PAT. Scope it to the specific repos you want Claude in, and to the three permissions above. A classic PAT with repo scope hands Claude every private repo on your account. Don't.

Put the API key in repo secrets, not in the workflow file. Obvious, but I have caught this in real client repos. ${{ secrets.ANTHROPIC_API_KEY }} only.

If you self-host the runners, lock down what they can reach. The default GitHub-hosted runners are fine. Self-hosted runners with access to your production network are how a PR review turns into a supply-chain incident.

The workflow I use for client work

Every client repo at Formaum has the same shape. Three layers, one purpose each.

Local. Claude Code CLI plus the GitHub MCP server. This is where I build. I work on branches, never on main. Claude opens the PRs through the MCP server.

Cloud (interactive). The @claude action. Clients and collaborators can tag @claude on a PR or issue and get a fix or an answer without me touching it. This is how I scale my responsiveness without scaling my hours.

Cloud (automatic). The PR review action runs on every PR. It catches the obvious stuff before a human ever opens the diff. I still do the architecture review. Claude does the first pass on bugs, missing tests, and security smells.

The CLAUDE.md file at the repo root is shared by all three layers. Write it once. Every layer respects it. That is the actual unlock.

Common mistakes

Token scoped too broad. Classic PAT with full repo scope, granted org-wide. Now Claude has read-write on every private repo. Use fine-grained tokens, one per project, with the minimum scope.

No PR review gate. Claude commits straight to main because the workflow has no branch protection. Turn on branch protection. Require at least one review on PRs. Let Claude open the PR, but never let it merge without a human.

Auto-commit without review. Wiring Claude to commit on every prompt with no diff gate is how you wake up to a half-built migration on main. Run with default permissions in client repos. Reserve --dangerously-skip-permissions for sandboxes you do not care about.

No CLAUDE.md in the repo. Without it, the Action has no idea what your conventions are. Every review reads like a junior engineer who has never seen your codebase before. Twenty lines of CLAUDE.md fixes most of it.

Treating the Action as a chat bot. It is not. It is a build step. Wire it to your test suite, your linter, and your deploy pipeline. The use is in the orchestration, not the conversation. That is the infrastructure that makes an AI system actually run on a Tuesday at 3am when nobody is watching.

Genevieve Claire

Founder, Formaum — Claude Code Expert & Full-Stack AI Engineer

Builds bespoke AI automation systems for multi-location operations. Previously EA Sports FIFA ($7B franchise) and Film/TV VFX on Skyfall, Avengers, Game of Thrones. Based in Vancouver, BC.