Yes, GitHub changed pull request limits for maintainers

Did GitHub change how open source maintainers can limit drive-by pull requests

Yes. GitHub added a repository setting that caps how many open pull requests users without write access can have at once, so maintainers can reduce drive-by noise without banning pull requests outright. GitHub says this is meant for open source repositories that get too many low-quality or repetitive PRs.

The change is newer than GitHub’s older interaction limits. Those older limits were temporary cooldowns for comments, issues, and pull requests. The new pull request limit is persistent and specific to concurrent open PRs, which is the part maintainers were missing when a queue got flooded.

The part people get wrong is assuming GitHub simply added a blanket block on outside contributors. It did not. A user without write access can still open pull requests, but once they hit the cap they must close or merge one before opening another. GitHub also lets maintainers add trusted contributors to a bypass list without giving them full collaborator access.

Draft pull requests do not count toward the limit, so the setting targets submitted work that enters the review queue. GitHub also says pull requests opened by Copilot or another AI agent count toward the limit, which matters in projects where automated or semi-automated contributions can multiply queue volume quickly.

The inconvenient part is that the limit does not solve review burden by itself. It changes who can keep opening new PRs, but it does not review code, decide quality, or stop someone from choosing the wrong repository to target. GitHub frames the feature as a way to lower unnecessary review and CI overhead, not as a replacement for maintainer triage.

If you want a stricter gate, GitHub also added other repository controls around pull request access. Maintainers can restrict pull request creation to collaborators only, or disable pull requests entirely in some repositories. That is a different control from the concurrent limit, and it is the one to use when the project needs a managed contributor set instead of open intake.

The older GitHub guidance about drive-by pull request noise was about preventing low-context or unaffiliated PRs from landing in maintainer queues. The new setting is a direct response to the same problem, but it works by limiting quantity, not by judging intent. That is why it helps with spray-and-pray contribution patterns, while still leaving room for real contributors to participate.

For a maintainer, the practical workflow is simple: set a cap in repository settings, decide whether trusted contributors should bypass it, and keep an eye on whether the queue is still manageable. If your project sees a small number of high-signal PRs, the setting may never matter. If your project gets a constant stream of drive-bys, it can stop one account from filling the queue.

The change answers a narrow question in a useful way. GitHub did change how maintainers can limit drive-by pull requests, and the new control is more precise than the older interaction limits because it caps concurrent open PRs from users without write access. It is a queue-management tool, not a wall.