Laravel Closes GitHub Issues: AI Agents Now Required for Bug Reports

What Actually Happened: Not All Laravel Repositories

In early September 2026, Taylor Otwell announced on X that he had closed Issues on most Laravel open-source packages. He instructed users to describe bugs to a coding agent and open a pull request instead, adding that imperfect code is acceptable because it can be iterated on. The internet reacted strongly, prompting Otwell to clarify that the change applies only to peripheral packages , not the core framework.

The distinction matters because Laravel has two repositories often called "main": laravel/framework — the core framework source code pulled via Composer. Issues remain open. laravel/laravel — the application skeleton generated by laravel new. Issues are closed.

A manual check of first-party packages in September 2026 shows the policy is not a blanket closure:

Issues closed: laravel (skeleton), telescope, sanctum, scout, socialite, pint, prompts, reverb, sail, breeze, folio, pennant, docs Issues open: framework (core), horizon, jetstream, passport, cashier-stripe, nova-issues Horizon, the primary queue-monitoring package, retains Issues, confirming the decision is per-repository , not universal. The official wording uses "most," not "all."

Contribution Guide: "Strongly Encourage" PRs, Not "Ban" Issues

The Laravel 13.x Contribution Guide now states:

To encourage active collaboration, Laravel strongly encourages resolving issues via pull requests rather than submitting GitHub issues. We have disabled GitHub issues for most first-party packages. If you find a problem, please create a pull request that fixes it… If you don't know how to fix it, describe the issue to a coding agent and use it to attempt a pull request.

This is a rare explicit endorsement of AI-assisted contributions in a mainstream framework's official workflow — not as an option, but as the default path .

Support Channels Remain

Questions and discussions are directed to GitHub Discussions, Laracasts forum, Laravel.io, Stack Overflow, and Discord. Security vulnerabilities go to [email protected]. Only the "I found a bug, you deal with it" interaction is removed.

Why the Policy Makes Sense: Four Arguments

1. Filters Low-Quality Noise

Filing an issue costs near zero; in the LLM era, that enables mass-generated "suspected bug" reports, bot spam, and drive-by error dumps that overwhelm maintainers. Creating a PR — even with AI — requires forking, editing code, running tests, and writing a description. This cost reallocation moves the burden from maintainers to submitters.

2. PRs Carry Higher Information Density

An issue says "error in scenario X"; maintainers must reproduce, locate, and assess impact — often half a day. A PR pins the problem to a specific file and line, includes a fix attempt, and often a reproducing test. Even a wrong fix is a higher-fidelity problem description than natural language. Otwell's "code doesn't have to be great" remark reflects this: the PR records the issue concretely.

3. AI Has Lowered the Submission Barrier

Five years ago, requiring PRs would exclude 95% of reporters. Today, a user unfamiliar with Laravel's queue internals can feed the error and reproduction steps to a coding agent, which reads the source, locates the bug, and generates a patch. The capability gap between filing an issue and opening a PR has been largely bridged by AI tools .

4. Maintenance Resources Are Linear; AI-Generated Problem Volume Is Exponential

Maintainer count is linear (or shrinking), while AI makes problem production exponential. The old open-source compact — "users throw problems over the wall, community solves them" — assumed reporting and fixing rates roughly matched. That premise is broken. Laravel rewrites the compact: don't throw the problem over; bring a draft solution.

Real Costs and Trade-offs

Users Who Can't Express Problems as Code

Many valuable bug reports come from ops engineers, production incidents, or specific PHP version + extension combos. Reporters may lack a local reproduction environment, let alone ability to craft a PR. Discussions partially catches these, but it lacks Issues' searchability, deduplication, and state tracking — it's a forum, not an issue tracker.

Loss of Public Knowledge Base

Issues serve as a searchable archive. Countless developers solve problems by finding a three-year-old issue closed as stale. Closing Issues removes that sediment layer. PRs are searchable too, but only for fixed problems; unresolved issues with workarounds have no home.

Internal Tension in AI Policy

The same Contribution Guide contains a contradictory-seeming section on "AI-Generated Contributions":

Substantial contributions primarily generated by AI without thoughtful human review are not accepted… PR descriptions must be written entirely by the contributor; PRs with AI-generated descriptions will be closed. Mass creation of fully AI-generated issues or PRs is not tolerated; such PRs will be closed without review and the contributor may be banned.

The reconciliation: AI can be your tool, not your ghostwriter. Using AI to locate bugs and draft patches is allowed because it helps articulate the problem; using AI to bulk-generate PRs or write descriptions is banned because it shifts review cost back to maintainers. The line is not "did you use AI" but "did a human take real responsibility for this submission." Enforcement remains fuzzy — maintainers must judge intent, likely relying on feel and post-hoc bans.

Opposite Approach in the PHP Ecosystem

Per Laravel News, some PHP projects choose the reverse: accept only issues, then have maintainers or their own AI write the fixes. This is the same dilemma solved by placing AI at different points in the pipeline:

AI Placement: Laravel puts AI on the contributor side; the reverse route puts AI on the maintainer side.

User Barrier: Laravel requires opening a PR (slightly higher); reverse route keeps the lowest barrier.

Maintainer Load: Laravel shifts to reviewing PRs (high info density); reverse route keeps maintainers doing triage + self-fix.

Spam Filter: Laravel relies on submission cost; reverse route relies on maintainer screening.

Main Risk: Laravel risks flood of low-quality PRs and review pressure shift; reverse route keeps maintainer as bottleneck.

Both attempt to rebalance reporting vs. fixing with AI. Laravel distributes compute and time costs across thousands of users, sacrificing some low-expression reporters. The reverse route keeps the door open but keeps the bottleneck at maintainers — now "read issue + direct AI to fix."

Otwell's relaxed stance: "If this doesn't work, so what? Just reopen Issues." That mindset — a reversible experiment, not a constitution — may be more valuable than the rule itself.

Transferable Lessons for Teams and Projects

Revisit your "entry cost" design. After AI drives content production cost near zero, any channel where submission cost < processing cost will drown. Not just open-source issues — support tickets, internal request queues, code review requests face the same. The fix isn't necessarily closing the door, but adding submitter-side cost (e.g., "must include reproduction steps and attempted solutions").

Make "bring a draft solution" the default culture. Internally, replace "this API is slow" with "this API is slow; I had AI check and it looks like N+1; here's my patch, tell me if it's right." Even a wrong draft raises the discussion starting point. AI makes "draft first" cheap enough to institutionalize.

Don't treat AI as a liability shield. Laravel's "PR description must be written entirely by the contributor" is worth copying. Generating with AI is fine; submitting means you've read, understood, and verified. People who blur this line burn credibility fast in any organization.

Keep an overflow channel. Laravel didn't weld the door shut: Discussions, forums, Discord, security email remain. Any hard constraint needs a pressure valve, or you block not just noise but the critical signals you actually need.

Conclusion

"No issues, only PRs" grates because it breaks a twenty-year implicit open-source contract: users find problems, community fixes them. Laravel declares that contract expired — not because maintainers got lazy, but because question velocity has decisively outpaced answer velocity.

Today, with AI narrowing the gap between "found a bug" and "tried a fix" to near zero, preserving the old contract only makes maintainers collapse first. Laravel chooses an inelegant but honest alternative: since the marginal cost of fixing a bug has dropped to the level of describing one, please just fix it on the way.

Whether this becomes industry standard depends on the quality of AI-assisted PRs over the coming months. If they're mostly usable, Otwell's prophecy holds; if they're just spam in a costlier disguise, the Issues switch can be flipped back. Either way, one thing is clear: open-source collaboration rules are being rewritten by AI, and the direction isn't "make users' lives easier" — it's "make everyone take one more step forward."