Skip to content

The publication for web craftspeople Monday, 7 September 2026

Back-end

Laravel closes GitHub Issues on its packages and points bug reports to coding agents

Taylor Otwell has turned off GitHub Issues on most Laravel packages, asking users to open a pull request drafted with a coding agent instead. The core framework repository is untouched, but the move reopens the debate over how high-traffic open source gets…

Illustration de couverture aux couleurs de Laravel

On 4 September 2026, Taylor Otwell turned off the Issues tab on most of Laravel’s open source packages. The instruction to users is blunt: describe the bug to a coding agent and open a pull request, rather than file a ticket. The core framework repository is left out, but the decision reopens the debate over how a high-traffic open source project should be maintained.

What Taylor Otwell changed

The change applies to the ecosystem’s first-party packages, the ones that orbit the framework without forming its core. On those repositories, GitHub’s Issues tab no longer accepts new tickets. The laravel/framework repository stays outside the scope and keeps receiving reports the usual way.

The rationale fits in a sentence the maintainer stands behind: a bug is now better documented by a proposed fix than by a description left waiting. Triage load, routinely named as the leading cause of maintainer burnout, is pushed upstream, onto the person who runs into the problem.

“If you hit a bug, describe it to a coding agent and open a PR. Even if the code isn’t great, that’s fine: code can be iterated on.”

“Describe the bug, open a PR”: the expected flow

The principle moves the entry point of a contribution. Where a ticket opened a discussion, the pull request becomes the unit of reporting: it carries both the description of the problem and a first attempt at a fix. The initial quality of that fix is secondary, since it can be reworked in review. In practice, the suggested path relies on the usual command-line tooling.

# No ticket: a branch, a fix described to an agent, a PR
git checkout -b fix/edge-case

# the fix is generated, then reviewed locally and the tests re-run
git commit -am "Fix cache handling for the edge case"

# the pull request documents the bug AND proposes the solution
gh pr create --fill --base main

Symfony takes the opposite road

The move contrasts with part of the PHP ecosystem. Several projects, Symfony chief among them, keep ticket filing as the entry point and hand the writing of the fix to their teams or internal tooling. Two opposite strategies emerge from the same observation: the volume of reports outstrips what volunteer maintainers can process.

ProjectReporting a bugWriting the fixRole given to AI
Laravel packagesDirect pull requestThe contributorGenerate the proposed fix
Symfony packagesClassic ticketThe project teamAssist on the maintainer side
laravel/framework repoClassic ticketThe maintainerNot mandated

What the move changes for contribution

For the maintainer, the gain is immediate: fewer tickets to triage, a repository where every entry already comes with an executable diff. For the contributor, the required effort rises. Reporting a bug is no longer just describing a symptom: it means producing a branch, a fix and, ideally, a test. The coding agent lowers that barrier without removing it, and the approach assumes the person has such a tool and knows how to drive it.

Watch out. A bug a user can describe but not fix risks never being reported. The shift can also transfer the load from triage to review, if a flood of rough pull requests replaces the flood of tickets. The traceability of a problem then depends on the quality of the PR that carries it.

The takeaway

Laravel closes tickets on its satellite packages and makes the AI-assisted pull request the new entry point, while Symfony keeps the ticket and retains control of the fix. The core framework, for its part, does not move. Two visions of open source maintenance in the age of coding agents now coexist, and the coming months will tell which one holds at scale.

I maintain a handful of repositories, on a scale nowhere near Laravel’s, and the fatigue of ticket triage is something I know well. The idea of receiving a diff rather than a “doesn’t work on my machine” is genuinely appealing. Yet I stay cautious: on my own projects, the best reports often come from users who can describe a problem perfectly without being able to solve it. Closing that door is a bet that the coding agent will bridge the gap for everyone. The bet is worth watching; I would not yet generalise it to a project whose community lacks a culture of contribution. — Simon Janvier

Further reading

Taylor disabled GitHub Issues on most Laravel open-source packages (Laravel News)

Read next