Home / When things go wrong

Several sessions die together, suspect the machine

When several sessions die at the same instant with no trace whatsoever in their own logs, the likely cause is the operating system killing processes under memory pressure, and the system log settles the question faster than a hunt through application errors.

A Claude Code session stops dead, with no usable error message in its own log. That is not worrying in itself. What should prompt a change of track is when two or three separate sessions stop at the same instant, on the same machine, with no dependency between them. A bug specific to the tool would rarely strike several independent processes to the second. An operating system running short of memory would.

The memory killer, a layer beneath the tool

On Linux, when available memory drops too low, the kernel triggers a mechanism called the OOM killer, for out of memory killer: it picks one or more processes and terminates them by force to stop the whole machine from locking up. The killed process generally gets no chance to write an error message before it disappears, which explains the total absence of any trace in its own log. Windows has no equivalent that kills a process this way: its resource exhaustion detector, visible in Event Viewer under the identifier Microsoft-Windows-Resource-Exhaustion-Detector, simply logs event 2004, naming the processes that were consuming the most virtual memory at the time of the measurement. This entry is enough to date a genuine memory pressure event on the machine, but it is diagnostic, it does not on its own settle what stopped a process. In both cases, the trail leads outside Claude Code: it sits one layer down, where the tool has neither visibility nor control.

The system log settles it before the application log does

Looking for the cause in the application's logs takes time and will find nothing if the cause lies elsewhere. The system log, by contrast, records the event the moment it happens, independently of what each killed process was doing. It is therefore the one to read first, not as a last resort.

# Builds a sample log, without touching the real system log
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

On a real machine, the equivalent command is dmesg -T | grep -i killed on Linux, or a read of the System log in Windows Event Viewer looking for a resource exhaustion detection event. The two identical timestamps on the two killed processes, as in the fabricated example above, are the signature that distinguishes a memory purge from a coincidence.

The fix targets the machine, not the usage

Once the purge is confirmed, the natural response, reducing the number of sessions kept open in parallel, treats the symptom without addressing the cause. The swap file exists precisely to absorb memory spikes without killing processes: sizing it correctly, or adding one where none exists, prevents the next purge without imposing artificial discipline on the number of windows left open.

This same discipline, checking the lowest layer before blaming the tool, also structures the approach to a command that stops responding, see a stuck command.