Access to Private Organization Repositories in GitHub MCP Server
Access to Private Organization Repositories in GitHub MCP Server
Describe the feature or problem you'd like to solve
Currently, GitHub MCP Server lacks the ability to access private repositories that belong to organizations where a user is a member. This is a significant limitation for professional developers who primarily work with company repositories.
A clear and concise description of what the feature or problem is: As professional developers, the majority of our work happens in private repositories owned by our employers or client organizations. Without access to these organization-owned private repositories, GitHub MCP Server's functionality is severely limited for enterprise users and professional developers. We need a way to securely access and work with private repositories within organizations we belong to, just as we can with personal repositories.
Proposed solution
Extend GitHub MCP Server's capabilities to support authentication and access to private repositories owned by organizations where the user has appropriate permissions. This should include:
- Support for organization-scoped tokens or authentication methods
- Ability to browse, and work with private organization repositories
- Respect for organization permission levels (maintaining the same access controls as GitHub.com)
- Integration with existing MCP Server workflows for these repositories
How will it benefit GitHub MCP Server and its users?
This enhancement would dramatically increase MCP Server's utility for professional developers and enterprise users. Most professional development work happens in private organizational repositories, not personal ones. By enabling access to these repositories, MCP Server would become a viable tool for daily professional use rather than just for personal projects.
Benefits include:
- Higher adoption rates among professional developers
- Increased productivity by allowing users to work with their most important repositories
- Better integration into professional workflows
- Enabling enterprise teams to utilize MCP Server's capabilities for their critical work
Additional context
Most professional developers spend 90%+ of their working time on company repositories. Without organization repository access, MCP Server is effectively unavailable for our main development activities. This creates a significant gap between the tool's potential and its current practical utility.
This feature would transform MCP Server from a tool that's primarily useful for personal projects to one that can be integrated into professional development workflows, greatly expanding its relevance and impact in the development community.
@adamklepacz you can already use the server with private repos that belong to orgs. You just need to make sure that:
- Your token has access to them
- You prompt the agent correctly
@juruen
How do I get access to those private repos under my company org? Can you guide me?
I'm generating PAT using my GitHub account. I'm a member of my company organization, but still I don't see the company repos through MCP.
Should I ask company to generate a member PAT token for me instead?
Does your organization use SSO? Sometimes after generating a PAT you also need to give it specific access to restricted orgs.
I also failed fine-grained PAT with full (read-only) permisson.
and it worked after change to classic token.
what should I request my organization? 😅
I did everything with my PAT from my company's organization account but I couldn't use github MCP properly.
I also tried a fine-grained PAT and a classic PAT, gave both all of the permissions, and I still cannot list issues under my private repo under my organization.
github:list_issues (MCP)(owner: "my-org", repo: "myrepo", state: "open")…
⎿ MCP error -32603: Not Found: Resource not found: Not Found
What's interesting is that claude sees that the organization exists, and search_repositories even succeeds in finding my private repo. But list_issues fails with 404.
Error executing code: MCP error -32603: failed to list issues: GET https://api.github.com/repos/my-org/myrepo/issues?state=open: 404 Not Found []
And this query:
{
`q`: `repo:my-org/myrepo is:issue is:open`
}
Error executing code: MCP error -32603: failed to search issues: GET https://api.github.com/search/issues?page=1&per_page=30&q=repo%3Amy-org%2Fmyrepo+is%3Aissue+is%3Aopen: 422 Validation Failed [{Resource:Search Field:q Code:invalid Message:The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them.}]
I also faced this issue with the fine grained token. Our org uses SSO, so I had to switch to the Classic tokens which support enabling SSO.
However, I still faced issues initially with the scopes I enabled in the beginning. Then I realized, it seems we need to check the top level repo checkbox that grants it all the permissions under it. The top level checkbox has this description next to it Full control of private repositories which it seems is only permitted if you check the top level box. If you only enable one of the subsets, there is no private repo support
@adamklepacz I successfully made it work by using a fine-grained personal access token with "Resource Owner" pointing to my company's organization. Tokens (classic) should work as well if allowed by your Organization.
@thiagoscodelerae I tried setting up in both ways Classic tokens / Fine grained PAT and gave all permissions , still facing the same issue .
@saivarsha17 do you know if your organization allows API/Git access through PAT? See settings below:
Also, if you are using docker to run the MCP server, did you restart the server after adding the generated PAT? This is required to get the environment variable GITHUB_PERSONAL_ACCESS_TOKEN correctly:
"args":[
"run",
"-i",
"--rm",
"-e",
"GITHUB_PERSONAL_ACCESS_TOKEN",
"ghcr.io/github/github-mcp-server"
],
I think this is more of a discussion and possible documentation gap, so I have removed the bug label. As @thiagoscodelerae has shared, orgs can have different rules for PATs, and you can selected different permissions when creating them too (which may well block certain actions as intended), and then there are also issues like SSO and other considerations like your individual access level for various repositories, so I think largely this is case of auth working as GitHub intends, and it sometimes causes confusion for end users - but it's not really in the scope of the MCP server to fix, and you would find the same issues calling the API directly with the same tokens.
@thiagoscodelerae Yes , my organization allows access through PAT . And also I'm using node package instead of docker . But still i restarted after updating the token . Still facing the same issue (MPC -32603: Authentication Failed: Bad credentials)
@saivarsha17, where did you find the node package to install? I can try it on my end after that.
FYI, I had all these issues with fine grained tokens. I went back and created a classic token with all read access, added the new token to the mcp config in cursor, restarted cursor and then it worked for me.
When using the OAuth approach, the MCP server can't create repos in my organisation - i'm just about to try with a PAT.
Can confirm I got this working with the following prompt:
List open PRs related to [...] on repo [repo-name] and on private org [org-name]
It added "owner" as a parameter and set it to the [org-name]
Using a classic PAT with most permissions enabled, making sure private repo is authenticated!
What about getting raw files?
my scenario: https://raw.githubusercontent.com/private-org/private-repo/refs/heads/master/docs/a-doc.md?token=<special_token_here>
Even though the MCP server got access to the the repo, it wasn't able to fetch the file contents from it because it lacked the token in the query for the raw files.
What about getting raw files?
my scenario: https://raw.githubusercontent.com/private-org/private-repo/refs/heads/master/docs/a-doc.md?token=<special_token_here>
Even though the MCP server got access to the the repo, it wasn't able to fetch the file contents from it because it lacked the token in the query for the raw files.
Interesting. It doesn't so much lack the token as it is the case that we provide the same auth headers the user is logged in to the MCP server with to the raw URLs, which works for most scenarios, but we might need to investigate if the raw API doesn't support all types of token.
For example it works with both PAT and oauth tokens for the GitHub org itself.
The signed URL approach can work, but it involves making an additional API call each time to get the signed URL, which adds a lot of latency, so might need to decide based on the token type or something.
Thanks for making us aware of this.
Confirming that switching from fine-grained token to a classic token fixed the issue for me (had to give it permissions to be able to private repos)
I've been unable to use fine-grained w/ the MCP server even though my org allows it. I used curl to make test calls to private repos using the token, and it works fine. However, when using the MCP server, I get the Bad credentials error. I am able to access public repos with the MCP server. The error only comes up w/ private repos when using fine-grained PAT (which has been proven to work via curl).
I have also been hitting the case where I can access the private repo using curl but the MCP server fails to access it. I've tried using both fine-grained and classic tokens and I can confirm the organization settings allow members to use PATs to reveal the organization's resources.
For fine-grained, you may need to grant repo:read perms on that repo AND add that user/bot account to the repo
Edit: It seemed not to work with the OAuth approach, but it turned out that VS Code CoPilot tried to access the issue with a normal web request, not using the GitHub MCP server, although it was available. I explicitly told CoPilot to use its tools and then it worked.
This issue is stale because it has been open for 30 days with no activity. Leave a comment to avoid closing this issue in 60 days.
For OAuth, I don't think its attempting to authenticate with the organization if it is required