Describe the feature or problem you'd like to solve
Several repository write tools currently declare scopes.Repo, so the OAuth scope filter hides them when the server is authenticated with a token limited to public_repo.
That forces an OAuth deployment which only needs to contribute to public repositories to request the broader repo scope, which also grants private-repository access.
The affected tools I have exercised successfully against public repositories with a public_repo token are:
add_issue_commentissue_writecreate_branchpush_filescreate_pull_requestfork_repository
The existing scope hierarchy already models repo as a parent of public_repo, so declaring scopes.PublicRepo for these tools would still accept a full repo token while also allowing least-privilege public-only OAuth deployments.
Proposed solution
Change the required scope for those six tools from scopes.Repo to scopes.PublicRepo and add focused tests asserting that each tool advertises:
- required scope:
public_repo
- accepted scopes:
public_repo, repo
No API handler or authorization bypass is needed; GitHub continues to enforce the token's actual repository permissions.
Example workflow
A public-only MCP deployment can request only public_repo, fork an open-source repository, create a branch, push a patch, open a pull request, and participate in issue discussion without gaining access to private repositories.
I have a small patch and regression coverage ready if this direction looks suitable.
Describe the feature or problem you'd like to solve
Several repository write tools currently declare
scopes.Repo, so the OAuth scope filter hides them when the server is authenticated with a token limited topublic_repo.That forces an OAuth deployment which only needs to contribute to public repositories to request the broader
reposcope, which also grants private-repository access.The affected tools I have exercised successfully against public repositories with a
public_repotoken are:add_issue_commentissue_writecreate_branchpush_filescreate_pull_requestfork_repositoryThe existing scope hierarchy already models
repoas a parent ofpublic_repo, so declaringscopes.PublicRepofor these tools would still accept a fullrepotoken while also allowing least-privilege public-only OAuth deployments.Proposed solution
Change the required scope for those six tools from
scopes.Repotoscopes.PublicRepoand add focused tests asserting that each tool advertises:public_repopublic_repo,repoNo API handler or authorization bypass is needed; GitHub continues to enforce the token's actual repository permissions.
Example workflow
A public-only MCP deployment can request only
public_repo, fork an open-source repository, create a branch, push a patch, open a pull request, and participate in issue discussion without gaining access to private repositories.I have a small patch and regression coverage ready if this direction looks suitable.