Accueil / Quand ça déraille

Plusieurs sessions meurent ensemble, soupçonnez la machine

Quand plusieurs sessions meurent au même instant sans aucune trace dans leurs propres journaux, la cause probable est le système d'exploitation qui tue des processus sous pression mémoire, et le journal système tranche plus vite qu'une chasse aux erreurs applicatives.

Une session Claude Code s'arrête net, sans message d'erreur exploitable dans son propre journal. Ce n'est pas inquiétant en soi. Ce qui doit faire changer de piste, c'est quand deux ou trois sessions distinctes s'arrêtent au même instant, sur la même machine, sans lien de dépendance entre elles. Un bug propre à l'outil frapperait rarement plusieurs processus indépendants à la seconde près. Un système d'exploitation qui manque de mémoire, si.

Le tueur de mémoire, une couche sous l'outil

Sur Linux, quand la mémoire disponible tombe trop bas, le noyau déclenche un mécanisme appelé OOM killer, pour out of memory killer : il choisit un ou plusieurs processus et les termine de force pour éviter que la machine entière ne se bloque. Le processus tué ne reçoit généralement aucune chance d'écrire un message d'erreur avant de disparaître, ce qui explique l'absence totale de trace dans son propre journal. Windows n'a pas d'équivalent qui tue un processus de cette façon : son détecteur d'épuisement de ressources, visible dans l'observateur d'événements sous l'identifiant Microsoft-Windows-Resource-Exhaustion-Detector, se contente de journaliser l'événement 2004 en nommant les processus qui consommaient le plus de mémoire virtuelle au moment de la mesure. Cette entrée suffit à dater une pression mémoire réelle sur la machine, mais elle diagnostique, elle ne tranche pas seule ce qui a arrêté un processus. Dans les deux cas, la piste sort de Claude Code : elle se situe une couche plus bas, là où l'outil n'a ni visibilité ni contrôle.

Le journal système tranche avant le journal applicatif

Chercher la cause dans les journaux de l'application prend du temps et ne trouvera rien si la cause est ailleurs. Le journal système, lui, enregistre l'événement au moment où il se produit, indépendamment de ce que faisait chaque processus tué. C'est donc lui qu'il faut lire en premier, pas en dernier recours.

# Fabrique un journal d'exemple, sans toucher au vrai journal système
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' > journal-exemple.log

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

Sur un vrai poste, la commande équivalente est dmesg -T | grep -i killed sur Linux, ou une lecture du journal Système dans l'observateur d'événements Windows à la recherche d'un événement de détection de ressources épuisées. Les deux horodatages identiques sur les deux processus tués, comme dans l'exemple fabriqué ci dessus, sont la signature qui distingue une purge mémoire d'une coïncidence.

Le correctif porte sur la machine, pas sur l'usage

Une fois la purge confirmée, la réponse naturelle, réduire le nombre de sessions ouvertes en parallèle, traite le symptôme sans régler la cause. Le fichier d'échange, aussi appelé swap, sert justement à absorber les pics de mémoire sans tuer de processus : le dimensionner correctement, ou en ajouter un absent, évite la prochaine purge sans imposer de discipline artificielle sur le nombre de fenêtres ouvertes.

Cette même discipline, vérifier la couche la plus basse avant d'incriminer l'outil, structure aussi le geste devant une commande qui ne répond plus, voir une commande bloquée.