Claude Code GitHub app: PR reviews and comment triggers

Most fractional leaders treat GitHub like a filing cabinet. Code goes in, pull requests get opened, things get reviewed when someone gets to them. The Claude Code GitHub app changes that entirely. It turns GitHub itself into a live interface for Claude -- reviewing pull requests automatically and responding to instructions you leave in comments, without you ever opening a terminal.

The real shift is what this means for multi-client work. You're not always the one committing code. With this integration, you can deploy Claude directly from GitHub to do meaningful work on any repository it has access to, whether you're online or not.

What the GitHub app actually does

Two distinct capabilities ship with the Claude Code GitHub app, and they're worth separating clearly.

Automatic PR review. The moment a pull request opens, Claude reviews it and posts a comment with its findings. No tagging required, no manual trigger. It runs on its own as a GitHub Action.

@Claude mentions. Tag @claude anywhere inside GitHub -- pull request comments, issue threads, review discussions -- and Claude picks up the task, executes it against the codebase, and responds in that same thread. This works beyond just PRs. If a client or colleague files a bug report in your issues tab, you can tag Claude in the comments with a specific instruction: "Fix this and open a PR." Claude does it.

The underlying mechanism is GitHub Actions. These are automations that GitHub runs server-side when specific events happen. You don't need to be online, your machine doesn't need to be running, and Claude Code doesn't need to be open. The actions run in GitHub's infrastructure.

> For operators managing multiple client repos: You can install the app across separate GitHub organizations and personal accounts. Each repo gets its own workflow files after the setup merge, so access and behavior stay isolated per client.

Setup walkthrough

The install flow runs inside Claude Code itself. Open a session in the repository you want to connect, type / and scroll to the install github app command, then press Enter.

Claude Code will confirm the current repository and start the setup sequence. Here's what happens at each step:

The setup PR is not cosmetic. It adds the actual GitHub Actions workflow files to your repository. The actions only run after that PR is merged.

Your API key is not your subscription

Claude Code as a desktop tool runs against your Claude subscription. The GitHub app integration runs against the Anthropic API directly. That means it bills per token, on a separate account.

To create the key, go to console.anthropic.com, navigate to API Keys, and generate a new one. Give it a name that identifies exactly what it's for -- something like github-app-fractionalco-repo -- so you can rotate it later without guessing which key does what. Paste it into the Claude Code setup prompt when asked.

Volume will be modest for most operator workflows. PR reviews on typical code changes run a small number of tokens per action. That said, track API spend monthly so you can account for it against client engagements if needed.

Keep this key secure. Anyone with access to it can run API calls billed to your account. Do not commit it to a repository, do not paste it into Slack, and do not reuse it across tools. Generate a dedicated key for this integration so you can revoke access to just this one surface if needed.

What happens after you merge the setup PR

Once merged, the workflows are live. During the setup process, Claude Code creates an initial PR specifically to test the installation. It runs both actions and posts a status comment. The whole verification typically completes in about two minutes. When both checks turn green, the integration is confirmed.

After that, no further configuration is required. The workflows trigger automatically:

• When a PR opens -- Claude runs a code review and posts findings as a PR comment
• When someone mentions @claude -- Claude reads the instruction, executes it against the repo, and responds in that thread

You can watch actions run in real time. Inside any GitHub repository, the Actions tab shows every workflow execution with status, logs, and timing. For teams that haven't worked with GitHub Actions before, this integration is a useful first introduction to what that infrastructure can do.

The @Claude mention pattern in practice

The PR review feature is straightforward. The @mention feature deserves more attention because the range of things you can trigger is broader than it first appears.

Here are patterns that map well to fractional operator contexts:

Bug reports as work orders. A client files an issue describing unexpected behavior. Tag @claude in the issue comments: "Investigate this bug and open a PR with a fix." Claude reads the issue, searches the codebase for the relevant code, writes the fix, and opens a PR -- all from one comment.

Targeted review questions. You open a PR and want Claude to focus on a specific concern rather than do a general review. Leave a comment: "@claude what does this change do to error handling in the checkout flow?" Claude reads the diff in context and answers directly in the thread.

Documentation requests. After merging a feature, tag Claude in the PR: "@claude update the README to reflect this new API endpoint." Claude reads the current README, reads the merged PR, and makes the update.

Cross-team handoffs. You're not the codebase owner on a client engagement, but you can still dispatch Claude to do an initial investigation of a reported issue by mentioning it in the right thread. The findings come back as a comment visible to everyone with repo access.

> What Claude can and cannot do from GitHub. Claude can read files, write code, and open PRs. It cannot deploy, merge PRs on its own, or access systems outside the repository. Every action it takes still produces a PR that a human reviews before merging. The human review step stays in the workflow.

Connecting this to your multi-client workflow

For fractionals managing four or five client engagements, the practical value here is coverage. You're not always watching every repository in real time. With automatic PR review active, a review runs on every PR regardless of whether you're the one looking at it. That creates a consistent quality baseline across repos even when your attention is divided.

The @mention capability extends that further. On repositories where you've set client team members up with GitHub access, they can tag Claude themselves for specific questions or tasks. Claude responds in the thread, the conversation is logged in GitHub, and you can review what was asked and what was done at any time.

If you're managing five client codebases, that's five repos where code quality reviews happen automatically, and five sets of issues where you or your clients can dispatch Claude by leaving a comment. The bottleneck shifts from "someone needs to look at this" to "someone needs to merge this." That's a meaningfully different constraint.

Verify before you rely on it

One recommendation before you start routing real work through this: confirm the setup is solid.

After merging the setup PR, run a small test. Create a branch, make a trivial change (a single line edit to a non-critical file), open a PR, and watch what happens in the Actions tab. Confirm the Claude Review action completes successfully. Then leave an @claude comment and confirm it responds.

This takes ten minutes and gives you confidence the integration is working before a client engagement depends on it.

> If an action fails during setup: Check the Actions tab for the error log. The most common issues are an invalid or expired API key, or the setup PR not having been merged yet. Both are straightforward to fix.