GitHub MCP Remote OAuth Setup: Start Read-Only Without Docker or a PAT
Use GitHub’s hosted remote MCP server first: point an OAuth-capable MCP client at https://api.githubcopilot.com/mcp/, approve only the access you need, and start in read-only mode with the smallest toolsets. If the host cannot complete GitHub OAuth, use the local official server’s OAuth flow or a fine-grained PAT instead.

Use GitHub’s hosted remote MCP server first: point an OAuth-capable MCP client at https://api.githubcopilot.com/mcp/, approve only the access you need, and start in read-only mode with the smallest toolsets. If the host cannot complete GitHub OAuth, use the local official server’s OAuth flow or a fine-grained PAT instead.
Table of contents
- Which GitHub MCP path should you choose?
- How do you connect the remote OAuth server?
- How do you make GitHub MCP read-only and repository-scoped?
- How do you verify the connection without changing a repository?
- When should you use local OAuth or a PAT instead?
- How do you fix missing tools, login loops, and blocked organizations?
- FAQ
Which GitHub MCP path should you choose?
Use the hosted remote server when your MCP host can complete GitHub OAuth. Use local OAuth or a PAT only when the host cannot complete that remote authorization flow.
The official remote endpoint is:
https://api.githubcopilot.com/mcp/
Remote OAuth depends on the MCP host having a GitHub OAuth App integration. A remote host may alternatively accept a PAT, but the endpoint alone does not create an OAuth integration. See the official remote-server guide before choosing a connection method.
| Situation | Recommended path | Starting posture |
|---|---|---|
| Host supports GitHub OAuth | Hosted remote server | Read-only and minimal toolsets |
| Host cannot complete remote OAuth on github.com | Local official binary or container | Local OAuth without a PAT |
| Host explicitly accepts a token | Remote or local configuration | Fine-grained PAT with limited access |
| GitHub Enterprise Server | Compatible non-hosted setup | Do not use the hosted endpoint |
MCP separates the host, client, and server roles, so the client’s authorization capabilities affect which server path works. The MCP architecture overview explains that relationship.
For the practical server entry, start with MCPtrove’s GitHub MCP Server directory page, then match it to the client you actually use.
How do you connect the remote OAuth server?
Add https://api.githubcopilot.com/mcp/ to an MCP client that provides a GitHub OAuth App integration, start its authorization flow, and return to the client after GitHub completes sign-in.
Use this sequence:
- Open the MCP client’s server or connector settings.
- Add the official remote endpoint exactly as shown above.
- Select the client’s GitHub OAuth integration if it offers one.
- Complete the GitHub authorization flow in the browser.
- Return to the client and confirm that the server is connected.
The authorization step is handled between the MCP host, the client, and the authorization server; it is not replaced by merely pasting the endpoint into a text field. The MCP authorization specification describes the protocol-level flow.
If the client does not offer a GitHub OAuth integration, use its documented PAT option only if it explicitly supports one, or switch to the local official server. Do not paste a PAT into an OAuth field. Users of Claude can begin from the Claude client page and then apply the same endpoint and access principles.

How do you make GitHub MCP read-only and repository-scoped?
Enable read-only mode, select only the toolsets needed for your task, and restrict authorization to the repositories you intend to inspect when the client or GitHub authorization flow provides that choice.
Use these settings as a baseline:
- Turn on the server’s read-only mode.
- Select the smallest read-oriented toolsets that answer your question.
- Choose only the repositories required for the task when repository selection is available.
- Leave write-oriented tools disabled until a specific task requires them.
- Recheck the selected repositories before completing authorization.
Read-only mode and repository scope address different concerns. Read-only mode limits the kind of action the server may perform; repository scope limits which repository data should be available. Keep both narrow rather than treating one as a substitute for the other.
GitHub supports toolset selection and a read-only mode in the official server. Exact labels and placement depend on the MCP client. The official GitHub MCP Server documentation is the source of truth for the server’s supported configuration.
How do you verify the connection without changing a repository?
Verify authentication with a harmless read against a repository you expect to access, then confirm that no write-oriented tools are enabled. Do not create, edit, merge, close, or delete anything during the initial check.
A practical verification sequence is:
- Confirm that the client reports the remote server as connected.
- Run a read-only request for repository metadata or another read operation.
- Check that the returned repository is the one you authorized.
- Confirm that the response contains data rather than an authorization or organization-policy error.
- Inspect the enabled toolsets and keep write capabilities disabled.
This check tests the complete path: client integration, OAuth authorization, server connectivity, and repository access. It also keeps the first request within the least-privilege posture recommended by the MCP security best practices.
If the client exposes configuration diagnostics, MCPtrove’s Config Doctor can be a practical next step. For a broader explanation of permissions and authorization boundaries, see MCP security: what actually matters.
When should you use local OAuth or a PAT instead?
Use local OAuth or a PAT when your MCP host cannot complete the hosted server’s GitHub OAuth integration. For github.com, the official local binary and container can now start an OAuth login without a PAT, keeping tokens in memory for that process.
Choose local OAuth when:
- The client has no GitHub OAuth App integration.
- The remote authorization callback cannot complete in your host.
- You need the official local binary or container path for github.com.
- You want the credential lifecycle tied to one local process.
Choose a fine-grained PAT when the host explicitly supports PAT authentication and a token is the workable credential for that setup. Keep its access limited to the repositories and operations required, and do not place it in prompts, logs, screenshots, or committed configuration.
The official local OAuth login guide covers the local flow. GitHub Enterprise Server does not use the hosted remote endpoint, so select a compatible local or enterprise-specific path instead of sending an Enterprise Server account through the hosted URL.
How do you fix missing tools, login loops, and blocked organizations?
Match the symptom to the connection layer: toolset settings cause missing tools, OAuth integration or callback problems cause login loops, and organization policy can block otherwise valid account access.
| Symptom | Likely issue | What to check |
|---|---|---|
| No GitHub OAuth option | Host lacks the required integration | Use local OAuth or a supported PAT path |
| Browser login repeats | Authorization did not return to the client | Restart the client’s OAuth flow and confirm the same client handles the callback |
| Expected tools are absent | Toolsets or read-only settings are narrow | Review enabled toolsets without broadly adding write access |
| Repository is inaccessible | Repository scope or account authorization is limited | Recheck selected repositories and the authorized GitHub account |
| Organization access is blocked | Organization policy requires approval | Resolve the organization’s approval or access requirement with its administrator |
Do not broaden permissions blindly to solve an error. First identify whether the failure is in the host integration, OAuth flow, toolset selection, repository scope, or organization policy. If the host cannot provide GitHub OAuth, move to local OAuth or a fine-grained PAT rather than repeatedly retrying the same remote setup.