Inicio / Cuando algo falla

Varias sesiones mueren juntas, sospecha de la máquina

Cuando varias sesiones mueren en el mismo instante sin ningún rastro en sus propios registros, la causa probable es el sistema operativo que mata procesos bajo presión de memoria, y el registro del sistema resuelve la duda más rápido que una caza de errores de la aplicación.

Una sesión de Claude Code se detiene en seco, sin ningún mensaje de error útil en su propio registro. Esto no es preocupante en sí mismo. Lo que debe hacer cambiar de pista es cuando dos o tres sesiones distintas se detienen en el mismo instante, en la misma máquina, sin ninguna relación de dependencia entre ellas. Un fallo propio de la herramienta rara vez golpearía a varios procesos independientes con precisión de segundo. Un sistema operativo que se queda sin memoria, sí.

El asesino de memoria, una capa por debajo de la herramienta

En Linux, cuando la memoria disponible cae demasiado bajo, el núcleo activa un mecanismo llamado OOM killer, por out of memory killer: elige uno o varios procesos y los termina por la fuerza para evitar que toda la máquina se bloquee. El proceso eliminado generalmente no recibe ninguna oportunidad de escribir un mensaje de error antes de desaparecer, lo que explica la ausencia total de rastro en su propio registro. Windows no tiene un equivalente que mate un proceso de esta manera: su detector de agotamiento de recursos, visible en el visor de eventos bajo el identificador Microsoft-Windows-Resource-Exhaustion-Detector, se limita a registrar el evento 2004 nombrando los procesos que más memoria virtual consumían en el momento de la medición. Esta entrada basta para fechar una presión de memoria real en la máquina, pero diagnostica, no resuelve por sí sola qué detuvo un proceso. En ambos casos, la pista queda fuera de Claude Code: se sitúa una capa más abajo, donde la herramienta no tiene ni visibilidad ni control.

El registro del sistema resuelve la duda antes que el registro de la aplicación

Buscar la causa en los registros de la aplicación lleva tiempo y no encontrará nada si la causa está en otro lugar. El registro del sistema, en cambio, guarda el evento en el momento en que se produce, con independencia de lo que estuviera haciendo cada proceso eliminado. Por eso es el que hay que leer primero, no como último recurso.

# Fabrica un registro de ejemplo, sin tocar el registro real del sistema
printf '2026-09-02T03:14:07 kernel: Out of memory: Killed process 4821 (node) total-vm:2048000kB\n2026-09-02T03:14:07 kernel: Out of memory: Killed process 4822 (node) total-vm:1980000kB\n' > registro-ejemplo.log

grep -i "out of memory" registro-ejemplo.log
# Out of memory: Killed process 4821 (node) total-vm:2048000kB
# Out of memory: Killed process 4822 (node) total-vm:1980000kB

En un equipo real, el comando equivalente es dmesg -T | grep -i killed en Linux, o una lectura del registro Sistema en el visor de eventos de Windows buscando un evento de detección de recursos agotados. Las dos marcas de tiempo idénticas en los dos procesos eliminados, como en el ejemplo fabricado arriba, son la firma que distingue una purga de memoria de una coincidencia.

La corrección recae sobre la máquina, no sobre el uso

Una vez confirmada la purga, la respuesta natural, reducir el número de sesiones abiertas en paralelo, trata el síntoma sin resolver la causa. El archivo de intercambio, también llamado swap, sirve precisamente para absorber los picos de memoria sin matar ningún proceso: dimensionarlo correctamente, o añadir uno ausente, evita la próxima purga sin imponer una disciplina artificial sobre el número de ventanas abiertas.

Esta misma disciplina, verificar la capa más baja antes de culpar a la herramienta, estructura también el gesto ante un comando que deja de responder, ver un comando bloqueado.