#Vibe Coding#MCP

Hands-On: Connect GitHub to Claude Code with MCP

Use MCP to let Claude Code read issues, open PRs, inspect CI, edit files, and submit changes. This guide covers the official remote MCP server, a self-hosted local server, configuration, practical workflows, and safe token permissions so AI-assisted development can close the loop in GitHub.

Key Points

  • Topic Focus: Vibe Coding、MCP
  • Suitable for: indie hackers, full-stack engineers, AI application developers
  • Core value: quickly understand background, practical paths, common pitfalls, and engineering advice
Author @admin·Published July 26, 2026·Updated July 26, 2026

Writing code with Claude Code feels great, but after finishing, you still have to switch to a browser to open a PR, inspect CI, or reply to an issue. MCP eliminates that disconnect by connecting GitHub to Claude Code, allowing the Agent to operate repositories, issues, PRs, and CI directly. Only then does the workflow truly become a closed loop.

1. Two routes: a remote MCP Server vs a self-hosted local server

Route A: GitHub's official remote MCP Server. GitHub provides an official MCP Server over HTTPS. You can use it with a simple configuration, and it covers common capabilities for issues, PRs, repositories, and CI. This is the right route for the vast majority of people because there is nothing to build yourself, and GitHub handles maintenance.

Route B: a self-hosted local MCP Server. If you need to connect to GitHub Enterprise or require custom capabilities beyond GitHub, such as your company's internal project management tools, build one yourself by wrapping the GitHub API with the MCP SDK. Only a small number of use cases require this.

Start with A. Move to B only if A is not enough.

2. Configure it in Claude Code

Add the GitHub MCP Server to the project's .mcp.json, which can be shared with the repository, or to the global configuration:

jsonc
// .mcp.json
{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer <YOUR_GITHUB_TOKEN>"
      }
    }
  }
}

How to get the token: In GitHub, go to Settings → Developer settings → Personal access tokens (fine-grained), create one, and select only the required permissions:

  • Repository read access for viewing issues, PRs, and code
  • Issue and PR read/write access if you want the Agent to open PRs or reply to issues
  • Workflow access if you want to trigger CI

Follow the principle of least privilege: do not give a classic token full repo access. A fine-grained token grants access per repository and per operation, limiting the impact if it leaks.

3. Secure ways to configure the token

Storing the token in .mcp.json creates a leak risk if the file is accidentally committed to Git. There are two safer approaches:

1. Environment variables + .gitignore. Use a variable placeholder in .mcp.json and read the actual value from the environment. Claude Code supports env injection:

jsonc
{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer ${GITHUB_MCP_TOKEN}" }
    }
  }
}

Commit .mcp.json to Git, but keep the token in .env, which is covered by .gitignore, or in the system keychain.

2. Use global configuration instead of project configuration. Configure the GitHub server at the user level in ~/.claude.json rather than at the project level, keeping the token out of the repository.

4. Practical usage: close the workflow loop

After configuration, restart Claude Code and it will be able to use GitHub capabilities. Here are several scenarios that deliver real productivity gains:

1. "Read issue #123, implement it in the current repository, and open a PR" The Agent reads the issue → understands the requirements → changes the code → creates a branch → opens a PR and references the issue in the PR description. Everything happens in the terminal.

2. "Why did CI fail?" The Agent reads the latest CI logs by retrieving the build results through MCP → identifies the failing test or compilation error → changes the code → pushes it and reruns CI.

3. "Address the review comments on this PR" The Agent reads the review comments on the PR → handles each one by changing the code or replying → pushes the update.

4. "Publish release notes for the features completed today" The Agent reads merged PRs since the previous release → compiles them into a changelog → publishes a release.

All of these tasks previously required switching to a browser and clicking through the UI. Now they take one prompt. MCP's value is eliminating this context switching.

5. What the Agent should do and what it should not

Before letting the Agent operate GitHub directly by opening PRs, merging, or deleting branches, consider the following:

  • Read operations are safe: reading issues, PRs, CI logs, and code is read-only and carries no risk.
  • Put guardrails around write operations: opening PRs, pushing branches, and replying to comments are reasonable, but irreversible operations such as merging PRs, deleting branches, and changing releases should require human confirmation. Claude Code asks you to confirm write operations by default; do not disable that protection.
  • Narrow the permissions: give the token only the required permissions and limit its repository scope. The impact of an accidental GitHub operation by the Agent is equal to the scope of the token's permissions.

6. Advanced usage: combine it with other MCP servers

GitHub MCP is useful on its own, but it becomes even more powerful when combined with other MCP servers:

  • GitHub + Linear/Jira MCP: synchronize issues and project management tools in both directions.
  • GitHub + Slack MCP: automatically notify a channel when CI fails.
  • GitHub + database MCP: let the Agent query production data to assist with debugging.

MCP's real power lies in combinations. Once your Agent is connected to both GitHub and internal tools, it can complete the full cross-system sequence of "inspect → change → submit → notify."

7. Pitfalls to avoid

  1. Keep token permissions minimal. The Agent's maximum capabilities are equal to the token's maximum permissions.
  2. Be careful with large repositories. Asking the Agent to "inspect the entire repository" may retrieve too much data. Constrain the scope, for example by saying, "Only inspect files under src/."
  3. Rate limits. The GitHub API enforces rate limits, and frequent calls can hit them. An MCP Server usually provides caching or request batching, but keep this in mind when writing your own scripts.
  4. Auditing. If the Agent operates on production repositories, PRs should ideally show which changes were made by AI, using a commit message or label, so reviewers know where to focus.

Summary

Connecting GitHub to Claude Code is one of the most direct and visibly beneficial ways to use MCP:

  • Use the official remote MCP Server, which is sufficient for most people, with the minimum permissions on a fine-grained token.
  • Store the token in an environment variable or global configuration rather than hard-coding it into the repository.
  • Allow read operations and guard write operations, with human confirmation for irreversible actions.

Once configured, your AI coding workflow moves from the fragmented state of "write code in the terminal, manage PRs in the browser" to a one-prompt closed loop in the terminal: read issues, write code, open PRs, inspect CI, and respond to reviews, all in one session. This is what MCP feels like when integration is taken to its logical conclusion: the AI tool is no longer an island, but part of your entire development workflow.

Related

Related Content