every CI provider has this problem as well -- using a CI provider on any repo requires giving them access to everything. specifically bad problem for people who are in multiple organizations or who have a mix of public + private repos

circleci has a docs page about it:

Note: CircleCI only asks for permissions that are absolutely necessary. However, CircleCI is constrained by the specific permissions each VCS provider chooses to supply. For example, getting a list of all user’s repos – public and private – from GitHub requires the repo scope, which is write-level access. GitHub does not provide a read-only permission for listing all a user’s repositories.

more granular scope would make it safer to use all kinds of codebase plugins

another approach would be to create a 'scoped subset' of my account that has access only to certain repos or organizations -- then the plugin vendor wouldn't have to worry about permissions

at the moment, is the best practice to create a whole new github account?

@github-staff this discussion + a good amount of StackOverflow posts reference this issue all the way back to 2015-2016. Can you at least give a corporate-friendly answer to why more read-only scopes are not a thing yet?

Just repeating what everyone thinks about not having them:

• unnecessary security risks
• unnecessary liabilities for 3rd parties that use the API
• inhibits growth of 3rd parties that need only a subset the repos scope. Say I make an app that publishes statistics about the number of PRs opened by each user in an org. Every org that installs the app would be suspicious about giving it access to THEIR WHOLE CODEBASE.

@github 🆘 🆘 🆘

Please let us know if you plan to fix this crucial issue for App Developers!

This limits the use of applications in Github significantly because clients don't want to install apps due to excessive scope! Please give us the ability to request read-only repos in OAuth App Scopes.

@github

Please help

It's crazy how GitHub OAuth still lacks a read-only scope for repos, despite an open issue since 2015. Hopefully, GitHub will prioritize this feature soon, as the fine-grained personal access tokens don't fit all the use cases.

Damn, same problem here, I wasn't expecting this much messages but it reassure me about the fact that I'm in need of this feature (just a simple repo:read would be nice)

My company is ok for using a really helpful tool but the scopes necessary to read repositories are too high at the moment and it makes no sense

Hey everyone,

So I encountered that problem a few minutes ago as well, but I managed to find a solution!

• PATs require too much efforts from non-power users, and unlike GH App, OAuth apps don't let you configure the access from GitHub directy
• however, your request for authentication to your OAuth app can include scopes: cf. API documentation

Note: Your OAuth app can request the scopes in the initial redirection. You can specify multiple scopes by separating them with a space using %20:

https://github.com/login/oauth/authorize?
  client_id=...&
  scope=user%20repo_deployment

I just used that and it worked! The number of available scopes is limited but it's a start

Hope this helps ✌️

From what I have read this discussion has been going on for some time, so not going to hold my breath.

But as many others have mentioned, it would be prudent from a security perspective to be able to limit access to read only on private repos for example.

It seems a bit heavy handed to grant read/write/all access to apps that just want to read data.

Anyone found an explanation as to why this is not and will not be implemented?

There appears to be an option exactly like this for projects:

project - Grants read/write access to user and organization projects.
read:project - Grants read only access to user and organization projects.

Scopes for OAuth apps

Why can't an OAuth login request read-only access to a specific repo, as well? Why does it have to be all private repos?

With the official GitHub MCP server now available, AI tools need secure, least-privilege access to both public and private repos. Today most clients fall back to long-lived PATs—cumbersome to rotate and prone to over-permission. By adopting OAuth 2.1 (PKCE, no implicit flow, fine-grained scopes) in MCP servers—and exposing a read-only scope for cloning/status checks—AI agents could obtain short-lived, read-only tokens via standard flows (see draft: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1). Managed providers like Composio’s MCP server already support OAuth out-of-the-box, handling token refresh and security best practices. Exposing a read-only OAuth scope will streamline credential management and enforce least-privilege for AI-driven workflows.
See discussion: modelcontextprotocol/modelcontextprotocol#205 (comment)

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐