Claude Code „court“-Endlosschleife und „Response stalled mid-stream“: Ursachen und sofortige Abhilfe

Wenn man länger mit Claude Code arbeitet, wiederholt die Antwort plötzlich immer wieder dasselbe Wort — „court court court court…", dutzende bis hunderte Male — und bricht am Ende mit „API Error: Response stalled mid-stream. The response above may be incomplete." ab. Ist Ihnen dieses Phänomen schon einmal begegnet?

Das ist kein Fehler Ihres Prompts oder Ihrer Umgebung, sondern meist die Verkettung zweier getrennter Bugs: ① eine Wiederholungsschleife (Degeneration), bei der das Modell immer wieder denselben Token ausgibt, und ② der „Response stalled mid-stream", bei dem der Stream durch diese Masse an Ausgabe oder ein Verbindungsproblem stoppt. Zu beiden existieren im offiziellen Anthropic-Repository mehrere Issues — es sind bekannte Bugs. Dieser Artikel ordnet auf Basis der offiziellen Dokumentation und realer Issues das Wesen dieser zwei Ebenen, ihre auslösenden Bedingungen, die sofortige Notbremse, die Vorbeugung für Entwickler und die Abgrenzung zu ähnlichen Fehlern.

1. Was passiert hier? — Zwei getrennte Phänomene verketten sich

Zuerst ist die Abgrenzung entscheidend. Auf dem Bildschirm sieht man „die Wiederholung von court" und „Response stalled mid-stream", doch das sind zwei Probleme auf unterschiedlichen Ebenen.

• ① Die „court"-Endlosschleife: Ein Wiederholungsphänomen, bei dem Claude (das Modell selbst) statt der beabsichtigten Antwort oder des Tool-Aufrufs immer wieder denselben Token erzeugt. Dazu gehören GitHub-Issue #68740 (Output enters an infinite loop repeating the token „court") oder #65823 (eine feste Zeichenkette wird tausendfach wiederholt und verbraucht die Ausgabe-Token restlos).
• ② „Response stalled mid-stream": Ein Fehler auf der Übertragungsseite, bei dem der Stream (die schrittweise Übertragung) der Antwort mittendrin stoppt. Er ist auch in der offiziellen Fehler-Referenz von Claude Code aufgeführt und wird auch in Issue #70840 gemeldet.

Wenn ① durchdreht, entsteht eine Masse an Ausgabe, die dann den Stream-Stopp ② auslöst — diese Verkettung erscheint auf dem Bildschirm des Anwenders als ein einziges Phänomen. Da Ursache und Abhilfe aber verschieden sind, führt das getrennte Verständnis schneller zum Ziel.

2. Die „court"-Endlosschleife — Wiederholung (Degeneration)

„court" hat keine Bedeutung. Es handelt sich um eine Variante des seit Langem bekannten Fehlermodus „Wiederholung (repetition / degeneration)", bei dem sich ein Sprachmodell an derselben Ausgabe festfährt — die Fixierung landet einfach zufällig auf dem Token „court". Es können auch andere Wörter oder Zeichenketten sein.

Gemeldete Merkmale (u. a. #68740):

• Tritt bei Modellen wie claude-opus-4-8 in der VS-Code-Erweiterung / im CLI von Claude Code auf.
• Beginnt mitten in der Sitzung und wiederholt sich innerhalb derselben Sitzung mehrfach (zustandsabhängig).
• Wird laut Meldungen besonders in Situationen ausgelöst, in denen unmittelbar vor einem Tool-Aufruf (etwa Edit) Fließtext etwa auf Japanisch erzeugt wird.
• Beim Durchdrehen wird eine Masse an Ausgabe-Token verbraucht (#65823), teils bis zur Blockade der Sitzung (#66950).

Das Label area:model (Modellverhalten) ist gesetzt, das Problem also nicht der Harness (Claude Code), sondern die Generierung auf Modellseite. Das heißt: Selbst wenn man Befehle oder Einstellungen korrigiert, lässt es sich nicht ausrotten — grundsätzlich gilt die Abhilfe „stoppen und ausweichen, sobald es passiert".

3. „Response stalled mid-stream" — der gestoppte Stream

Die andere Seite, „API Error: Response stalled mid-stream. The response above may be incomplete.", ist ein Fehler der Übertragungsseite, der auftritt, wenn der Antwort-Stream mittendrin keine Daten mehr sendet. Genau wie die Warnung „Die obige Antwort ist womöglich unvollständig" sagt, ist der bis dahin gestreamte Teil nicht verloren — es fehlen lediglich die letzten paar Sätze oder ein Tool-Aufruf.

Als Hauptfaktoren wurden gemeldet bzw. erläutert:

• Lange Antworten: Wenn die Generierung lange dauert — etwa beim Lesen mehrerer großer Dateien und dem Erstellen eines strukturierten Berichts —, tritt der Fehler leichter auf. Auch die Masse an Ausgabe durch das court-Durchdrehen fällt darunter.
• Instabile Netzwerk-/Verbindung: Bei grenzüberschreitenden Verbindungen, privaten Heimanschlüssen, über tmux-Sitzungen usw. steigt die Wahrscheinlichkeit.
• Fehlender Lese-Timeout: Der Hinweis, dass der Client endlos wartet, wenn die vorgelagerte API das Senden von Paketen einstellt (Issue #70840).

Der sehr ähnliche „Connection closed mid-response" (die Verbindung wurde mitten in der Antwort geschlossen) (#69415) ist übrigens ein anderer Fehler: Hier „stoppt" der Stream nicht, sondern wird „getrennt". Die Symptome ähneln sich, dieser liegt aber näher am Verbindungsabbruch.

4. Anders als das „court/invoke-Tag-Leck" — so unterscheidet man sie

Man verwechselt es leicht, doch das Phänomen dieses Artikels, „court läuft in einer Endlosschleife", und das Phänomen „court leckt zusammen mit invoke-Tags auf den Bildschirm", sind verschiedene Dinge. Letzteres behandelt ein anderer Artikel auf unserer Website ausführlich.

Für den Typ, bei dem „court" zusammen mit Tags leckt und der Tool-Aufruf nicht zündet, siehe Ursache und Abhilfe für den Fehler, bei dem Claude Code „court" oder invoke-Tags ausgibt. Ursache und Abhilfe unterscheiden sich teilweise.

5. Auslösende Bedingungen

Für beide Phänomene ist keine Reproduktionsbedingung bekannt, unter der sie „garantiert auftreten". Aus den Meldungen zeichnen sich jedoch gemeinsame Faktoren ab, die die Wahrscheinlichkeit erhöhen.

6. Sofort beheben (für Anwender)

Da sich die Wiederholung auf Modellseite nicht per Einstellung ausrotten lässt, ist „schnell stoppen und den Zustand zurücksetzen" am zuverlässigsten. Die Reihenfolge ist wie folgt.

1. Sofort stoppen (Esc): Sobald Sie eine Schleife oder einen Hänger bemerken, brechen Sie die Generierung mit Esc ab. So stoppen Sie die Verschwendung von Ausgabe-Token.
2. In eine neue Sitzung ausweichen: Da der Bug zustandsabhängig ist, verschwindet er meist, wenn Sie eine neue Sitzung starten. Erneute Versuche in derselben Sitzung fallen leicht rückfällig.
3. Mit /clear den Kontext zurücksetzen: Wenn Sie die Sitzung fortsetzen möchten, leeren Sie den Kontext, um den Zustand zu entlasten (/compact übernimmt den Zustand, weshalb die Behebung unsicher ist).
4. Tool-Aufrufe ohne Vorrede: Es gibt Meldungen, dass man die Schleife leichter vermeidet, wenn man vor Edit u. Ä. keinen langen Text schreiben lässt, sondern das Tool ohne jede Vorrede aufruft.
5. Aufgaben in kurze Sitzungen aufteilen: Hält man mit „eine Aufgabe = eine Sitzung" Generierungsdauer und Kontext kurz, treten sowohl Wiederholung als auch Stream-Stopp seltener auf.
6. Die Verbindung stabilisieren: Häuft sich stalled, überprüfen Sie die Stabilität von Leitung und Proxy-Route. Der bereits gestreamte Inhalt bleibt erhalten, Sie können also einfach ab der Stelle weiterarbeiten.

✅ Merke: „Zweimal daneben — nicht verbeißen, ab in eine neue Sitzung." Versucht man es im selben kaputten Zustand erneut, ahmt das Modell leicht die vorherige Wiederholung nach und fällt rückfällig.

7. Für Entwickler — mit API/SDK vorbeugen

Wenn Sie mit der Messages API oder dem SDK selbst implementieren, können Sie den Schaden mit folgenden Maßnahmen begrenzen.

• Einen Lese-Timeout für das Streaming setzen: Kommt über einen bestimmten Zeitraum kein Paket, abbrechen und erneut versuchen. So vermeiden Sie endloses Warten (Gegenmaßnahme gegen die Grundursache von stalled).
• Wiederholungserkennung als Schutz: Wenn in der jüngsten Ausgabe derselbe Token / eine kurze Zeichenkette abnorm oft wiederholt wird, die Generierung abbrechen. Das verhindert den ausufernden Verbrauch von Ausgabe-Token.
• Unvollständige Antworten erneut versuchen: stop_reason prüfen und bei einem vorzeitigen Ende neu starten, ohne die kaputte Ausgabe im Verlauf zu belassen (ein kaputter Verlauf löst im nächsten Turn eine Wiederholung aus).
• Ein Obergrenze für max_tokens setzen: Damit sich selbst im Fall des Durchdrehens die Obergrenze für Kosten und Zeit ziehen lässt.
• Tool-Argumente und Vorreden kurz halten: Lange Argumente und lange Vorreden können auslösende Bedingungen sein.

8. Abgrenzung zu ähnlichen Fehlern

9. Offizieller Bearbeitungsstand

Hier der Stand von Juli 2026, mit ausdrücklicher Angabe der Sicherheit.

• ✅ Als bekannter Bug erkannt: Sowohl zur court-Wiederholung als auch zu stalled existieren im offiziellen Anthropic-Repository mehrere Issues, und die court-Wiederholung trägt die Labels area:model und bug.
• 🟡 Dauerhafte Behebung nicht bestätigt: Zum Zeitpunkt der Erstellung dieses Beitrags ist kein offizieller Fix bestätigt, von dem man sagen könnte „damit ist es behoben". Da eine Verbesserung durch Versions-Updates möglich ist, sollte man Claude Code auf dem neuesten Stand halten.
• 🟡 Ursache zustands- und umgebungsabhängig: Mehrere Faktoren wie lange Laufzeit, großer Kontext und Verbindungsqualität spielen zusammen; eine einzelne Reproduktionsanleitung ist nicht identifiziert.

※ Die Lage kann sich ändern. Den aktuellen Stand bitte in der Issue-Liste von Claude Code und der offiziellen Fehler-Referenz prüfen.

FAQ

F1. Hat „court" irgendeine Bedeutung?

Nein. Es ist die „Wiederholung (Degeneration)", bei der sich das Sprachmodell an derselben Ausgabe festfährt — die Fixierung landet einfach zufällig auf dem Token „court". Es können auch andere Wörter oder Zeichenketten sein. Es liegt nicht an Ihrem Prompt oder Ihren Daten.

F2. Geht die bisherige Ausgabe verloren, wenn „Response stalled mid-stream" erscheint?

Nein. Es ist genau wie die Meldung sagt, nur „die obige Antwort ist womöglich unvollständig" — der bis dahin gestreamte Inhalt bleibt erhalten. Da die letzten paar Sätze oder ein Tool-Aufruf fehlen können, arbeiten Sie einfach ab der Stelle weiter.

F3. Ist es sofort behoben, wenn ich es erneut versuche?

Bei leichten Fällen kann es sich beheben, aber ein erneuter Versuch in derselben Sitzung fällt leicht rückfällig. Denn das Modell ahmt die unmittelbar vorherige kaputte Ausgabe (die Wiederholung) nach. Nach zweimal daneben ist es zuverlässiger, sich nicht zu verbeißen und auf eine neue Sitzung umzustellen.

F4. Ist es behoben, wenn ich /compact mache?

Unsicher. Da /compact den Kontext zusammenfasst und den Zustand übernimmt, kann die Ursache der Wiederholung bestehen bleiben. Wollen Sie den Zustand zurücksetzen, sind /clear oder eine neue Sitzung zuverlässiger.

F5. Ist das derselbe Bug wie das „court/invoke-Tag-Leck" aus dem Artikel?

Verwandt, aber verschieden. Dieser Artikel behandelt den Wiederholungs- und Stream-Stopp-Typ, „court läuft in einer Endlosschleife und stoppt am Ende mit stalled". Der Tag-Leck-Typ ist „einige wenige court oder rohe invoke-Tags lecken durch und der Tool-Aufruf zündet nicht"; Näheres siehe anderer Artikel.

F6. Wie beugt man als Entwickler grundlegend vor?

Wirksam sind drei Punkte: einen Lese-Timeout für das Streaming setzen, mit Wiederholungserkennung abnorme Wiederholungen abbrechen und bei vorzeitigem Ende ohne die kaputte Ausgabe im Verlauf erneut versuchen. Auch eine Obergrenze für max_tokens verhindert das Ausufern von Kosten und Zeit.

F7. Wann tritt es besonders leicht auf?

Die Wahrscheinlichkeit steigt bei durchgehenden Sitzungen über mehrere Stunden bis Tage, schwerem Kontext von hunderttausenden bis rund einer Million Token, langem Fließtext unmittelbar vor einem Tool-Aufruf, instabilen Verbindungen (grenzüberschreitend, Heimanschluss, über tmux) sowie Aufgaben mit langer Ausgabe. Vorbeugend hilft, mit „eine Aufgabe = eine Sitzung" alles kurz zu halten.

Verwandte Artikel

• Der Fehler, bei dem Claude Code „court" oder invoke-Tags ausgibt — Tag-Leck-Typ (anders als dieser Artikel)
• Ursache und Abhilfe für Output blocked by content filtering policy — Fehler des Filters auf der Ausgabeseite
• Was ist der /loop-Befehl von Claude Code — die richtige Verwendung wiederholter Ausführung