# Connect Claude to GitHub with MCP

Add GitHub's remote MCP server to the Claude Code CLI with one
`claude mcp add` command, then authenticate. After that Claude reads your issues,
pull requests, and code directly, so you stop pasting issue text and diffs into
the chat. This guide shows the exact setup and the checks that confirm it worked.

Add the server, confirm it connected, then ask for a summary of open pull requests. Illustrative session.

If MCP is new to you, read [MCP fundamentals](/guides/mcp-fundamentals) first for
the host, client, and server model. Here you connect one real server end to end.

## What can Claude do with GitHub?

Once the server is connected, you ask Claude to do GitHub work in plain language
and it acts on the live data instead of a snapshot you pasted:

- "Read issue #142 and draft a fix plan."
- "Review PR #456 and list the risky changes."
- "Show every open pull request assigned to me."
- "Find where `parseToken` is defined across the repo."

Claude calls the server's tools to fetch issues, PRs, file contents, and search
results, then works from what comes back. You never leave the terminal.

## The two pieces you connect

GitHub publishes a hosted MCP server, so you do not install or run anything
locally. You point Claude Code at its URL and prove who you are with a token.

- **The server URL** · `https://api.githubcopilot.com/mcp/`. This is GitHub's
  remote endpoint. Claude Code reaches it over HTTP.
- **A GitHub token** · a personal access token that tells GitHub which repos
  Claude may touch and what it may do with them.

Because the server is remote, the connection uses the HTTP transport, not a local
subprocess. That matters for the flags you pass below.

## Step 1: create a GitHub token

Open your GitHub token settings and generate a new fine-grained personal access
token. Grant it access to only the repositories you want Claude to work with,
and only the permissions you need.For a repo owned by an organisation, a fine-grained token often needs an org admin to approve it before it works, and until then you get a "connected but no tools" or "cannot see the repo" state, not a clear error. Check the org's Personal access tokens settings (or ask an admin) so the token is approved for that org.

For reading and acting on issues, PRs, and code, these repository permissions
cover the common cases:

| Permission | Access | Lets Claude |
| --- | --- | --- |
| Contents | Read | Read file contents and branches |
| Issues | Read and write | Read issues, create them, comment |
| Pull requests | Read and write | Read PRs, open them, review, comment |
| Metadata | Read | List repos and basic repo info (required) |

Start with Read access everywhere if you only want Claude to look, never change
anything. You widen to Read and write later when you want it to open issues or
PRs. Copy the token when GitHub shows it. You see it once.

Secrets belong out of your shell history and out of version control. Paste the
token only into the command below, and never commit it to a repo.

## Step 2: add the server

Run this in your terminal. Replace `YOUR_GITHUB_PAT` with the token you just
created:

```bash
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_PAT"
```

Reading the command left to right:

- `claude mcp add` registers a new server.
- `--transport http` selects the HTTP transport for a remote server. Without it,
  Claude Code does not know how to reach the URL.The easy slip is leaving off `--transport http`. The default transport is stdio, so Claude Code treats the GitHub URL as a local program to launch, then fails with a confusing "command not found" or a server stuck on "failed" instead of a clear network error. For any hosted endpoint, pass `--transport http` (or `--transport sse` if the server uses it) so the CLI talks over the network rather than spawning a subprocess.
- `github` is the name you give the server. You use this name later with
  `claude mcp get github` and `claude mcp remove github`.
- The URL is GitHub's hosted endpoint.
- `--header "Authorization: Bearer YOUR_GITHUB_PAT"` sends your token on every
  request so GitHub knows it is you.

That writes the server into your config. By default it lands at local scope,
which means it is private to you and active only in the project where you ran the
command.

## Step 3: confirm it connected

List your servers to confirm the entry exists:

```bash
claude mcp list
```

Then start Claude Code and open the MCP panel:

```bash
claude
```

```text
/mcp
```

The `/mcp` panel shows each connected server and the number of tools it exposes.
A healthy GitHub entry shows a connected status and a tool count above zero. If
the server needs a browser sign-in, the panel walks you through it.

Now ask Claude a read-only question to prove the data flows:

List the five most recently updated open issues in this repository, with their numbers and titles.

If Claude returns real issue numbers and titles from your repo, the connection
works. If it cannot reach GitHub, jump to Troubleshooting below.

## How does a GitHub request flow through Claude?

When you ask Claude something that needs GitHub, this is the round trip:

Claude decides which tool to call, the CLI sends the call to the GitHub server
with your token attached, the server returns the data, and Claude works from
that result. You see the answer, not the wiring.

## Which scope should I use?

The scope decides which projects see the server and whether your team shares it.
You set it with `--scope`:

| Scope | Loads in | Shared with team | Stored in |
| --- | --- | --- | --- |
| local (default) | Current project only | No | Your home config |
| project | Current project only | Yes, via version control | `.mcp.json` in the repo |
| user | All your projects | No | Your home config |

For a token tied to your own account, keep the default local scope or use `user`
scope so the server follows you across projects:

```bash
claude mcp add --transport http github --scope user https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_PAT"
```

Avoid `project` scope for this server. Project scope writes a shared `.mcp.json`
into the repo, and you do not want a personal token committed there. If you want
a team-shared `.mcp.json`, reference the token through an environment variable
instead of pasting it. Claude Code expands `${VAR}` inside `.mcp.json`:

```json
{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${GITHUB_PAT}"
      }
    }
  }
}
```

With that file in the repo, each teammate sets their own `GITHUB_PAT` in their
environment and the secret stays out of version control.

## Daily use

With the server connected, you give GitHub work to Claude the same way you give
it any task. Concrete prompts get concrete answers.

Read and plan from an issue:

```text
Read issue #142 in this repo. Summarize the bug in two lines, then list the files you would change to fix it. Do not edit anything yet.
```

Review a pull request:

```text
Review PR #456. List correctness risks first, then style notes. For each item give the file and a one-line reason.
```

Triage your queue:

Show every open pull request assigned to me, sorted by oldest first, with the repo name and title for each.

You combine GitHub with your local checkout in one request. Claude reads the
issue from GitHub, then edits files in your working tree:

```text
Read issue #142, apply the fix to src/auth/session.ts, run the test suite, and tell me what changed. Stop before committing.
```

## Reference an issue or PR by mention

If the server exposes its data as resources, you pull a specific item into
context with an `@` mention instead of describing it. Type `@` in your prompt to
browse what is available, then reference one directly:

```text
Analyze @github:issue://142 and suggest a fix.
```

The referenced item is fetched and attached to your message, so Claude reads the
real issue rather than your paraphrase of it.

## How do I keep the token safe?

A token is a key to your repos. For the broader picture of what to allow and what to block, see [MCP security basics](/guides/mcp-security-basics). Two habits keep the risk low:

- **Start read-only.** Grant Read access first. Confirm Claude reads issues and
  PRs the way you expect before you grant write access. You widen permissions
  when you have a reason, not by default.
- **Scope to repos you name.** A fine-grained token can list the exact
  repositories it reaches. Pick them by hand. A token that touches one repo
  cannot harm the rest of your account.

A server that pulls in outside text, like issue bodies written by other people,
can carry instructions aimed at the model. This is prompt injection. Read what
Claude proposes before you let it write to GitHub or push changes, the same way
you review a teammate's pull request before merging.

## Troubleshooting

**The token is rejected.** If you set the `Authorization` header and GitHub
rejects it, Claude Code reports the connection as failed rather than retrying.
Check that the token has not expired and that it grants access to the repo you
are asking about. Regenerate the token and run `claude mcp remove github`, then
add it again.

**The panel shows no tools.** A connected server with zero tools usually means
the token lacks permission for any toolset. Confirm the token includes at least
Metadata read plus the permissions in Step 1.

**Claude cannot see a repo.** Fine-grained tokens reach only the repositories
you selected when you created them. Edit the token in GitHub settings to add the
repo, or generate a new token that includes it.

**Check or remove the server.** Inspect the saved configuration or remove it
entirely with these:

```bash
claude mcp get github
claude mcp remove github
```

## Where to go next

You now have one real server connected and verified. The same `claude mcp add`
pattern connects other services: an error tracker, [a database](/guides/connect-claude-to-your-database), [a folder of notes or docs](/guides/connect-claude-to-your-notes). Each
follows the steps you just ran, pick the transport, name the server, pass the
credential, then confirm with `/mcp`. For the model behind all of it, the host,
client, and server roles, see [MCP fundamentals](/guides/mcp-fundamentals).