---
title: "Laravel desactivó los issues en sus paquetes: ahora solo acepta pull requests"
excerpt: "Socialite, Scout, Telescope, Sanctum y una veintena más de repos oficiales ya no dejan abrir issues. El framework sí. Comprobé repo por repo cuáles cayeron y qué significa para quien solo quería reportar un bug."
date: "2026-09-05T10:30:00.000Z"
category: "Laravel"
tech_article: true
author:
  name: "angel cruz"
  picture: "/images/me/angel-cruz.png"
ogImage:
  url: "/images/open-graph/laravel-opengraph-image.png"
seo_title: "Laravel desactivó los issues en sus paquetes: qué repos y qué hacer ahora"
seo_description: "Laravel deshabilitó GitHub Issues en Socialite, Scout, Telescope, Sanctum, Octane, Pint y más. Lista verificada de repos, por qué el framework sigue abierto y cómo reportar un bug hoy."
---

**Laravel deshabilitó la pestaña de Issues en buena parte de sus repositorios de paquetes y pide que abras un pull request en su lugar. `laravel/framework` sigue aceptando issues.** Si usas Socialite, Scout, Telescope, Sanctum, Octane o Pint y encuentras un bug, el botón para reportarlo ya no está.

Lo anunció Taylor Otwell en X (traduzco):

> La semana pasada deshabilité los issues de GitHub en la mayoría de los paquetes open source de Laravel.
>
> Si te topas con un bug, descríbeselo a un agente de código y abre un PR. Aunque el código no sea bueno, no pasa nada: el código se puede iterar. El PR sigue documentando el problema, y luego puede venir un arreglo en condiciones.
>
> Sospecho que pronto así es como va a funcionar la mayoría de las librerías open source.

Fuente: https://x.com/taylorotwell/status/2095516796748996843

[Brent Roose lo comentó en stitcher.io](https://stitcher.io/blog/no-more-issues) el 4 de septiembre de 2026. Su lectura, resumida, es que un proyecto open source debería bajar la barra de contribuir y no subirla, y que exigir un PR la sube.

Estoy de acuerdo con la mitad. Creo que la barra no subió, se movió de sitio, y en un repo de Laravel se vio dónde cayó.

## Qué repos de Laravel tienen los issues desactivados

Consulté la API de GitHub repo por repo el 4 de septiembre de 2026, leyendo el campo `has_issues`. Puedes reproducirlo con la CLI de GitHub:

```bash
gh api repos/laravel/socialite --jq '.has_issues'
```

Con los issues desactivados, al 4 de septiembre de 2026:

- `laravel/laravel`
- `laravel/socialite`
- `laravel/scout`
- `laravel/telescope`
- `laravel/sanctum`
- `laravel/breeze`
- `laravel/octane`
- `laravel/pennant`
- `laravel/pulse`
- `laravel/prompts`
- `laravel/reverb`
- `laravel/folio`
- `laravel/vapor-cli`
- `laravel/envoy`
- `laravel/dusk`
- `laravel/sail`
- `laravel/pint`
- `laravel/ui`

Con los issues todavía abiertos:

- `laravel/framework`
- `laravel/horizon`
- `laravel/passport`
- `laravel/jetstream`
- `laravel/fortify`
- `laravel/cashier-stripe`
- `laravel/cashier-paddle`
- `laravel/echo`
- `laravel/valet`
- `laravel/homestead`
- `laravel/installer`
- `laravel/tinker`
- `laravel/serializable-closure`
- `laravel/nightwatch`
- `laravel/mcp`
- `laravel/boost`
- `laravel/wayfinder`.

> `laravel/laravel`, el esqueleto de aplicación que instalas al crear un proyecto, también está cerrado. Y el corte no sigue la línea que uno esperaría: Horizon está abierto y Pulse cerrado, aunque los dos son paquetes de primera parte con dashboard. Los productos más recientes (Nightwatch, MCP, Boost, Wayfinder) siguen abiertos. Parece una limpieza de lo que más ruido de triaje generaba, no una política uniforme.

Esta lista caduca. Si lees esto meses después, corre el comando y comprueba.

## Por qué un maintainer haría esto

Brent, que mantiene [Tempest](https://tempestphp.com/), defiende esta parte desde dentro: un issue es una petición de trabajo dirigida a otra persona, y el tiempo del maintainer es el recurso escaso del open source. Cuando quien reporta ya intentó una solución, aunque sea mala, aporta algo que el issue no tiene: dónde creyó que estaba el problema.

El triaje, además, es el trabajo más ingrato que existe en un repo popular. No produce código, no se ve en el changelog y se come las tardes. Cerrar la puerta reduce el volumen de entrada de golpe, sin negociar.

Hasta ahí el cálculo se sostiene.

## El coste no desaparece, se muda al review

Escribir un PR mediocre hoy cuesta casi lo mismo que escribir un issue. Le describes el fallo a un agente de código, te devuelve un parche, lo abres. La fricción que el cambio pretendía crear no existe para quien tiene una suscripción de veinte dólares al mes.

Lo que sí cambia es quién paga la revisión. Un issue malo se lee en treinta segundos y se cierra. Un PR malo trae diff, tests, CI, y hay que leerlo entero para saber que está mal. Brent apunta un efecto de segundo orden que me parece el más concreto de su post: cuando un release rompe algo para mucha gente, llegan decenas de PR duplicados en horas, y cada uno dispara los workflows de GitHub Actions. Los issues duplicados no consumen minutos de CI.

## El caso vapor-cli: revisar de dónde salió el código

Fíjate en la frase del anuncio que hace todo el trabajo: "el PR sigue documentando el problema". Es decir, el PR vale aunque el código no sirva, porque el reporte viaja dentro. Brent enlaza [un comentario de Taylor en el PR #285 de `laravel/vapor-cli`](https://github.com/laravel/vapor-cli/pull/285) para apoyar que el código generado por LLM sigue necesitando un ojo humano experto. El hilo del que sale esa frase, que reconstruí con la API de GitHub, ocurrió entero el 3 de septiembre de 2026 en unas horas:

- 07:57 UTC. Se publica `v1.70.4`, que amplía la restricción de Composer para permitir Guzzle 8.
- 08:52 UTC. El usuario `datashaman` abre el PR #285. No arregla el despliegue: hace que `displayValidationErrors()` deje de asumir que todo 4xx trae un saco de errores de validación, para que el error se vea en vez de imprimir un "Whoops!" vacío.
- 09:01 UTC. `maliknikolaj` comenta con la causa real: `guzzlehttp/psr7` 3 dejó de pasar el método HTTP a mayúsculas en el constructor de `Request`, y el CLI llama a `request('post', ...)` en minúscula. Con Guzzle 8 la petición sale literalmente como `post /api/... HTTP/1.1` y el balanceador delante de `vapor.laravel.com` responde un 400 en HTML antes de llegar a la aplicación. Lo demuestra con dos `curl`, uno con `-X POST` y otro con `-X post`.
- 09:05 UTC. `abedshamia` confirma el fallo con su propia línea de tiempo de despliegues en CI y el pin a `1.70.3` como solución temporal.
- 09:10 UTC. `datashaman` abre el PR #286 con el arreglo real, dos líneas de cambio efectivas más tests, acreditando el diagnóstico a quien lo encontró.
- 14:10 UTC. Taylor mergea el #286. Un minuto después sale `v1.70.5`.
- 14:21 UTC. Taylor cierra el #285 con una respuesta de plantilla: que la contribución parece generada principalmente por IA sin revisión humana cuidadosa, y que las contribuciones de calidad requieren criterio humano sobre el código.

Once minutos separan el merge del arreglo y el cierre del otro PR de la misma persona por parecer escrito por una máquina.

No sé si el #285 lo escribió una IA. Nadie lo sabe mirando el diff, y ahí está el problema. Lo comprobable es que el hilo produjo el diagnóstico correcto, un fix mergeado y un release el mismo día. El #285 documentaba el problema, que es justo lo que el anuncio pedía de un PR, y aun así se cerró por cómo estaba escrito.

Cuando la contribución era un issue, el maintainer juzgaba una sola cosa: si el bug existe. Cuando es un PR, juzga si el código sirve, si encaja con las convenciones del proyecto, y ahora también de dónde salió. Esa tercera pregunta no tiene respuesta fiable, se contesta por olfato, y equivocarse sale barato para el proyecto y caro para quien contribuye.

## A quién deja fuera

Brent plantea el argumento de inclusividad y creo que se queda corto en un punto que desde Latinoamérica se ve mejor.

Es verdad lo que dice: hay gente sin acceso a herramientas de IA por dinero o por convicción, y para ellos el salto de reportar a arreglar es enorme. Pero antes que el acceso a la IA pesa el idioma. Escribir un issue en inglés imperfecto describiendo lo que te pasó es una cosa. Abrir un PR contra el repositorio de Laravel, con el nombre de Taylor Otwell en la lista de revisores, es otra completamente distinta. Mucha gente que reportaría un bug no va a abrir ese PR nunca, y no por falta de capacidad técnica.

Ese reporte que no llega no aparece en ninguna métrica. El maintainer ve que bajó el ruido; no ve los bugs que dejaron de contarse.

## Cómo reportar un bug de Laravel hoy

**Comprueba primero si el repo tiene issues.** No asumas. `gh api repos/laravel/NOMBRE --jq '.has_issues'`, o mira si aparece la pestaña.

**Si el bug es del framework, va en `laravel/framework`.** Sigue aceptando issues y es donde acaba la mayoría de los bugs de comportamiento del núcleo, aunque los notes usando un paquete.

**Si el paquete está cerrado, te queda el foro.** Esos repos tampoco tienen Discussions activadas, comprobé `has_discussions` en todos y devuelven `false`, así que dentro de GitHub no hay otra puerta. Escribe en [laracasts.com/discuss](https://laracasts.com/discuss): un reporte bien redactado ahí lo encuentra el siguiente que busque el mismo error, que es la mitad del valor de un issue.

**Si abres un PR, que la descripción sea el issue que no pudiste abrir.** El error literal, la versión exacta desde la que falla, el comando mínimo que lo reproduce y qué esperabas. El #285 hace esto bien: pega el warning, el archivo, la línea y el endpoint que muere primero.

**Separa el diagnóstico del arreglo.** Si encuentras la causa y además la parcheas, dilo explícitamente y en ese orden. El hilo del #285 y el #286 es un buen modelo: un PR es la causa, el otro es la visibilidad, y en la descripción queda claro cuál es cuál.

**No mandes un parche que no entiendes.** Vas a tener que defenderlo en la revisión, y ahí es donde se cae. Si el agente te dio algo que no sabes explicar, conviértelo en una descripción del problema y deja el código fuera.

## Lo que queda por ver

La pregunta abierta es si `laravel/framework` aguanta. Brent lo deja apuntado y yo tampoco tengo respuesta: si el objetivo es reducir triaje, el repo con más issues del ecosistema es el candidato evidente, y hoy es la única puerta que le queda a quien solo puede reportar.

Taylor cierra su anuncio diciendo que sospecha que pronto así va a funcionar la mayoría de las librerías open source. Puede que acierte, y por eso conviene mirar bien este primer caso: lo que Laravel decida sobre qué hacer con un PR que documenta un bug pero trae código flojo se va a copiar en muchos repos más pequeños, donde no hay equipo a tiempo completo para revisarlo.

Lo otro que me ronda lo menciona Brent de pasada y me parece el marco correcto: Laravel hace tiempo que no es solo un proyecto open source. Es una empresa con producto, equipo a tiempo completo y clientes de pago sobre un ecosistema que nació abierto. Cerrar los issues en un proyecto de fin de semana es supervivencia. A esta escala es una decisión de producto, y quien la paga es el que todavía no forma parte del ecosistema.

## Preguntas frecuentes

### ¿Laravel desactivó los issues en todo el framework?

No. `laravel/framework` sigue aceptando issues al 4 de septiembre de 2026. El cambio afecta a repositorios de paquetes como Socialite, Scout, Telescope, Sanctum, Octane, Pint o Sail, y también a `laravel/laravel`, el esqueleto de aplicación.

### ¿En qué repos de Laravel están desactivados los issues?

Verificados el 4 de septiembre de 2026: `laravel/laravel`, `socialite`, `scout`, `telescope`, `sanctum`, `breeze`, `octane`, `pennant`, `pulse`, `prompts`, `reverb`, `folio`, `vapor-cli`, `envoy`, `dusk`, `sail`, `pint` y `ui`. La lista puede cambiar; compruébala con `gh api repos/laravel/NOMBRE --jq '.has_issues'`.

### ¿Tengo que usar IA para mandar un pull request a Laravel?

Obligatorio no es, aunque el propio anuncio recomienda describirle el bug a un agente de código y abrir el PR con lo que salga. Cuidado con tomárselo al pie de la letra: Taylor cerró el PR #285 de `vapor-cli` alegando que parecía generado por IA sin revisión humana suficiente. Manda código que puedas defender en la revisión, lo hayas escrito con ayuda o sin ella.

### ¿Qué hago si solo quiero reportar un bug de Laravel y no sé arreglarlo?

Si el bug es del núcleo, abre el issue en `laravel/framework`, que los sigue aceptando y además tiene Discussions activadas. Si es de un paquete cerrado, no hay alternativa dentro de GitHub (esos repos tampoco tienen Discussions), así que queda [laracasts.com/discuss](https://laracasts.com/discuss). Si te animas con el PR, la descripción bien hecha vale más que el parche.

### ¿Por qué un pull request puede costar más de revisar que un issue?

Porque un issue malo se descarta en segundos y un PR malo hay que leerlo entero, con su diff y sus tests, para saber que está mal. Además dispara los workflows de CI cada vez que se abre o se actualiza, y tras un release roto llegan decenas de PR duplicados arreglando lo mismo.

### ¿Esto significa que Laravel ya no acepta reportes de bugs?

Los acepta, pero cambia la forma en la mayoría de los paquetes: el reporte va dentro de la descripción de un pull request en vez de en un issue. La consecuencia práctica es que el reporte y la propuesta de arreglo viajan juntos y se juzgan juntos.

## Fuentes

- [No more issues](https://stitcher.io/blog/no-more-issues), Brent Roose, stitcher.io, 4 de septiembre de 2026
- [PR #285 de laravel/vapor-cli](https://github.com/laravel/vapor-cli/pull/285) y [PR #286](https://github.com/laravel/vapor-cli/pull/286), con el hilo completo del incidente y el release `v1.70.5`
- [Anuncio de Taylor Otwell en X](https://x.com/taylorotwell/status/2095516796748996843). La traducción del texto citado es mía
- Estado de `has_issues` y `has_discussions` de cada repositorio, consultado en la [API de GitHub](https://docs.github.com/en/rest/repos/repos#get-a-repository) el 4 de septiembre de 2026

---

## Sitemap

Índice completo del sitio: [/sitemap.md](https://www.angelcruz.dev/sitemap.md)

Canónico HTML: [https://www.angelcruz.dev/post/laravel-paquetes-sin-issues-solo-prs](https://www.angelcruz.dev/post/laravel-paquetes-sin-issues-solo-prs)