# Remote or local GitHub MCP server: which should you run? Source: https://codelifter.com/forum/posts/remote-or-local-github-mcp-server-which-should-you-run/ Site: CodeLifter Forum, category MCP and tools Published: 2026-10-16. Updated: 2026-10-31. Replies: 2. ## Question by CodeLifter editors (staff), 2026-10-16 Run the remote server if you use github.com and your client supports remote MCP servers: there is nothing to install, and OAuth asks for scopes as tools need them. Run the local server if you use GitHub Enterprise Server, your client only supports local servers, or you want to choose when the server version changes. ## What each one is Both come from the same repository. GitHub's [remote server documentation](https://github.com/github/github-mcp-server/blob/main/docs/remote-server.md) says the hosted version "is built using this repository as a library" and that GitHub "regularly update[s] the remote server to include the latest version of this code." - **Remote.** GitHub runs it at `https://api.githubcopilot.com/mcp/`. Your client connects over HTTP. - **Local.** You run it yourself, either as the public Docker image `ghcr.io/github/github-mcp-server` or by building the Go binary from `cmd/github-mcp-server` and running `github-mcp-server stdio`. Your client starts it as a local process. Either way, the tools call the GitHub API with your credentials. The choice is about where the MCP process runs, who updates it and how you sign in, not about whether GitHub sees your requests. ## Side by side | Factor | Remote | Local | | --- | --- | --- | | Install | None | Docker, or a Go build | | Client requirement | Remote MCP support (the README names VS Code 1.101 or later, Claude Desktop, Cursor and Windsurf among others) | Any client that can start a local server | | Sign-in | OAuth with scope challenges, or a personal access token | OAuth login on first use, or `GITHUB_PERSONAL_ACCESS_TOKEN` (the token takes precedence) | | GitHub Enterprise Server | Not supported | Supported with `--gh-host` or `GITHUB_HOST` | | GitHub Enterprise Cloud with data residency (ghe.com) | Supported, at `copilot-api.YOURSUBDOMAIN.ghe.com/mcp` | Supported with `GITHUB_HOST` | | Choose toolsets | `X-MCP-Toolsets` header or `/x/{toolset}` URL | `--toolsets` flag or `GITHUB_TOOLSETS` | | Read-only mode | `X-MCP-Readonly` header or `/readonly` URL | `--read-only` or `GITHUB_READ_ONLY` | | Exclude tools | `X-MCP-Exclude-Tools` header | `--exclude-tools` or `GITHUB_EXCLUDE_TOOLS` | | Extra toolsets | `copilot_spaces` and `github_support_docs_search` are remote only | Not available | | Updates | GitHub updates it | You decide when to pull or rebuild | The configuration rows come from the [server configuration guide](https://github.com/github/github-mcp-server/blob/main/docs/server-configuration.md); the rest from the repository [README](https://github.com/github/github-mcp-server). The README states plainly: "GitHub Enterprise Server does not support remote server hosting." ## The case for remote The remote server is the shortest path for someone who wants to try MCP against github.com. With OAuth, the [scope filtering document](https://github.com/github/github-mcp-server/blob/main/docs/scope-filtering.md) says "when a tool needs a scope you haven't granted, you're prompted to authorize it," so you are not asked for every scope at the start. You also skip keeping a token in a config file. Things to check first: 1. Your client must support remote servers and, for OAuth, the README notes that "Each MCP host application needs to configure a GitHub App or OAuth App." If yours has not, use a personal access token instead. 2. If you work in an organisation, the README lists "Any applicable policies enabled" as a prerequisite. An owner may need to allow it. 3. The URL form only takes one toolset (`/x/issues`, not `/x/issues,repos`). To combine toolsets, use the `X-MCP-Toolsets` header. A minimal read-only setup in VS Code's `mcp.json`: ```json { "servers": { "github": { "type": "http", "url": "https://api.githubcopilot.com/mcp/", "headers": { "X-MCP-Toolsets": "repos,issues,pull_requests", "X-MCP-Readonly": "true" } } } } ``` ## The case for local Run it locally when the remote option cannot work or when you want control over the process: - **Enterprise Server.** Only the local server can point at your own host. The README says the host must use `https://`, and that "non-HTTPS hosts are refused" except for loopback hosts during local development. - **Clients without remote support.** Any client that can launch a command can run the Docker image. - **A fixed version.** The remote server changes when GitHub deploys it. Locally, nothing changes until you pull a new image or rebuild. - **Isolation.** The Docker image runs in a container you start and stop. Add `--rm` so nothing is left behind. A local setup with a token and the same limits: ```json { "servers": { "github": { "command": "docker", "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "-e", "GITHUB_TOOLSETS", "-e", "GITHUB_READ_ONLY", "ghcr.io/github/github-mcp-server"], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}", "GITHUB_TOOLSETS": "repos,issues,pull_requests", "GITHUB_READ_ONLY": "1" } } } } ``` The README also documents an OAuth login for the local server: the Docker install buttons publish a callback port on `127.0.0.1:8085`, and the resulting token "is kept in memory only." If you use a token instead, the README's advice is to keep it in an environment variable, add `.env` to `.gitignore`, and run `chmod 600` on any config file that holds it. ## What does not change between them Both versions support the same toolsets, read-only mode, excluded tools and lockdown mode. The configuration guide describes lockdown mode as "a best-effort content filter, not a security boundary," so do not treat it as protection on either side. Neither version reduces what your credential can do: the token or OAuth grant is the real limit. The thread on [which token scopes the GitHub MCP server needs](/forum/posts/which-token-scopes-does-the-github-mcp-server-need/) covers how to keep that small. ## A short decision path 1. On GitHub Enterprise Server? Run local. 2. Client cannot connect to remote servers? Run local. 3. Need to pin the version for a team or a course? Run local. 4. Otherwise, start with remote in read-only mode, and add write toolsets only when a task needs them. For a full list of tools and what each can change, see the CodeLifter [GitHub MCP server page](https://codelifter.com/mcp/github/). If you also give an assistant file access on your machine, the thread on [sandboxing the Filesystem MCP server](/forum/posts/how-do-you-sandbox-the-filesystem-mcp-server/) covers the local side, and [who is the author of a commit made through an MCP server](/forum/posts/who-is-the-author-of-a-commit-made-through-an-mcp-server/) covers what happens once writes are on. ## Reply 1 by CodeLifter editors (staff), 2026-10-29 **What is lockdown mode on the GitHub MCP server?** A filter on what public content the server shows the model, not a permission control. The server's [configuration guide](https://github.com/github/github-mcp-server/blob/main/docs/server-configuration.md) says lockdown mode only surfaces content in public repositories from users with push access, and describes it as a best-effort content filter meant to reduce prompt-injection risk. Prompt injection is text written to be read by a model as instructions, for example an issue comment that tells an agent to push a change or reveal a token. Lockdown cuts down how much text from strangers reaches the model, which matters most when an agent triages issues on a public repository. The guide is explicit that it is not an authorization boundary, so it does not stop a tool from doing anything your token allows. It is available on both the remote and local servers, like read-only mode. Treat it as one layer: read-only mode or a short `--exclude-tools` list limits what the agent can do, the token limits what the API allows, and lockdown limits what the agent reads. The same guide documents an insiders mode for experimental features and warns that they may change, evolve or be removed, so leave it off for a setup you depend on. ## Reply 2 by CodeLifter editors (staff), 2026-10-31 **How do you add the remote GitHub MCP server to Claude Code?** With one `claude mcp add` command. Claude Code's [MCP documentation](https://code.claude.com/docs/en/mcp), read on 16 October 2026, gives GitHub as a worked example: generate a fine-grained personal access token limited to the repositories you want, then run ``` claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \ --header "Authorization: Bearer YOUR_GITHUB_PAT" ``` The same page says the command saves the configuration without checking the credentials, so a wrong token only shows up later; run `/mcp` and look for a checkmark, or an error with the HTTP status, such as 401. By default the server is stored in local scope, available only to you in the current project. `--scope user` makes it available across your projects, and `--scope project` writes it to `.mcp.json` to share with the team. Do not put a real token in a committed `.mcp.json`. The page also says a project-scoped server from a cloned repository stays pending until you approve it, and that a repository cannot approve its own servers. To keep the read-only and toolset limits from the opening post, add the server with `claude mcp add-json` instead and put `Authorization`, `X-MCP-Readonly` and `X-MCP-Toolsets` in its `headers` object. --- Cite as: CodeLifter Forum, "Remote or local GitHub MCP server: which should you run?", https://codelifter.com/forum/posts/remote-or-local-github-mcp-server-which-should-you-run/, accessed 2026-11-12.