New release: new repository settings to configure pull request access

[moraesc]

Today, we’re introducing two new repository settings that give maintainers greater control over how their projects accept contributions: the ability to disable pull requests entirely, and the option to restrict pull requests to collaborators only.

Open Source is not One-Size-Fits-All

Maintainers are at the heart of GitHub’s ecosystem. You shape your communities, your project’s scope and technical direction, and define what processes contributors should follow. For years, we’ve operated on a default assumption that if a repository is public, it should accept pull requests from anyone. But that’s not how all projects work. Some projects want to share code without managing contributions. Others need to restrict collaboration during critical development phases. Many repositories, like mirrors or read-only reference implementations, simply have no need for pull requests at all.

More granular pull request permissions have been one of our most consistently requested features, and that need has become more urgent as the nature of contributions has evolved. We're committed to supporting maintainers and open source projects of all types, and we're excited to deliver these foundational tools to the community.

What’s New

1. Disable pull requests entirely

Just like you can with issues, wikis, projects, and discussions, maintainers can now turn off pull requests completely from your repository's Settings.

When disabled, the pull requests tab will be not be visible. This means no one can see existing pull requests or open new ones.

2. Restrict Pull Requests to Collaborators

When enabled, the pull requests tab remains visible. All pull requests can be seen, but only collaborators (users with write access) can create new ones. Collaborators can be added or removed by going to the Collaborators tab in a repository’s Settings.

What’s Next

As the open source landscape evolves, we’re committed to evolving our tools to ensure that the important work of open source maintainers remains enjoyable and sustainable. To learn more about some of the ideas we’re exploring, check out our latest blog post.

For teams that need highly customized contribution policies today, Agentic Workflows, a research project from GitHub Next, are designed to enforce virtually any project-specific rules you define. While this approach requires more technical setup and comes with usage costs, it provides significant flexibility. You can explore example workflows here.

Your Feedback Shapes our Roadmap

We’re extremely grateful for the feedback we’ve received from the community. The discussion threads, feature requests, and conversations with maintainers have been instrumental in helping us understand what to build and why it matters.

Now, we’d love to hear how these settings work for your project in practice, what challenges remain, and what additional controls would make managing pull requests easier. Your input will inform our next steps and ensure we’re building the right tools to address your needs.

Thank you so much for your collaboration and helping us improve the open source community on GitHub.

[Wayne-Jones]

The fact that this new feature on GitHub is so anti-OSS that there isn't enough words to explain how backwards this is. Let's be honest, this feature only rolled out because maintainers (whose job is to triage PRs and Issues) can't and don't want to deal with their responsibilities with maintaining their repo. While we do live in a world with AI Agents, I think this feature steps over the line and takes it a bit too far. As it not only gatekeeps new members from contributing to Open Source Software, but it further perpetuates an already gatekept culture of software development. I would call on GitHub to find a middle ground of detecting when an AI Agent creates a PR and allow Repo Owners to block that instead of a broad global block.

[grahamperrin]

… Let's be honest, …

If honesty is truly what's wanted: I'm extremely disappointed that the first comment here seems to be an ill-informed complaint.

The information below might help to paint a picture, for people who are not aware of the gamut of opinions over the past decade:

• Add feature to disable pull requests on a repository dear-github/dear-github#84 (January 2016)
• Request: Ability to turn off Pull Requests · community · Discussion #8907 (December 2021)
• Exploring Solutions to Tackle Low-Quality Contributions on GitHub · community · Discussion #185387 (January 2026)

[Wayne-Jones]

It seems obvious we have 2 different definitions of the word "job", meaning task or responsibility of work, and "gatekeep" meaning acting as a filter for what is and isn't allowed.

For the sake of ending this conversation, we can agree to disagree without implying that people are self entitled to someone's software. All I stated was that this feature would further gatekeep future contributors who want to contribute to the original repo. Not a fork.

You and the folks on this thread would probably retort with, if you can't contribute to the original repo because of being gatekept, why not just make a fork and do it their own way? But that's not the point I'm trying to make and proves once again why the open source community isn't so truly open.

That's all I have to say about this matter.

[yawaramin]

This feature is just a tool. It does nothing by itself. The choice to accept outside contributions or not has always been the decision of a project's maintainers.

I understand the point that you are trying to make. You are misunderstanding what open source maintainers 'owe' you from their projects. They don't 'owe' you having to accept your PRs. Again, this feature is just a tool that helps maintainers who already wouldn't have accepted PRs. It does not force any projects to stop accepting PRs.

If you don't like the implication that you are acting entitled to someone else's work then don't make accusations that the community is not 'truly open' just because a project won't accept PRs.

[Wayne-Jones]

If you don't like the implication that you are acting entitled to someone else's work then don't make accusations that the community is not 'truly open' just because a project won't accept PRs.

Ok you clearly don't get it and you never will 😄

[jayaddison]

@Wayne-Jones I haven't managed to stay on-board as a maintainer in many open source projects for a long duration of time, despite sometimes being granted those privileges, because I begin stressing a lot about whether contributions are genuine -- and, conversely, whether I'm being unfair to what I think is an AI contributor, when actually it's a human -- whether there might be important bugs that I didn't notice (regardless of human/AI), and so on. Partly I also have problems believing that I am welcome in any particular community.. but neither of those is the only factor involved.

People are free to copy, run, learn from and adapt open source software -- but that doesn't mean that the authors/maintainers have any duty to read and accept any mixture of inbound problems or suggestions in return; maybe they had a bad time with some of those and want to pause until they unpick that, or they'd prefer simply to continue on developing it on their own. I think that's OK, and that these changes help make those options possible.

[story645]

Restrict Pull Requests to Collaborators

Are there any plans to roll out a modified version of this? Been thinking something like an allow list would be helpful - not just collaborators but anyone who's commented in the issue such that we have some confidence that their PR isn't (going to be) spam. I guess I'm asking for a modification of the "allow folks assigned to issues" request, but this would give space for prs not attached to issues/folks we know through other comms channels.

[xunchahaha]

+1

[moraesc]

@story645 yes! we're looking into releasing some additional settings so maintainer have more granularity over who can make contributions

[0xMF]

Giving me the choice to disable completely any setting I did not want was always on my wishlist. I knew I could disable Issues and Wikis. I never thought GitHub would let me disable PRs. Yet the unthinkable happened. Now my wishlist is complete. Thank you!

[moraesc]

Very glad to hear that @0xMF !

[SpriteOvO]

I would like to see a setting to disable Copilot globally on GitHub.

[jayaddison]

It seems like a vuvuzela problem.

To explain: people want to participate in the action (supporting their sports teams, or contributing to open source projects). To be more likely to be heard/involved, they'll accept or bring ways to amplify their voice (the vuvuzela, or a generative AI code agent).

Some brands with plenty of funds are willing to provide free amplifying support at a loss, because they want their vuvuzela to be the one that is most audible during the sport/broadcast (or an AI agent in commit logs, or comments). Unfortunately, too many free vuvuzelas in the stadium cases an incredibly unpleasant experience for everyone.

The analogy to the repository settings here is that some stadiums can choose not to allow people in to observe the game at all -- without altering the policy on vuvuzela usage within the stadium.

I think a more practical solution is generally to disallow vuvuzelas. The sports teams (the project maintainers and developers) shouldn't have to be the ones enforcing that, it should stadium policy (repository settings). However, the stadiums here aren't independent - they all have to work within the policy options provided by the governing body (GitHub).

[jayaddison]

In the case where would-be contributors are restricted by these settings, I'd anticipate that they will be able to continue to create forks of the source repositories on GitHub and to work on features in their own branches -- it's only the pull request step in the source repo that these settings adjust.

I'll need to think about this more (and I imagine GitHub staff has already discussed this), but I'd hope that additional ways to discover and surface useful contributions (and contributors!) from the network/forks of repos might emerge in future (I'd imagine this is something that advanced projects/maintainers may already look for).

[moraesc]

@jayaddison confirming users will still be able to create forks of repositories even if PRs are disabled in that repository.

I'll need to think about this more (and I imagine GitHub staff has already discussed this), but I'd hope that additional ways to discover and surface useful contributions (and contributors!) from the network/forks of repos might emerge in future (I'd imagine this is something that advanced projects/maintainers may already look for).

We're looking into a bunch of different approaches that we could implement down the line. Please share any thoughts that come to mind!

[pierotofy]

Excellent! Thank you.

Can we please now also add the ability to limit the opening of new issues to collaborators only? It would really help cut down on AI slop burnout. I know I can disable issues entirely, but projects still need to track issues. People should still be able to see issues, but just not participate.

[ufukty]

This. Restricting Issues section to insiders makes sense for many reasons. For example OSS users are better served in the Discussions section. Thread structure prevents unnecessary notifications and important information getting buried inside "Show more" pit. Posts are isolated from the issue tagging system and milestones, which is great to prevent missing direction in product management.

• Feature request: Role-based Issues section access control #191479

[br3ndonland]

@moraesc how does "Restrict Pull Requests to Collaborators" relate to bots like Dependabot? Do we have to invite Dependabot to be a collaborator on those repos?

[moraesc]

@br3ndonland Dependabot can still create PRs if PRs are restricted to collaborators only. It's technically considered a collaborator since it has write access to the repo

[beutlich]

Any chance to add has_pulls to the repository endpoints? Thanks!

[moraesc]

@beutlich , it should be available on the repository endpoint under has_pull_requests

[beutlich]

Neither the sample response nor the documentation mention it at https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#get-a-repository

[psybers]

Neither the sample response nor the documentation mention it at https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#get-a-repository

First, the link you gave is to the older API. The latest version is here: https://docs.github.com/en/rest/repos/repos?apiVersion=2026-03-10

Second, while it is not documented in the latest version, I can verify that it does seem to be live. I tested turning the feature off and back on via a PATCH to one of my repos. Probably the docs will update with the next apiVersion. Or it was just missed in the docs.

[mynameistechno]

@psybers thanks for the tip! I see it in the API even though it's not documented eg

"has_pull_requests": true, "pull_request_creation_policy": "collaborators_only",

[smockle]

https://docs.github.com/en/rest/repos/repos?apiVersion=2026-03-10#get-a-repository and https://docs.github.com/en/rest/repos/repos?apiVersion=2026-03-10#update-a-repository now document has_pull_requests and pull_request_creation_policy, under “Response schema” and “Body parameters”, respectively. Thanks for pointing out the omissions, @beutlich, @psybers, and @mynameistechno!

[ViliusS]

@moraesc how this affects private repositorie? I see that the default is to "Allow all users". Does this mean that anyone having read access to private repository will now be able to create PRs? If I remember correctly, previously only people with write access to private repository were able to create PRs.

[ViliusS]

@moraesc I understand how to configure new setting. My question was regarding the previous and new default. Are you implying the default behaviour on old private repositories didn't change with the introduction of this new setting? Or should we go through all the repos now and set them to "Collaborators only"?

[moraesc]

@ViliusS Ah i see. Confirmed the default did not change on old private repositories. They should all behave as they were previously.

[helen]

@ViliusS To be specific, you cannot fork a private repository and pull requests must be opened from a branch, so a read-only user cannot create a PR because they cannot create a branch in a private repo.

[rmacklin]

You can fork private repositories, unless forking is explicitly disabled in the repository settings:

or organization settings:

[helen]

Ah yes that's right, I forgot that's a difference between org types but it's also only within the organization. In any case, behavior has not changed for the original defaults or for existing repositories as they were before this addition :)

[JoshuaMaitland]

Thank you for implemented that Pull Request toggle on the repository settings. That even helps me (and other people) to disable Pull Requests when there are certain projects like their "own" personal README profile are not really needed!! I've been waiting on that setting for ages now.

[penguinscript]

It's a much needed change. The amount of crypto promoting or generic scam GitHub pull requests and issues being raised and then tagging everyone in, is getting out of control.

Glad that at least some steps are being taken to provide repo owners with more control to stop that from happening.

[clason]

Sorry for necro-posting this, but we are just now trying out this feature in https://github.com/tree-sitter/tree-sitter, which suffers from constant bot (and low-quality PR) spam, and ran into one serious issue with this (very welcome) feature: The announcement and wording on the help page talk about restricting creation to collaborators -- which is standard terminology for anyone that has been added to a project directly regardless of the role (if it's not maintainer or higher); it even shows up as a badge next to their comments.

However, in fact what is required is write role -- which is a much higher bar, and not a role I would feel comfortable giving to someone I just want to be able to open PRs (while still keeping out bots and their proxies).

So my request (in order of urgency) would be to

1. Make sure all documentation of this feature (changelog and help pages and especially text on the settings themselves) is unambiguous about what is required to bypass restrictions.
2. Add additional roles to the drop-down so projects can allow PR creation for people with triage or even read role (which then becomes a managed "collaborator" role, which I believe is what many open source projects want).

[alasdairwilson]

I wanted to say that this makes a lot of sense for my use cases too, presumably instead of the bar being set at write (therefore capturing write, maintain and admin) it could be configurable to read - which would still allow a trusted set of collaborators to submit PRs via their forks without giving them write access to the core repo.

[mynameistechno]

I agree with overall sentiment here, what I really want is to allow any of our org members to open PRs (membership is already tightly controlled). This is also lacking from the new GItHub Actions policy settings.