Blog-Headerbild
Johannes Hoppe

Claude Code: Wie man den Endless-Scrolling-Bug wirklich löst

17.02.2026

Claude Code hat einen berüchtigten Bug: Das Terminal scrollt unkontrolliert, flackert oder friert komplett ein. Seit März 2025 sammeln sich die GitHub Issues mit tausenden Upvotes, und das Problem ist immer noch nicht behoben. Es ist das meistgemeldete UX-Problem von Claude Code überhaupt, und eine direkte Lösung von Anthropic lässt immer noch auf sich warten. In diesem Artikel erkläre ich, warum der Bug existiert, warum die üblichen Workarounds nicht helfen und wie man ihn mit einem Open-Source-Tool endgültig löst.

🇬🇧 This article is available in English language here: Claude Code: How to Actually Fix the Endless Scrolling Problem

Inhalt

Das Problem

Du arbeitest mit Claude Code und plötzlich passiert es: Das Terminal beginnt unkontrolliert zu scrollen. Du siehst keinen Text mehr, nur noch ein Rauschen aus Zeilen. Du greifst den Scrollbalken, bist ganz oben, versuchst manuell runterzuscrollen. Manchmal klappt es, manchmal nicht. Dann denkst du, es ist wieder stabil, und im selben Moment geht es schon wieder los. Es macht dich komplett aggressiv, und du kommst in der Zeit zu nichts, weil du einfach nur noch sauer bist.

⚠️ Flackerndes Video. Flickern bei der Arbeit von Johannes, aufgenommen in iTerm2

Dieses Problem ist nicht selten. Es ist das meistgemeldete und frustrierendste UX-Problem von Claude Code. Es betrifft macOS, Linux und Windows gleichermaßen. Es passiert in iTerm2, Terminal.app, VS Code, Cursor, tmux, IntelliJ und Kitty. Und es ist seit fast einem Jahr bekannt, ohne dass Anthropic eine wirkliche Lösung geliefert hat.

Auf GitHub gibt es dutzende Issues dazu, alle beschreiben dasselbe Symptom mit unterschiedlichen Namen:

In Issue #9935 hat jemand gemessen: 4.000 bis 6.700 Scroll-Events pro Sekunde.

⚠️ Flackerndes Video. Quelle: GitHub Issue #7216 – massives Scrolling in Cursor

Besonders schlimm wird es mit parallelen Agenten. Wenn Claude Code mehrere Agenten gleichzeitig startet, liefert jeder von ihnen ständig Status-Updates zurück. Der Bildschirm kommt überhaupt nicht mehr zur Ruhe, und die Claude-Session wird während der gesamten parallelen Ausführung unbenutzbar. Mehrere Issues bestätigen dieses Muster: parallele Agenten überlasten die Rendering-Pipeline komplett (#17547, #16923, #10008). Ein User, der 18 Agenten gleichzeitig laufen lässt, beschreibt es als "flicker-thrashing", sobald die Benachrichtigungen die Bildschirmhöhe überschreiten.

Was ich zuerst versucht habe (und warum es nicht geholfen hat)

Statuszeile deaktivieren

Mehrere Issues deuten darauf hin, dass die Statuszeile den Bug auslöst, wenn sie breiter als das Terminal ist. In ~/.claude/settings.json lässt sich die Statuszeile deaktivieren. Ergebnis: Der Bug tritt seltener auf, aber nicht nie. Die Statuszeile ist nur einer von mehreren Render-Pfaden, die das Problem verursachen.

Terminal breiter machen

Wenn die Statuszeile nicht umbricht, sollte der Bug verschwinden. In der Praxis flackert es auch bei 200 Spalten Breite, weil der Bug nicht nur von der Statuszeile kommt.

iTerm2 updaten

iTerm2 unterstützt Synchronized Output (dazu gleich mehr). Ein Update auf die aktuelle Version (3.6.6) bringt Verbesserungen, löst das Problem aber nicht, weil Claude Code selbst die Ursache ist.

Nicht tippen während Claude denkt

Ein häufiger Trigger ist Tastatureingabe während der "Thinking"-Phase. Sich zurückzuhalten hilft, aber wer will schon sein Verhalten an einen Bug anpassen?

Welche Terminals sind betroffen?

⚠️ Flackerndes Video. Quelle: GitHub Issue #832 – Endless Scrolling auf Windows

Die folgende Tabelle fasst die Berichte aus den verschiedenen GitHub Issues zusammen. Die Angaben zur Häufigkeit des Auftretens sind teils messbar belegt, teils subjektiv von den betroffenen Usern beschrieben.

Terminal Endless Scrolling Flickering Anmerkung
VS Code (integriert) Ja Heftig Am schlimmsten betroffen, VSCode-Crashes möglich
Cursor (integriert) Ja Heftig Gleicher xterm.js-Renderer wie VS Code
macOS Terminal.app Ja Spürbar Kein Synchronized Output
iTerm2 Ja Gelegentlich Synchronized Output vorhanden, hilft aber nicht ausreichend
tmux Ja Massiv 4.000–6.700 Scroll-Events/Sekunde gemessen
Kitty Ja Spürbar Linux und macOS
Windows CMD Ja Heftig Praktisch unbenutzbar
PowerShell Ja Heftig Auch Windows Terminal betroffen
IntelliJ IDEA Ja Spürbar Endlosschleife beim Minimieren
Ghostty Nein Nein GPU-Rendering, DEC 2026
+ claude-chill Nein Nein Funktioniert mit jedem Terminal

Warum existiert dieser Bug?

Technischer Deep-Dive: Dieser Abschnitt erklärt die Architektur hinter dem Bug. Wenn du nur die Lösung willst, springe direkt zu Die Lösung: claude-chill.

Claude Code ist eine React-Anwendung im Terminal. Die Benutzeroberfläche wird mit Ink gerendert, einer Library, die React-Komponenten in ANSI-Escape-Sequenzen übersetzt. Statt HTML-Elemente im Browser zu erzeugen, schreibt Ink Steuerzeichen in den Terminal-Stream: Cursor positionieren, Farben setzen, Zeilen löschen, Text schreiben.

Das funktioniert bei einfachen Tools gut. Bei Claude Code wird es zum Problem, weil mehrere Dinge gleichzeitig rendern:

  1. Streaming-Antworten – jedes Token löst einen Render-Zyklus aus
  2. Statuszeile – aktualisiert sich mehrmals pro Sekunde (Timer, Token-Counter)
  3. Spinner/Animationen – eigener Render-Zyklus während "Thinking"
  4. Input-Feld – rendert bei jedem Tastendruck

Jeder dieser Render-Pfade schreibt Escape-Sequenzen in den Terminal-Stream. Wenn sich Spinner, Statuszeile und Streaming-Antwort überlappen, bekommt das Terminal widersprüchliche Cursor-Positionen. Das Ergebnis: Zeilen werden an die falschen Stellen geschrieben, der Bildschirm ist korrumpiert, und jeder weitere Render verschlimmert das Chaos.

Vergleich: Browser-Rendering mit Compositor vs. Terminal-Rendering ohne Compositor

Warum hilft Synchronized Output nicht?

Synchronized Output (DEC mode 2026) ist ein Protokoll, das dem Terminal sagt: "Puffere alles zwischen Start- und End-Sequenz und zeige es atomar an." Claude Code sendet diese Sequenzen bereits (\x1b[?2026h und \x1b[?2026l). Terminals wie iTerm2 und Ghostty unterstützen sie.

Ich nutze iTerm2 seit Jahren, und ich kann bestätigen: Synchronized Output löst das Problem nicht. Synchronized Output schützt nur einzelne Updates. Wenn hunderte unkoordinierte Updates pro Sekunde kommen, die sich gegenseitig überschreiben, ist jedes einzelne zwar atomar, aber das Gesamtbild ist trotzdem kaputt. Es ist wie ein Filmprojektor, der saubere Einzelbilder zeigt, aber jedes Bild einen anderen Bildausschnitt hat.

Warum funktioniert Ghostty trotzdem?

Ghostty-User melden keine Flicker-Probleme, obwohl das Argument oben auch für Ghostty gelten sollte. Der wahrscheinliche Grund: Ghostty rendert GPU-beschleunigt und verarbeitet die Escape-Sequenzen schneller als CPU-basierte Terminals. Meine Vermutung: Die Updates sind nicht wirklich weg, aber sie werden so schnell gezeichnet, dass das menschliche Auge kein Flackern wahrnimmt. Das ist weniger "das Problem ist gelöst" und mehr "das Problem ist unsichtbar". Wenn du Ghostty mal ausprobieren willst, nur zu (ich selbst habe es nicht getestet, ich mag mein iTerm2): Neben dem flackerfreien Rendering bietet es GPU-beschleunigtes Rendering via Metal (macOS) und OpenGL (Linux), native Ligatur-Unterstützung, das Kitty Graphics Protocol für Inline-Bilder im Terminal und über 100 eingebaute Themes. Schick ist es definitiv.

Warum fixt Anthropic das nicht einfach?

Anthropic hat durchaus reagiert. In Version 2.0.10 (Oktober 2025) wurde der Renderer komplett neu geschrieben, und Ende Januar 2026 wurde der neue "Differential Renderer" für alle User ausgerollt. Chris Lloyd, Anthropic-Ingenieur und Autor der Terminal-Rendering-Patches, schrieb auf Hacker News:

"we shipped our differential renderer to everyone today. We rewrote our rendering system from scratch and only ~1/3 of sessions see at least a flicker."

Zusätzlich hat Anthropic Patches für Synchronized Output upstream eingereicht: Der Patch für VSCode (xterm.js #5453) wurde gemerged, und der Patch für tmux (#4744) wurde vom tmux-Maintainer übernommen und direkt in OpenBSD committed. Das hat die Situation verbessert, aber nicht gelöst.

Das Kernproblem ist architektonisch: React im Terminal ist ein Impedance Mismatch. Zwei Systeme, die fundamental unterschiedlich arbeiten. React geht davon aus, dass Rendering billig ist. Im Browser stimmt das: DOM-Diffing ist schnell, der Browser-Compositor sorgt für flackerfreie Darstellung. Im Terminal gibt es keinen Compositor. Jeder Render ist ein Stream von Escape-Sequenzen, und das Terminal hat keine Möglichkeit, atomare Frame-Updates zu garantieren.

Anthropic müsste React/Ink komplett rauswerfen und direkt gegen den Terminal-Buffer rendern. Das wäre ein massiver Umbau ihrer gesamten UI-Architektur. Stattdessen setzen sie darauf, dass Terminals sich anpassen (DEC 2026, GPU-Rendering). Ob diese Wette aufgeht, ist fraglich. Nach tausenden Upvotes und fast einem Jahr ist der Bug jedenfalls immer noch da.

Die Lösung: claude-chill

claude-chill ist ein Open-Source PTY-Proxy von David Beesley. Es setzt sich zwischen dein Terminal und Claude Code und macht genau das, was Claude Code selbst hätte tun sollen: sauberes Differential Rendering.

Wie es funktioniert

  1. claude-chill erstellt ein Pseudo-Terminal (PTY) und startet Claude Code darin
  2. Alle Ausgaben von Claude Code werden durch einen VT100-Emulator im Speicher geleitet
  3. Der aktuelle Bildschirmzustand wird mit dem vorherigen verglichen
  4. Nur die tatsächlichen Änderungen (Diffs) werden an dein echtes Terminal weitergegeben
  5. Die Diffs werden in Synchronized-Output-Blöcke gepackt

Statt tausender unkontrollierter Redraws pro Sekunde bekommt dein Terminal nur saubere, atomare Frame-Updates. claude-chill ist der fehlende Compositor, den Claude Code nie eingebaut hat.

claude-chill als PTY-Proxy zwischen React/Ink und dem Terminal

Installation

claude-chill wird aus dem Quellcode kompiliert, da es keine vorgebauten Binaries gibt. Dafür brauchst du den Rust-Compiler und seinen Paketmanager Cargo. Falls du noch kein Rust installiert hast, ist das in einer Minute erledigt.

Option 1: Homebrew (macOS/Linux)

Wenn du Homebrew bereits nutzt, ist das der schnellste Weg:

brew install rust

Option 2: Offizieller Rust-Installer (alle Plattformen)

Der offizielle Weg über rustup.rs funktioniert auf macOS, Linux und Windows. Das Skript installiert den Rust-Compiler (rustc), den Paketmanager (cargo) und den Toolchain-Manager (rustup):

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source ~/.cargo/env

Auf Windows statt curl den Installer von rustup.rs herunterladen und ausführen.

Prüfen, ob Cargo verfügbar ist:

cargo --version

Wenn eine Versionsnummer erscheint, kann es losgehen.

claude-chill installieren:

cargo install --git https://github.com/davidbeesley/claude-chill

Cargo lädt den Quellcode, kompiliert ihn und legt die fertige Binary unter ~/.cargo/bin/claude-chill ab. Der Kompiliervorgang dauert beim ersten Mal etwas, da alle Dependencies mitgebaut werden.

Einrichtung

Damit du nicht jedes Mal claude-chill claude tippen musst, richte einen Alias ein. Füge in die Konfigurationsdatei deiner Shell folgende Zeile ein (~/.zshrc für zsh, ~/.bashrc für bash, bei anderen Shells die jeweilige Konfigurationsdatei):

alias claude='claude-chill claude --'

Das -- am Ende ist wichtig. Es signalisiert claude-chill, dass alle folgenden Argumente (wie --resume) an Claude Code durchgereicht werden sollen.

Danach musst du die Shell neu laden:

# zsh
exec zsh

# bash
exec bash

Unter Windows schließt du das Terminal einmal und öffnest es neu.

Ab jetzt startet claude automatisch über claude-chill. Du merkst keinen Unterschied, außer dass das Flackern weg ist.

Ist claude-chill sicher?

Ich habe den gesamten Quellcode gelesen (ein kompaktes Rust-Projekt mit 12 Quelldateien). Ergebnis: Der Code ist sauber (geprüft in Version 0.1.4, Commit 2595cf7). Kein Netzwerkzugriff, keine Dateisystem-Schreibzugriffe (außer optionalem Debug-Logging), kein Zugriff auf sensible Umgebungsvariablen. Die Dependencies sind etablierte Rust-Crates: nix für POSIX-APIs, vt100 als Terminal-Emulator, termwiz (vom WezTerm-Entwickler) als Escape-Sequence-Parser. Der Code ist gut strukturiert, ausführlich getestet und hat eine explizite Whitelist/Blacklist für jede Terminal-Escape-Sequenz.

Ein großes Dankeschön an David Beesley für dieses Projekt!

Fazit

Der Endless-Scrolling-Bug in Claude Code ist ein architektonisches Problem: React/Ink im Terminal produziert mehr Updates, als das Terminal verarbeiten kann. Anthropic hat den Renderer umgeschrieben, Patches für Terminals beigesteuert und empfiehlt Ghostty. Das alles hat die Situation verbessert, aber nicht gelöst.

claude-chill löst es. Es ist ein kleiner, sauberer PTY-Proxy, der die Rolle des fehlenden Compositors übernimmt. Zwei Befehle, und der Bug ist Geschichte.

cargo install --git https://github.com/davidbeesley/claude-chill
echo "alias claude='claude-chill claude --'" >> ~/.zshrc

Weiterführende Links:

Keywords:Claude CodeEndless ScrollingInfinite ScrollTerminal FlickeringScreen FlickeringFlickerScroll BugScrolling BugTerminal RenderingUI FreezeHigh Speed Scrollingclaude-chillAnthropicTerminaliTerm2GhosttyVS Code TerminaltmuxPTY ProxySynchronized OutputDEC 2026

Zurück
Anregungen? Feedback? Fehler? Forke/bearbeite diese Seite auf GitHub.