In the previous post, I organized how major OSS projects rewrote their contribution policies in response to “AI Slop” into three policy types: outright bans, Human-in-the-Loop, and structural closure. That article focused on how the policy documents changed.

This post is a sequel that goes one step further, covering the 2026 cases where projects closed or structurally narrowed the PR gate itself, not just the policy document. On June 5, 2026, the independent browser engine Ladybird completely halted acceptance of public pull requests, a symbolic culmination of this trend. From January through spring, tldraw, Ghostty, openai/codex, and Jazzband all closed off external contribution paths in turn.

And in February 2026, GitHub itself shipped features to disable or restrict PR acceptance, so even the GitHub-era assumption that “welcoming PRs is the default” has begun to waver at the platform level. This post classifies these gate closures by their form, working from primary sources, and closes with practical takeaways from the perspectives of both depending on and running OSS.

From “Policy Documents” to “Closing the Gate”

curl’s bug bounty shutdown and Ghostty’s AI policy, both covered last time, were at the stage of “stating a stance in a document.” Documents work on good actors, but the people throwing Slop don’t read them in the first place. What projects escalated to in 2026 was changing the repository access controls themselves, not the documents.

What drives this change is the asymmetry between generation cost and review cost that I laid out last time. The cost of writing code has dropped to nearly zero, but the cost of reviewing it remains bound to finite human cognitive resources. GitHub’s open-source program director Ashley Wolf summed it up neatly in the February 2026 blog post “Welcome to the Eternal September of open source”: “The cost to create has dropped but the cost to review has not.”

Layered on top of this is the supply-chain security concern that has persisted since the 2024 xz utils backdoor incident (CVE-2024-3094). AI Slop is the problem of “draining review bandwidth through sheer volume,” while the xz incident is the problem of “earning trust and then abusing it.” It is more accurate to read the 2026 gate closures as the confluence of these two threats.

Four Forms of Halting and Restricting

The AI-driven “halts and restrictions of external PRs” observable in 2026 fall into four broad categories by their form. Where the previous post’s policy types (outright ban, Human-in-the-Loop, structural closure) classified “stance on paper,” this classifies “what was actually closed.”

flowchart LR
    A[Halting / Restricting External PRs]
    A --> B[Complete Closure]
    A --> C[Invitation / Vouch]
    A --> D[Auto-close]
    A --> E[Retiring the Reward / Org Model]

    B --> B1[Ladybird]
    C --> C1[openai/codex]
    C --> C2[Ghostty — Vouch]
    D --> D1[tldraw]
    E --> E1[curl — bounty end]
    E --> E2[Jazzband — org sunset]

• Complete closure: Close every public PR path and restrict code changes to maintainers only. Ladybird is the archetype.
• Invitation / Vouch: Stop unsolicited external PRs and admit only invited or vouched contributors. openai/codex and Ghostty.
• Auto-close: Allow PR creation but automatically close external PRs with a bot. tldraw.
• Retiring the reward / org model: Fold the reward program or the collective-maintenance organizational model itself, rather than the gate of an individual repository. curl’s bug bounty removal, Jazzband’s dissolution.

Let’s look at each case in turn.

Ladybird — Complete Halt of Public PRs

Ladybird is a fully independent browser engine that depends on none of Blink, WebKit, or Gecko, spun out from SerenityOS in June 2024. With over 60,000 GitHub stars, over 3,000 forks, and more than 1,200 contributors, it is run by the nonprofit Ladybird Browser Initiative. GitHub co-founder Chris Wanstrath put in $1 million of his own funds, and it also receives backing from Shopify and Cloudflare.

On June 5, 2026, founder Andreas Kling declared in the blog post “Changing How We Develop Ladybird”: “We will no longer accept public pull requests. From now on, code changes to the Ladybird codebase will only be introduced by project maintainers.” The reason: ahead of an alpha release, the project needs “a tighter development process, a clearer security model, and a smaller set of people responsible for the code that enters the browser.”

The most-quoted passage confronts head-on the collapse of the “effort as a proxy for good faith” premise I touched on last time: “A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds.” Kling also made the supply-chain concern explicit: “A browser runs untrusted input from the entire internet on the user’s machine, and one well-disguised vulnerability is all an attacker needs. We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it.” This is clearly a statement made with xz-utils-style attacks in mind.

The form of the shutdown is thorough. All existing public PRs were closed too, and the project explicitly stated it would not create “a shadow contribution system through issues, comments, email, or forks.” At the same time, it continues to welcome bug reports, test cases, website testing, standardization discussions, security reports, and technical feedback. The license stays BSD-2-Clause, keeping the code open source. In other words, it narrowed only the right to merge code while leaving the other contribution paths open.

Reactions split. Critics asked whether a project that accepts no external code contributions at all is really open source, and warned that concentrating authority in maintainers creates a single point of failure. Defenders cited the SQLite development model (accepts bug reports but strictly controls code contributions) as a precedent. Ladybird is the definitive case showing that the naive equation “open source = anyone can send code” is no longer self-evident in 2026.

openai/codex — Halting Unsolicited PRs and collaborators-only

openai/codex is an Apache-2.0-licensed coding-agent CLI, a massive repository with roughly 91,000 stars and 13,500 forks. In Updating Codex Contribution Guidelines #9956 on January 27, 2026, it switched its previously external-PR-centric model to invitation-only.

The wording is plain: “We no longer accept unsolicited pull requests.” The reasoning is that while AI tools have made code generation cheap and fast, the human cost of review, fixing, and integration remains high, and external submissions, lacking shared architectural context and near-term roadmap, end up as a maintainer bottleneck. Maintainer etraut-openai stated bluntly that external PRs had become a “bottleneck rather than a force multiplier.”

The policy was then codified in docs/contributing.md, which goes as far as “pull requests that have not been explicitly invited … will be closed without review.” This is not merely “please file an issue first” but a strong halt: PRs without an invitation aren’t even reviewed. The technical state backs this up: the PR list shows “New Pull request creation is restricted,” and the GitHub API’s repo metadata returns pull_request_creation_policy: "collaborators_only". The project has begun using GitHub’s platform feature, discussed below, as a formal governance mechanism.

What’s interesting is that community reaction appeared less as outright backlash than as a change in submission style. In several issues, external developers explicitly noted that “since the contribution policy is invitation-only, I’m submitting this as an enhancement request rather than a PR,” attaching a reference implementation on a local branch or fork. The center of gravity of contribution shifted from directly submitting code diffs to submitting analysis, proposals, and reproduction information.

tldraw — Auto-closing External PRs and the “AI Self-Loop”

tldraw is a React-based infinite-canvas SDK. As I noted last time, founder Steve Ruiz introduced a policy of auto-closing external contributors’ PRs in Issue #7695 on January 15, 2026, and detailed it in the January 17 blog post “Stay away from my trash!”.

What I want to re-emphasize in this sequel is the structure tldraw identified: the “AI self-loop” (AI-to-AI looping). Ruiz used a /issue command for Claude Code to cheaply turn minor anomalies into issues. External contributors fed those issues into their own coding agents, generated diffs without understanding the contents, and returned them as PRs. The result was a futile automation cycle in which “code whose own author cannot explain its coherence” is auto-submitted against “incomplete issues the maintainer hasn’t deeply examined.” The submitted PRs passed both syntax and CI, yet completely ignored the architecture and long-term design patterns, and often left the PR template and CLA unaddressed.

Note that tldraw is not strictly OSI-compliant open source but “source-available” (the tldraw license), requiring a license key for production use. Even so, as a project published on GitHub that received PRs from the community, it counts as a representative case of gate closure. The form of the shutdown is “auto-close of external PRs,” with issues and bug reports still welcome, positioned as “a temporary policy until GitHub provides better management tools.” As noted below, GitHub shipped those “better tools” in February.

Ghostty — Vouch as a Web of Trust

Ghostty is a GPU-accelerated terminal emulator developed in Zig by HashiCorp co-founder Mitchell Hashimoto. Last time I covered the staged tightening of its AI policy (the August 2025 disclosure requirement, the January 2026 AI_POLICY.md, the February Vouch Request system).

What I want to dig into in this sequel is the mechanism behind Vouch itself. Hashimoto built and integrated into Ghostty a Web-of-Trust tool, Vouch, in which external users cannot submit a PR unless explicitly vouched for by a trusted existing member. What’s distinctive is the design: the trust list is managed not in a database or external API but in a single text file inside the repository (Trustdown format), parsed via POSIX tools and GitHub Actions. As of June 2026, a growing number of repositories are reported to have adopted Vouch, led by Ghostty’s own production use.

Hashimoto has consistently framed this as an “anti-idiot, not anti-AI” stance. Most of Ghostty’s maintainers use AI daily; the problem is not using AI but the act of making others review code you neither understand nor have verified. Vouch is an attempt to gate that “anonymous influx of unverified code” through human trust relationships.

curl and Jazzband — Ending a Bounty Program and Sunsetting an Organization

Let me briefly situate two cases I covered in detail last time within the gate-closure context.

curl announced the end of its bug bounty, running since 2019, in Daniel Stenberg’s January 26, 2026 blog post “The end of the curl bug-bounty” (the program officially ended on January 31, 2026). This is the end of a reward program rather than a halt of PR acceptance, but in cutting off the financial incentive (the “lure at the gate”) after AI-fabricated fake vulnerability reports dragged the valid-report rate below 5%, it is continuous with this post’s theme. Reporting was limited to GitHub Private Vulnerability Reporting.

Jazzband announced the end of the organization itself in “Sunsetting Jazzband” on March 14, 2026. The explanation: the “shared push access” model that had collectively maintained 84 Python projects became untenable in a world flooded with AI-generated spam. Rather than closing the gate of an individual repository, this was the heaviest case, folding the collective-maintenance organizational model itself.

Node.js — The Debate Sparked by a 19,000-Line AI-Generated PR

It’s not a gate-closure case, but the Node.js episode is indispensable as a symbol of 2026’s central issue.

In January 2026, Matteo Collina, a Node.js core TSC (Technical Steering Committee) member and author of Fastify, submitted a PR (#61478) implementing a virtual file system feature of about 19,000 lines (by the PR’s own breakdown, roughly 9,200 lines of code, 11,200 of tests, and 1,300 of docs, totaling over 20,000). He posted it after disclosing that he had “used a lot of Claude Code tokens but reviewed all the code himself.” In response, Fedor Indutny, who created the io.js fork, launched a petition to ban acceptance of LLM-generated PRs and demanded a TSC vote.

The points of contention were less the code quality itself than compliance with the DCO (Developer Certificate of Origin), the reviewability of a giant diff, and the fairness of paid tools effectively becoming a “soft paywall.” This episode sharply illustrated the issue one step short of gate closure: how a trust-based community should handle a “large AI-generated PR disclosed as human-reviewed.” The concern is that when code review degrades from “mutual understanding of design intent” to “mere syntax checking and behavior verification,” the merged code becomes technical debt stripped of context.

GitHub — The Platform’s Response

In response to maintainers’ departures and outcries, GitHub too stepped into a platform-level response in February 2026. Last time I touched briefly on the feature’s existence; in this sequel let me pin down the specifics.

On February 13, 2026, GitHub officially released changes to repository settings.

• Disable pull requests entirely: Turn off the PR feature from Settings. When enabled, the “Pull requests” tab itself disappears, and you can neither open new PRs nor view existing ones. For mirrors and read-only codebases.
• Restrict pull requests to collaborators: Keep the PR tab but limit PR creation to collaborators with write access. You can block only unapproved external users’ PRs.

These can be changed from Settings > General > Features, and the setting is reflected in the repository’s metadata. openai/codex returning pull_request_creation_policy: "collaborators_only" comes from exactly this feature.

The feature provoked fierce debate in the community. Some criticized it as “anti-OSS, building barriers to entry and fostering an exclusionary culture; they should instead build a middle layer that identifies and blocks only AI-generated PRs.” Many maintainers, on the other hand, defended the legitimacy of the measure: “developers share their code for free, but they’re under no obligation to review others’ code.” The “soccer stadium and vuvuzela” metaphor born in the debate is apt: if spectators (contributors) all blow free megaphones (generative AI) at once until the players (maintainers) can no longer continue the match, the stadium (GitHub) has no choice but to restrict what’s brought in (PRs).

An Academic Framing — The Three Types of “Beyond Banning AI”

Alongside individual cases, academic framing is advancing too. The March 2026 paper “Beyond Banning AI: A First Look at GenAI Governance in Open Source Software Communities” analyzed the governance responses of 67 notable OSS projects and classified them into three directions. These map closely onto the previous post’s three types and are useful as external corroboration.

1. Prohibitionist / zero-tolerance: Treats AI-generated code as intellectual-property uncertainty or “tainted code” and closes the gate at the input stage. QEMU and NetBSD are representative.
2. Boundary-and-accountability: Permits AI use while imposing disclosure, verification, and full assumption of responsibility. The Linux kernel, CloudNativePG, Aurelia, and others.
3. Quality-first / tool-agnostic: Deems policing the means of generation unrealistic and responds by re-asserting and reinforcing existing quality standards, CI, and manual review. Oh My Zsh and curl are representative.

The essential problem the paper raises is the “wall of missing information” that AI-generated code leaves behind. When you generate 19,000 lines in an instant (the Node.js example), there’s no context for “why this design” or “which trade-offs were considered.” It further notes the concern of “model collapse,” where AI-generated code published on the web becomes training data for the next generation of models. Code generation without design thinking, the paper argues, harbors a downward spiral that degrades software quality over the long run.

Wrapping Up

Last time I organized policy design for those running OSS. From this sequel’s set of cases, three points become practically instructive, including the perspective of those who depend on OSS, not just those who run it.

1. Read the “intensity” of the closure.
   • Even among AI-driven closures, the meaning as a dependency differs by the form of the halt.
   • Ladybird’s complete closure effectively centralizes authority in maintainers.
   • codex’s and Ghostty’s invitation/vouch model lets you keep contributing if you build a relationship.
   • tldraw’s auto-close is a temporary measure pending GitHub’s tooling.
   • What they share is keeping non-code paths such as issues, bug reports, and security reports open, narrowing only the right to merge code.
   • Look at the intensity with which a dependency has closed to decide whether to fork, build a relationship and keep contributing, or wait.
2. Read the license as the premise of a fork strategy.
   • Permissive licenses like Apache-2.0 and BSD leave legal room to carry on via a fork even when upstream closes (Ladybird stays BSD-2-Clause, codex stays Apache-2.0).
   • With a source-available license like tldraw’s, the PR halt and the license restriction overlap to narrow the escape route.
   • For important dependencies, add license and governance together to your evaluation criteria.
3. Treat supply-chain security and AI Slop at the same table.
   • As Ladybird invoked xz-style trust-abuse attacks, the 2026 gate closures sit at the confluence of two threats: the exhaustion of review bandwidth and the abuse of trust.
   • Evaluate the bus factor, funding status, and contributor-acceptance policy of the OSS you depend on, and support it with sponsorship where needed.
   • Put a brake, via internal policy, on your own developers “dumping” AI-generated code upstream.
   • Protecting a dependency’s maintainers ultimately protects your own supply chain.

As I wrote in last time’s conclusion, the model of open contribution in OSS is not dead. But 2026 was the year the naive premise of the GitHub era, that “welcoming PRs is the default,” began to crumble from the platform level. The source of value has clearly shifted from “writing code” to “setting the right problem” and to “building explicit trust.” The return to a Web of Trust that Ghostty’s Vouch represents may be its most concrete expression.

That concludes this sequel on how OSS projects began closing the external PR gate in 2026, sent from the gemba.

References

• Ladybird official site
• tldraw official site
• Ghostty official site
• Jazzband official site