※The content of this article is based on what the author confirmed at the time of writing (August 2026).
Since GitHub MCP is an OSS project that is actively updated, please check the latest implementation at the
repository

Lockdown Mode

GitHub MCP Server has a feature called Lockdown Mode, which apparently makes content readable only when the contributor of that content has push access to the repository

https://github.com/github/github-mcp-server/blob/main/docs/server-configuration.md#lockdown-mode

Lockdown Mode
Best for: Public repositories where you want to limit content from users without push access.
Lockdown mode ensures the server only surfaces content in public repositories from users with push access to that repository. Private repositories are unaffected, and collaborators retain full access to their own content.
(Translation: Lockdown Mode
Best use case: Public repositories where you want to restrict content submitted by users without push access.
In Lockdown Mode, the server only displays content in public repositories that was contributed by users who have push access to that repository. Private repositories are unaffected, and collaborators continue to retain full access to their own content.)

Why is this feature needed

Tools like GitHub MCP allow AI to perform operations such as "read an issue" or "read a PR comment" — and there are malicious actors who attempt to extract confidential information through a technique called prompt injection

For example, this type of attack involves opening an issue with embedded instructions for the AI and getting it to execute them

Lockdown Mode serves as a simple countermeasure by preventing the AI from ever seeing "content written by unknown parties"

Let's actually try it

Test [1]

For this test, we use issue #2984 from github/github-mcp-server
The author of this post does not have push access to this repository

Result from directly calling with curl

Lockdown Mode OFF result (issue body is returned as-is):

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{\"number\":2984,\"title\":\"Security: Bearer JWT + JWKS for agent callers ...\",\"body\":\"...(the full body is returned as-is)...\",\"user\":{\"login\":\"Mawyxx\",...},\"author_association\":\"NONE\",...}"
      }
    ]
  }
}

Lockdown Mode ON result (failure):

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "failed to check lockdown mode: failed to get user permission level: GET https://api.github.com/repos/github/github-mcp-server/collaborators/Mawyxx/permission: 403 Resource not accessible by personal access token []"
      }
    ],
    "isError": true
  }
}

It properly fails

Test [2]

Next, we use issue #2981 from github/github-mcp-server
The author of this post should have push access to this repository

Lockdown Mode ON result (failure):

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "failed to check lockdown mode: failed to get user permission level: GET https://api.github.com/repos/github/github-mcp-server/collaborators/ericsciple/permission: 403 Resource not accessible by personal access token []"
      }
    ],
    "isError": true
  }
}

Hmm... I expected it to succeed, but...

Not what I expected

Looking at the error message, it seems that internally it's hitting this endpoint to check whether the contributor has push access, and failing

GET /repos/{owner}/{repo}/collaborators/{username}/permission

My guess is:

1. Need to decide whether to block based on Lockdown Mode
2. Let's check the contributor's push access
3. No permission to check
4. Failure

(This is just speculation though)

The result was that with Lockdown Mode enabled, issues and comments from repositories where you yourself are not a collaborator basically cannot be retrieved

This mode may have been designed with the assumption that the user is a collaborator of the public repository

Summary

• Lockdown Mode is a feature for collaborators (those with push access) of public repositories to protect their own repositories, and is not suitable for use by non-collaborators looking into other repositories
• It is unclear whether this behavior is intentional design, but as a result, access to content is more strictly restricted, which can be said to reduce the risk of prompt injection