How to connect VS Code Copilot to GitHub with the official GitHub MCP Server A developer guide shows how to connect GitHub's official MCP Server to Copilot in VS Code, letting the agent read issues, pull request review comments, GitHub Actions failures, security findings and Dependabot alerts directly from chat. Setup uses the hosted remote server at api.githubcopilot.com/mcp/ with OAuth on VS Code 1.101+, and access can be narrowed via a /readonly URL, single-toolset /x/{toolset} paths, or X-MCP-Toolsets and X-MCP-Readonly headers. The guide notes that lockdown mode (X-MCP-Lockdown) is a best-effort filter rather than a security boundary and should be paired with read-only mode and a minimally scoped token. Copilot in VS Code can read the files you have open. Out of the box it cannot read the issue you are fixing, the review comments on your pull request, or the log of the GitHub Actions run that just failed. You end up copying all of that into chat by hand. The GitHub MCP Server https://github.com/github/github-mcp-server is GitHub's official bridge between AI tools and the GitHub platform. Once connected, your agent can browse code across repos you can access, create and update issues and pull requests, look at workflow runs and build failures, and read security findings and Dependabot alerts, all from a chat prompt. GitHub hosts a remote version, so in VS Code there is nothing to install or run. This guide covers the setup, how to limit what the agent can do, and a local option if you want one. The README has an "Install in VS Code" button. Click it and complete the flow, then toggle Agent mode next to the Copilot Chat input and the server starts. VS Code 1.101+ supports OAuth for remote servers, so you can sign in with your GitHub account instead of creating a token. Open or create .vscode/mcp.json in your project and add the hosted server: { "servers": { "github": { "type": "http", "url": "https://api.githubcopilot.com/mcp/" } } } That uses OAuth. If you would rather use a GitHub personal access token, the README's version prompts you for it as a password input instead of hard-coding it in the file: { "servers": { "github": { "type": "http", "url": "https://api.githubcopilot.com/mcp/", "headers": { "Authorization": "Bearer ${input:github mcp pat}" } } }, "inputs": { "type": "promptString", "id": "github mcp pat", "description": "GitHub Personal Access Token", "password": true } } Switch Copilot Chat to Agent mode and ask for things that used to take a tab switch: List the open issues labeled bug in this repo and summarize the three oldest. Read the review comments on my open pull request and fix what they ask for. Why did the last GitHub Actions run on main fail? Show me the failing step. By default the server turns on five toolsets: context , repos , issues , pull requests and users . GitHub's own advice is that enabling only what you need helps the model pick the right tool and keeps the context smaller. Other toolsets include actions , code security , dependabot , discussions , notifications , projects and more. With the remote server you control this through the URL or headers. Read-only. Add /readonly to the URL and the agent gets only read tools. A good default while you build trust: { "type": "http", "url": "https://api.githubcopilot.com/mcp/readonly" } One toolset. Use /x/{toolset} , for example issues only, read-only: { "type": "http", "url": "https://api.githubcopilot.com/mcp/x/issues/readonly" } Several toolsets. The path takes one toolset at a time, so for a mix use the X-MCP-Toolsets header: { "type": "http", "url": "https://api.githubcopilot.com/mcp/", "headers": { "X-MCP-Toolsets": "repos,issues,actions", "X-MCP-Readonly": "true" } } /x/all turns on everything, and /insiders or the X-MCP-Insiders header opts you into experimental tools early. If your agent reads issues and pull requests on a public repo, anyone can write text it will see. The server has a lockdown mode that hides content from authors without push access. Turn it on with the X-MCP-Lockdown: true header. GitHub is clear that this is a best-effort filter, not a security boundary: it does not change what your token can read or write. Pair it with read-only mode and a token scoped to the minimum. You can run the server in Docker instead. On github.com the one-click Docker buttons log you in with OAuth on first use. With a personal access token, the README's Docker form is: docker run -i --rm \ -e GITHUB PERSONAL ACCESS TOKEN=