Claude Code GitHub Integration: What It Actually Buys

Claude code github integration is four different mechanisms with one name, and most of what people install it for is already on disk. We asked one session two questions against this repository with no GitHub integration of any kind: the one answerable from the clone took 2 turns and a single Bash call; the one that needed GitHub's API took 4 turns, three tool calls across two shells, and returned NOT_AVAILABLE. That split is the whole decision. Measured 2026-09-12 on Claude Code 2.1.269, Windows 11.

Key takeaways

• Four surfaces share the name, and only one charges context on every request.
• A repository question was answered with one tool call and no integration at all.
• A pull request question could not be answered, at almost identical cost — $0.0933 against $0.0941.
• This repository has 65 commits, 9 carrying a Claude co-author trailer, and zero workflow files, so the Actions path is unwired here.
• claude --from-pr 1 with no credentials exited 0 with an empty stderr and started an ordinary session.

Four integrations wearing one name

They differ in what you install, what they cost before they do anything, and which questions they can answer:

Rows two and three answer the same questions at very different prices. Row one answers a surprising number of them for free, which is the finding the next section is about.

The line git already answers

We asked, with only file and shell tools available and nothing GitHub-shaped installed:

How many commits on this repository's current branch were co-authored by Claude,
and what is the GitHub remote URL? Answer in one line.

One Bash call, two turns, 11,547 ms, $0.0941:

9 commits on `main` include a `Co-Authored-By: Claude` trailer, and the GitHub
remote is https://github.com/MuhammadKashif10/devventa.

Both facts came from the clone. git log holds every commit message and git remote holds the URL, so an integration would have bought nothing. The same is true of blame, history, branches, tags, diffs between refs, and who last touched a file. The repository is not the part of GitHub you are missing.

The numbers themselves are worth a glance: 9 of 65 commits carry the trailer, and 52 of 65 subjects are a single word — the same habit our review-scope measurement found makes a diff harder to read than it needs to be.

The question that failed

Second question, same session shape, same tools:

How many open pull requests does this repository have on GitHub right now?
If you cannot determine it, say NOT_AVAILABLE and why.

Four turns, three tool calls, 16,396 ms, $0.0933:

NOT_AVAILABLE — the `gh` CLI isn't available in Bash on this machine, and the
PowerShell tool requires approval to run `gh` commands that wasn't granted, so
I can't query GitHub's PR count right now.

It tried gh pr list in Bash, then reached for PowerShell twice — the cross-shell fallback this project has measured on Windows before. Pull requests, issues, review threads, check runs and releases live on GitHub's servers and in no clone. That set is exactly, and only, what a claude github mcp server or the gh CLI is for.

The cost line is the uncomfortable part: failing cost the same as succeeding, within a cent. An agent with no route to an answer still spends turns finding that out.

Choosing between the CLI and the MCP server

Both reach the same API. The difference is when you pay.

The gh CLI costs nothing until it is called, because it is one more command to a shell the agent already has. Its cost is a permission decision — you are allowing an authenticated binary to act on your repositories — which belongs in a rule rather than an approval prompt each time. See Claude Code permissions for the shape of that rule.

A GitHub MCP server exposes typed tools, which the model uses more reliably than it composes CLI flags, and its tool definitions are in context on every request whether or not you touch GitHub that turn. That is the trade this site measured across a five-server fleet in multiple MCP servers: startup is paid once, definitions are paid forever.

The rule we use: occasional GitHub work goes to gh; a recurring workflow that reads pull requests every session justifies the server. Neither was measurable here — gh is installed on neither shell on this machine and we hold no token for the server — so those two rows of the table carry no numbers, deliberately.

The Actions path and claude pr review

The fourth surface runs nowhere near your terminal. Install the GitHub app, commit a workflow, and a mention on an issue or pull request starts a session inside GitHub Actions that can comment and push. Anthropic's GitHub Actions documentation covers the setup; what matters for the choice is that it costs no local context at all and is the only one of the four that responds when you are not there.

This repository has zero workflow files. There is no .github directory, so despite a live remote and 65 commits, that path is entirely unwired — the same gap our workflow audit found across CI, git hooks and npm lifecycle scripts. It is recorded in the check rather than quietly fixed, because an unused integration is a real state that a lot of repositories are in.

For a claude pr review the local route is usually better anyway: check the branch out and the diff is already on disk, which is what the review command operates on. Reserve the Actions path for reviews that must happen without you.

The entry point that fails open

claude --from-pr <number> resumes a session linked to a pull request. We expected it to error in a repository with no gh and no linked session. It did not:

claude --from-pr 1 -p --output-format json "hi"
# → exit 0, stderr empty
# → "is_error": false
# → "result": "Hi! What are we working on today?"

An ordinary session, no warning, nothing on stderr. A mistyped PR number, a repository with no linked sessions, and a missing credential all look identical to a successful launch. If a script depends on being attached to a PR's session, assert on something from that conversation rather than on the exit code.

What did not work

Two of the four surfaces could not be measured here. gh is on neither shell on this machine and the MCP server needs a token this project does not hold. Their context costs are named as the thing to measure and left without numbers, rather than estimated into a table that would look complete.

--from-pr was going to be the article's error message. It was in the outline as a clean example of a loud failure. It exited 0 with an empty stderr, so the section became a warning about silence instead.

The first framing was a ranking. The plan was to rank the four surfaces. Two of them answer identical questions and could not be separated on this machine, so the article gives a decision rule keyed to what is in the clone, which is the thing we could actually measure.

Best practices

• Start with no integration. Ask a week of real questions and note which ones git could not answer.
• Split by location, not by feeling. History, blame and diffs are local. Pull requests, issues, reviews and checks are not.
• Prefer gh for occasional work — it costs nothing until it runs.
• Reserve the MCP server for recurring GitHub work, and add it alone so its per-request cost is visible.
• Use the Actions app for reviews that must happen without you, not for work you are present for.
• Assert on content, not exit codes, for anything PR-linked.
• Write a commit-message rule you can check. Nine of 65 trailers here is a measurement, not a target.

Common mistakes

Installing a GitHub server to read your own repository. It is already on disk. You have added per-request weight for questions git log answers.

Assuming a failed lookup is cheap. Our unanswerable question cost within a cent of the answerable one and took two more turns.

Trusting --from-pr silently. It starts a normal session when it cannot link one, and says nothing.

Installing the Actions app and stopping there. Without a workflow file the app does nothing; this repository's zero workflows are the state a lot of repositories are actually in.

Granting a token wider scope than the question needs. A read-only token answers every question in the second arm of this test.

Conclusion

Ask the questions first, install second. If what you need is history, blame or a diff, Claude Code already has it and a claude code github integration buys you nothing but context weight — measured here at one tool call and eleven seconds for a question two integrations would have charged for. If what you need is pull requests, issues, reviews or checks, pick gh for occasional use and an MCP server for a daily workflow, and add one at a time so you can see what each costs.

Frequently asked questions

Muhammad Kashif

Founder and editor of Devventa, covering AI coding assistants, Next.js and the modern AI development stack.