Estás trabajando y, de golpe, Claude Desktop se congela y todas las sesiones de Claude Code que tenías abiertas mueren a la vez. Fuerzas el cierre, intentas reiniciar y a veces te encuentras con que la aplicación ya ni siquiera arranca. Cuando pasa esto, la última línea del log suele ser siempre la misma.
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }Este artículo aclara qué significa ese exitCode 101457950 (es decir, 0x060C201E), por qué se lleva por delante incluso a sesiones que no tienen nada que ver, y qué medidas se pueden tomar de verdad y cuáles no.
⚠️ Etiquetas de fiabilidad de este artículo: ✅ Confirmado = queda registrado en una incidencia pública o medido en el equipo del autor / 🟡 Reportado = hay varios reportes, pero ninguna confirmación oficial / 🔴 Sin confirmar = no se puede afirmar. Anthropic no ha publicado sobre este síntoma ni una explicación oficial de la causa ni un aviso de corrección (según lo comprobado a 15 de agosto de 2026).
Una sola pestaña arrastra a todas las sesiones
— porque el proceso GPU es un recurso compartido del que solo hay uno por aplicación
1. Conclusión: no falla Claude Code, falla el recipiente
Empecemos por separar las cosas. Aunque tengas la sensación de que «se ha caído Claude Code», lo que se cae no es Claude Code (la CLI). Lo que se cae es el proceso GPU de la aplicación de escritorio (Electron) que lo aloja.
✅ Confirmado: comprobarlo es fácil, basta con mirar el final de %APPDATA%\Claude\logs\main.log. Si la línea inmediatamente anterior al reinicio es GPU process gone, es este caso. El log se corta ahí y la línea siguiente ya es Starting app.
Y lo importante es que lo que se pierde son procesos, no datos. El historial de conversaciones y las transcripciones se escriben en disco, así que, tras reiniciar, puedes volver a abrir la sesión y seguir leyendo desde donde estabas. El trabajo que estuviera en ejecución es otra historia, y lo retomamos en §6.
2. El síntoma: no «se cierra», se «congela»
Lo más incómodo de este fallo es que la aplicación no desaparece: se queda ahí, sin responder. No sale ningún diálogo de error ni se reinicia sola. Se queda congelada hasta que el usuario se da cuenta y fuerza el cierre.
En el equipo del autor (Windows 11 / RTX 2080 Ti / 32GB de RAM), en las tres ocasiones observadas el 14 de agosto de 2026, el intervalo más largo entre la muerte del proceso GPU y el cierre forzado fue de unos 30 minutos. Durante todo ese tiempo, las 8 sesiones abiertas siguieron detenidas.
Tres formas de reconocerlo
- No cae una, caen todas: si solo se detuvo una sesión, la causa es otra. Si varias sesiones se reinician dentro del mismo minuto, lo que se ha caído es la aplicación
- El log se corta a media escritura: en un cierre normal siguen las líneas del proceso de salida. Aquí se detiene incluso la escritura justo después de
GPU process gone - No hay volcados: si no han aparecido volcados nuevos en
%APPDATA%\Claude\Crashpad\, no es una caída nativa del lado de la CLI
3. Por qué arrastra incluso a sesiones que no tienen nada que ver
Aquí está el fondo del asunto, y también la razón por la que no es algo que se pueda resolver con ajustes.
Electron (Chromium) concentra el renderizado en un proceso dedicado: el proceso GPU. Y de ese proceso solo existe uno por aplicación. Todas las ventanas, todas las pestañas y todas las sesiones lo comparten.
Es decir: si una sola página abierta en el navegador integrado mata el proceso GPU, se lleva por delante al mismo tiempo a sesiones que no tienen ninguna relación con esa página. No hay aislamiento por pestaña ni por sesión. ✅ Confirmado: así está diseñado el modelo de procesos de Chromium, y el usuario no puede aislarlo desde los ajustes.
Un único proceso GPU, compartido por todo
4. El detonante: el navegador integrado es el más frecuente, pero no el único
✅ Confirmado: el detonante más frecuente en las incidencias públicas es el navegador integrado (el panel de navegador). #80444 registra cómo el proceso GPU muere entre 15 y 36 segundos después de que una página abierta en una pestaña del navegador ejecutara la detección de capacidades de WebGL/WebGPU, y las cuatro veces con el mismo 0x060C201E.
#82967 es aún más concreto y sitúa el detonante en la captura de pantalla para la vista previa de la herramienta de navegador (capturePreviewScreenshotIfChanged). #83478 informa de que se reproduce «dejando abierta una vista previa que se actualiza continuamente».
🟡 Reportado: ahora bien, el navegador no es el único detonante. #68049 informa de caídas al arrancar con el mismo exitCode en un entorno ARM64, sin que medie ninguna operación de navegador. #83028 dice que se reproduce con la GPU integrada de Intel. No se puede afirmar que «si no usas el navegador no ocurre nunca».
💡 Medición en el equipo del autor (no generalizable): investigando herramientas de IA, la operación de abrir cuatro páginas seguidas en el navegador integrado con uno o dos segundos de intervalo se repitió unas 18 veces el mismo día, y en 3 de ellas murió el proceso GPU. No se cae siempre: solo se cae cuando se junta una combinación de páginas pesadas. Es la observación de un único equipo, así que la frecuencia en sí no se puede trasladar a otros entornos.
5. Confirmarlo con los logs
Sin quedarse en suposiciones: con tres archivos se puede confirmar. Conviene saber, además, que el directorio ~/.claude/logs no existe.
| Qué mirar | Ruta | Criterio |
|---|---|---|
| La aplicación en sí | %APPDATA%\Claude\logs\main.log | Si la línea inmediatamente anterior al reinicio es GPU process gone, es este caso |
| La ventana del navegador | %APPDATA%\Claude\logs\unknown-window.log | Si a la misma hora aparece CONTEXT_LOST_WEBGL, también desde el lado del renderizado se ve que la GPU se ha caído |
| Caídas nativas | %APPDATA%\Claude\Crashpad\ | Si no han aparecido volcados nuevos, no es un fallo del lado de la CLI |
⚠️ El aviso de requestAdapter que sale en ese mismo log no es el culpable. La línea «The powerPreference option is currently ignored when calling requestAdapter() on Windows.» no es un indicio de caída, sino un mensaje normal de Chromium que informa de que en Windows powerPreference no surte efecto (Chrome for Developers / Chromium issue 40268366). Aparece en cuanto abres una página que usa WebGPU, se caiga o no. No tomes su mera presencia como fundamento de nada.
El exitCode permite distinguir un cierre normal. Aunque todos sean «cierres», no significan lo mismo, y conviene perseguir solo lo que hay que perseguir.
| exitCode | Hexadecimal | Significado |
|---|---|---|
101457950 | 0x060C201E | La firma de este caso. Lo que hay que perseguir |
-1073741205 | 0xC000026B | Al cerrar sesión o apagar el equipo. Normal |
1073807364 | 0x40010004 | Cierre intencionado. Normal |
6. Recuperación: cuándo [Reparar] devuelve la aplicación y cuándo no
Si fuerzas el cierre y reinicias, lo habitual es que puedas seguir usándola sin más. El problema es cuando, al intentar reiniciar, resulta que la aplicación ya no arranca.
✅ Confirmado: después de la caída de la GPU, Windows puede considerar que el paquete MSIX «ha sido modificado» y negarse a iniciarlo. #80444 lo registra como appxState=2 (Modified) e informa de que pudo recuperarlo todas las veces con Configuración → Aplicaciones → Claude → Opciones avanzadas → [Reparar]. #81836 dice igualmente que con [Reparar] vuelve.
Lo que viene a continuación es, creo, la parte más útil de este artículo. También hay reportes en los que [Reparar] no funciona. #82967 tenía el paquete en estado Modified, NeedsRemediation e informa de que [Reparar] fallaba siempre y solo se recuperó desinstalando por completo y reinstalando.
El orden a seguir cuando ya no arranca
- Termina los procesos residentes: si siguen reteniendo archivos, [Reparar] se rechaza alegando que la aplicación está en ejecución
- [Reparar]: Configuración → Aplicaciones → Aplicaciones instaladas → Claude → Opciones avanzadas. Los datos se conservan
- Si aun así no va, desinstalar y volver a instalar (habrá que iniciar sesión de nuevo)
El detalle del procedimiento, y si se pierden o no el historial de conversaciones y las sesiones, está recogido en el procedimiento de reparación de «No se puede abrir esta aplicación».
Sobre los datos. Las transcripciones se quedan en disco, así que puedes releerlas tras reiniciar. Ahora bien, #81698 informa de que «perdí de golpe todo el trabajo que estaba en marcha; también desaparecieron los resultados de los subagentes que corrían en paralelo». Lo guardado se queda, pero lo que estaba en ejecución no vuelve: conviene tener clara esa distinción.
7. Lo que puedes hacer y lo que no
Por desgracia, no hay ninguna solución de fondo. Lo único posible es poner más difícil que se apriete el gatillo y, como además circulan medidas de las que se informa que no sirven, las separo.
- No abrir páginas pesadas en el navegador integrado. Llévalas a un navegador de verdad
- No abrir muchas páginas de golpe. Deja intervalo entre una y otra
- No dejar una vista previa abierta indefinidamente (la condición de reproducción de #83478)
- Desactivar la propia función de navegador: es la vía de escape que menciona #82967. Pero eso solo detiene lo que provoca el navegador y no sirve contra la variante que se cae al arrancar (#68049)
- No acumular trabajos largos en una sola sesión. La relectura tras la recuperación sale más ligera
--disable-gpuno se puede usar: en la versión MSIX lo rechaza con «Acceso denegado» (#82967)- Actualizar la aplicación no lo arregla: en el equipo del autor volvió a ocurrir con la versión posterior a la actualización
- Aislar el proceso GPU: no se puede por arquitectura (§3)
- Cambiar la planificación de GPU o los ajustes del controlador: #82967 informa de haber probado varias cosas sin efecto
🟡 Reportado: si usas una GPU híbrida (una configuración que alterna entre la integrada y la dedicada), fijar la GPU preferida para Claude en Configuración → Sistema → Pantalla → Gráficos de Windows merece la pena probarlo. El fundamento está del lado de Chromium: en Windows, indicar la GPU mediante powerPreference no surte efecto, porque Chrome todavía no sabe repartir el trabajo entre dos GPU y componer el resultado; se sigue en Chromium issue 40268366. Es decir, la aplicación no puede fijar con cuál de las dos GPU se dibuja, así que, si lo quieres fijar, no queda más remedio que recurrir a los ajustes del sistema. Eso sí, no se ha encontrado ningún reporte de que esto haya funcionado en este caso concreto, así que no te hagas demasiadas ilusiones.
8. Otro fenómeno que se confunde con este: el cierre forzado por la actualización de la Store
La versión de Microsoft Store (MSIX) tiene desactivada la autoactualización propia de la aplicación. En su lugar, es la Store la que fuerza el cierre de la aplicación en marcha para sustituirla. Como la aplicación desaparece de golpe mientras trabajas, es fácil confundirlo con una caída de la GPU.
Los logs los distinguen sin ambigüedad. En una actualización de la Store queda la línea Windows session ending (close-app) y no aparece GPU process gone. Si en el siguiente arranque la versión ha cambiado, queda confirmado.
Esto no se puede evitar, así que la única mitigación es dejar las actualizaciones hechas antes de meterte en un trabajo largo.
Resumen
- Qué es en realidad: no un fallo de Claude Code, sino una caída del proceso GPU de la aplicación de escritorio (
exitCode 101457950/0x060C201E) - Por qué caen todas: el proceso GPU es un recurso compartido del que solo hay uno por aplicación. Una sola pestaña arrastra a todas las sesiones. No se puede aislar con ajustes
- Detonante: el navegador integrado es el más frecuente. Pero también hay reportes de caídas al arrancar, así que no es el único
- Cómo confirmarlo: mira en
main.logla línea inmediatamente anterior al reinicio. Si diceGPU process gone, es este caso - Recuperación: forzar el cierre y reiniciar. Si ya no arranca, [Reparar]. Hay reportes que llegan a un punto en el que [Reparar] no funciona
- Datos: lo guardado se queda, pero el trabajo en ejecución no vuelve
- No hay ningún aviso oficial de corrección (a 15 de agosto de 2026)
Preguntas frecuentes
P. ¿Se borra el historial de conversaciones?
R. No se borra. Las transcripciones se escriben en disco, así que puedes volver a abrirlas tras reiniciar. Ahora bien, el trabajo que estuviera corriendo en el instante de la caída sí se pierde: hay un reporte de que desaparecieron incluso los resultados de los subagentes que iban en paralelo (#81698).
P. ¿Se arregla actualizando la aplicación?
R. No necesariamente. En el equipo del autor volvió a ocurrir con la misma firma en la versión posterior a la actualización. Eso sí, #80444 lo reporta como una regresión aparecida a partir de cierta versión, así que es posible que según la versión salga con más o menos facilidad.
P. ¿Se arregla actualizando el controlador de la GPU?
R. Es una medida débil. Si la causa estuviera en la capa del controlador, el registro del sistema de Windows anotaría un TDR (evento con ID 4101), pero en el equipo del autor no salió ni uno en 30 días. #68049 también informa de que el problema reapareció después de actualizar el controlador y de hacer una reinstalación limpia.
P. ¿No será falta de memoria o transcripciones demasiado grandes?
R. En el equipo del autor ambas hipótesis quedaron descartadas. En el momento de la caída, el total de todos los procesos de Electron era de unos 1,7GB y la memoria libre, 14,8GB de 31,9GB. Había incluso sesiones con transcripciones que habían crecido hasta 98,5MB, pero no había correlación con la hora de las caídas.
P. ¿Es lo mismo cuando solo se detiene una sesión?
R. No. Aquí se congela la aplicación entera, así que siempre es del tipo «caen todas». Si solo cae una, sospecha de otra causa. Si lo único que pasa es que la respuesta se corta a medias, entra en la familia de Connection closed mid-response o response stalled mid-stream.
Artículos relacionados
- Claude Desktop «No se puede abrir esta aplicación»: cómo repararlo (la limpieza posterior a este fallo)
- «Hay otro programa que está usando este archivo en este momento» (0x80070020) (otro problema distinto: no arranca tras actualizar)
- Recopilación de errores de Claude Code
