News

New GitHub Switch Limits Repo Issue Creation to Collaborators Only

• By David Ramel
• 06/30/2026

Apparently encouraged by the maintainer response to recent pull request controls, GitHub is taking another step in the same direction: letting repository admins restrict issue creation to collaborators only.

The new setting, announced in a GitHub Changelog post and a related GitHub Community discussion, lets repository admins limit issue creation to users with write access. When enabled, people without write access cannot create issues from entry points across the repository experience, including Issues, Comments, Discussions, Projects and Copilot.

That makes the issue tracker the latest part of GitHub's open source workflow to get a maintainer-side intake control. In February, GitHub added new repository settings for pull request access, allowing maintainers to disable pull requests entirely or restrict pull request creation to collaborators. In June, it added a way to limit open pull requests from users without write access.

GitHub then defended the June PR limits in a maintainer-focused blog post, "How pull request limits are cutting down the noise." The company said maintainers were facing "too many incoming pull requests, too much low-quality noise, and too few ways to manage the flow." It also quoted maintainers who said the new caps were helping them keep review queues usable.

Now GitHub is extending that same reasoning from pull requests to issues. The result is not just another repository setting, but another sign that GitHub is rebalancing open source participation around maintainer capacity, contribution quality and AI-amplified volume.

From Pull Request Limits to Issue Limits
GitHub's core argument is that creating work for maintainers has become much easier than reviewing it. In the PR-limits post, GitHub said merged pull request volume across the platform grew from about 25 million per month in January 2023 to more than 90 million, a roughly 3.6x increase. The company also explicitly included AI-generated activity in the new limits, saying pull requests opened by Copilot or another AI agent count toward a user's cap.

GitHub quoted several maintainers who backed the move. AutoGPT's Nicholas Tindle said, "It's helped us want to review pull requests again. Knowing that someone hasn't just opened 5-10 pull requests that are slop makes it much easier to want to look." Homebrew's Mike McQuaid said AI had accelerated repeated near-identical submissions and that the setting lets maintainers keep outside contribution while gating users to a level "we can cope with."

That public defense makes the new issue restriction easier to understand. GitHub is applying the same basic idea to another high-volume maintainer queue: give project owners more control over who can create work for them in the first place.

GitHub had already previewed that direction. In the PR-limits post, the company said issue-related controls were coming, including per-repository caps on how many open issues a user without write access can have at once and "an option to restrict issue creation to collaborators." The new collaborator-only issue setting delivers one part of that plan.

The broader rationale goes back to GitHub's February post, "Welcome to the Eternal September of open source." There, GitHub's Ashley Wolf framed the issue as a friction problem. Pull requests, "Good First Issues" and generative AI have lowered the barrier to open source participation, which made contribution easier but also made it easier for low-quality work to arrive at scale.

"Too much keeps people and their ideas out, too little friction can strain the trust open source depends on," GitHub said. "Today, a pull request can be generated in seconds. Generative AI makes it easy for people to produce code, issues, or security reports at scale. The cost to create has dropped but the cost to review has not."

The Maintainer Case
For maintainers, GitHub's case is straightforward: open contribution channels are valuable, but they can also become unmanageable. Spam, duplicate reports, low-effort bug filings, support requests disguised as issues and AI-assisted drive-by submissions can all consume review and triage time.

In the GitHub Community discussion for the June PR-limits rollout, GitHub's Camilla Moraes described the release as part of a broader effort to help maintainers handle contribution volume at scale. "It's become dramatically easier to generate pull requests, issues, comments, and bug reports, but the cost of reviewing them hasn't gone down," she wrote.

The same Community post described the PR cap as a way to manage the flow of incoming PRs "before the queue gets out of hand." It also introduced a bypass list so trusted contributors can be exempt from the limit without requiring full collaborator access.

That point is important for GitHub's defense of the broader direction. The company is not presenting these tools only as hard blocks. It is also presenting them as a way to distinguish between unknown contributors, trusted non-collaborators and users with write access.

The issue restriction carries the same tradeoff. A project can remain public, but its issue tracker can become a controlled intake channel. That may be useful for mirrors, read-only reference implementations, projects in release crunches, repositories with formal support channels, or projects that are swamped by low-signal issue traffic.

GitHub's Response: Make the Controls More Granular
The June PR-limits Community discussion also shows GitHub responding directly to developer questions about how blunt these controls should be.

One developer asked whether GitHub had considered allowing a user assigned to at least one issue to open a PR, matching workflows where maintainers assign issues before accepting outside contributions. Another asked for a similar setting that would allow only users assigned to an issue to open a pull request.

Moraes replied that GitHub is planning "more granular limit controls" so maintainers can decide which users automatically bypass limits based on trust signals such as account age, number of merged PRs in the repository and organization status. She also said GitHub could explore issue assignment as an additional signal.

Another developer asked why draft PRs do not count toward the new limit, noting that draft PRs could still pollute a PR list and potentially act as a workaround for low-quality submissions. Moraes said GitHub chose not to count drafts because maintainers can identify and filter them out of the main review flow, and because feedback had mostly focused on ready-for-review PRs. Still, she said GitHub is "definitely open to revisiting this if feedback trends in a different direction."

Those responses give GitHub's clearest answer to concerns about overblocking: the first generation of contribution controls may be broad, but GitHub says the direction is toward trust-based exceptions, bypass lists and project-specific signals rather than one-size-fits-all gates.

Developer Pushback Has Been Limited but Pointed
The strongest public pushback I found came not around the new issue restriction, but around the earlier pull request access controls. In the GitHub Community discussion for the February PR change, one commenter called the feature "anti-OSS" and said it would "gatekeep new members" from contributing to open source. That commenter argued GitHub should find a middle ground by detecting when an AI agent creates a PR and letting repository owners block that rather than enabling a broad restriction.

Other developers in the same thread defended the feature. One respondent said it is "just a tool" and argued that maintainers have always had the right to decide whether they want to accept outside contributions. Another pointed to years-old requests for the ability to disable or restrict pull requests, suggesting the setting was not a sudden anti-open-source turn so much as a response to longstanding maintainer demand.

I did not find a direct GitHub staff reply to that specific "anti-OSS" criticism in the February thread. GitHub's broader response, however, has been consistent across its posts and changelog entries: the controls are optional, aimed at maintainer sustainability and meant to support different kinds of public repositories, including mirrors, controlled-contribution projects and repos going through critical development phases.

Discussion of the June PR limits was more about implementation than philosophy. In the GitHub Community discussion for that release, developers asked for issue-assignment-based eligibility, programmatic bypass-list management and clarification about draft PRs. GitHub responded with the trust-signal roadmap described above, while its PR-limits blog said the company is also exploring cross-repository controls for contributors who spray pull requests across many repositories at once.

A related Hacker News discussion also focused more on whether per-repository limits solve enough of the problem than on whether maintainers should have controls at all. That aligns with GitHub's own framing: this is not only a spam problem, but also a queue-management and maintainer-attention problem.

A Curious Lack of Pushback on Issues
For a setting that can prevent the general public from opening issues in a public repository, the visible reaction to the new issue restriction has been surprisingly quiet, although it is still early days.

The GitHub Community announcement showed only three comments. One commenter praised the feature as useful for maintainers overwhelmed by low-effort or spam issues and suggested scheduled restrictions for maintenance windows. Another asked for user- or organization-level defaults for both issue and pull request settings. A third appeared to be an unrelated file upload.

That small reaction may suggest that GitHub has already won much of the framing battle. After months of presenting contribution controls as maintainer-sustainability infrastructure -- first through the "Eternal September" argument, then through PR access settings, then through PR caps -- the issue restriction may feel less like a shocking departure and more like the next expected step.

It may also reflect a broader shift in open source expectations. Public code no longer necessarily implies unlimited public intake. A repository can be open for reading, forking and discussion elsewhere while its maintainers reserve the issue tracker for collaborators or trusted contributors.

Not Closing Open Source, But Redefining Intake
The new issue setting does not change GitHub's default model. Repository admins have to enable it. But it does change what GitHub treats as a normal option for public projects.

For years, the implicit expectation on many public GitHub repos was that anyone could file an issue or submit a pull request, even if maintainers were free to ignore, close or reject it. GitHub is now giving maintainers more tools to reduce that work before it reaches the queue.

For maintainers, the upside is less noise and more control. For developers and users, the downside is that a public project may become harder to engage with, especially for legitimate first-time contributors whose first useful act might be filing a bug report.

GitHub appears to be trying to split the difference. Its public argument is that the answer is not to "raise the drawbridge," but to give maintainers better controls, better signals and better ways to preserve trust. Its product direction, however, shows a clear trend: more limits on who can create work for maintainers, how much work non-collaborators can create, and which trust signals might let contributors bypass those restrictions.

The significance is not simply that GitHub added another dropdown. It is that, after publicly portraying PR limits as useful for cutting maintainer noise and responding to requests for more granular trust-based controls, GitHub is now extending that model to issues -- further normalizing the idea that open source participation needs gates, not just open doors.