OOM-Vorfall: Claude Code in tmux (18. März 2026)

Stand: 19. März 2026

Was ist passiert?

Am 18. März 2026 gegen 01:13 Uhr war raspip5 nicht mehr erreichbar — weder per SSH noch per HTTP (Home Assistant, Grafana, Pi-hole). Ping funktionierte noch, weil der Linux-Kernel selbst noch lief, aber alle Anwendungen (der sogenannte „Userspace") hingen.

Ursache: Claude Code lief in einer tmux-Session und wurde nicht beendet, als die SSH-Verbindung getrennt wurde. tmux hält Prozesse absichtlich am Leben — genau dafür ist es da. Aber Claude Code (ein Node.js-Prozess) wuchs über Stunden unkontrolliert im Speicherverbrauch. Am Ende belegte der Prozess allein 5,8 GB RAM bei insgesamt nur 8 GB im System.

Da gleichzeitig 32 Docker-Container liefen, war der gesamte Arbeitsspeicher aufgebraucht — ein sogenannter Out of Memory (OOM).

Warum hat Linux das nicht verhindert?

Linux hat einen eingebauten Schutzmechanismus: den OOM-Killer. Wenn der Speicher ausgeht, beendet der Kernel den Prozess mit dem höchsten Verbrauch. Das hat auch funktioniert:

Out of memory: Killed process 19417 (claude) total-vm:74400448kB, anon-rss:5957280kB

Der OOM-Killer hat Claude Code beendet. Aber zu diesem Zeitpunkt waren andere Prozesse bereits so stark beeinträchtigt, dass das System nicht mehr reagierte. Ein Power-Cycle (Strom aus/ein) war nötig.

Warum ist Claude Code so speicherhungrig?

Claude Code basiert auf Node.js (JavaScript-Runtime). Node.js ist bekannt dafür, bei langer Laufzeit und großen Kontexten viel Speicher zu belegen. In einer interaktiven Session wächst der Speicherbedarf mit jeder Aktion — Dateien lesen, Tools aufrufen, Konversationshistorie aufbauen.

Solange man aktiv arbeitet und die Session irgendwann beendet, ist das kein Problem. Problematisch wird es, wenn Claude Code unbeaufsichtigt weiterläuft — zum Beispiel weil tmux die Session offen hält, nachdem man das iPhone weggelegt hat.

Zusammenfassung der Symptome

Was	Status während des Vorfalls
Ping (ICMP)	Funktionierte (Kernel lief)
SSH	Keine Antwort (Userspace hing)
Home Assistant (8123)	Nicht erreichbar
Grafana (3000)	Nicht erreichbar
Pi-hole DNS (53)	Nicht erreichbar
TCP-Ports	Offen (Kernel akzeptierte Verbindungen), aber keine Antwort

Typisches Bild eines OOM-Vorfalls: Kernel lebt, aber alle Anwendungen stehen still.

Gegenmaßnahmen

Regel 1: Claude Code nie unbeaufsichtigt in tmux lassen

Wenn die Arbeit unterbrochen wird (iPhone weglegen, SSH-Verbindung bricht ab): Claude Code vorher beenden (/exit oder Ctrl+C). tmux selbst kann weiterlaufen — das Problem ist nur der Claude-Prozess darin.

Regel 2: Memory-Limit setzen (Absicherung)

Falls Claude Code doch länger laufen muss, mit einem Speicher-Limit starten:

systemd-run --user --scope -p MemoryMax=3G claude

Das begrenzt den Prozess auf 3 GB RAM. Wird das Limit überschritten, beendet Linux nur diesen Prozess — das restliche System bleibt stabil. Die 3 GB sind so gewählt, dass genug Luft für die Docker-Container bleibt (8 GB gesamt, ~2 GB für Container, ~2 GB für System/Cache).

Regel 3: Bei langen Sessions `/clear` nutzen

Der Slash-Command /clear in Claude Code löscht die Konversationshistorie und gibt Speicher frei. Bei längeren Arbeitssitzungen regelmäßig nutzen — oder eine neue Session starten.

Für Einsteiger: Was bedeutet das alles?

tmux ist ein nützliches Werkzeug, das Terminal-Sessions am Leben hält (siehe 47_tmux_einrichtung.md)
Claude Code ist ein KI-Assistent, der im Terminal läuft
Die Kombination ist grundsätzlich sinnvoll — man kann die Arbeit unterbrechen und später weitermachen
Aber: Claude Code darf nicht stunden- oder tagelang unbeaufsichtigt laufen, weil der Speicherverbrauch wächst
Im schlimmsten Fall wird das gesamte System unerreichbar und muss physisch neu gestartet werden (Stecker ziehen)