Inhalt
- 1. Was die Meldung wirklich bedeutet — die offizielle Definition
- 2. Das Erste, was zu tun ist — nichts ist verloren
- 3. Warum es abreißt — die drei Ebenen, auf denen die Verbindung schließt
- 4. Was Paketmitschnitte zeigten: ein Schließen vom Server aus
- 5. Prüfen Sie Ihre Version — die Chronologie der Fixes
- 6. Bedingungen, die es wahrscheinlicher machen
- 7. Sofort beheben — Checkliste für Anwender
- 8. Für Entwickler — Vorbeugung auf API-/SDK-Ebene
- 9. Abgrenzung zu ähnlichen Fehlern
- 10. Offizieller Stand und was noch offen ist
- Häufige Fragen
Sie arbeiten in Claude Code, und mitten in einer Antwort bleibt alles bei dieser Zeile stehen:
API Error: Connection closed mid-response. The response above may be incomplete.
Es kann beim Schreiben eines langen Berichts passieren, beim Lesen mehrerer Dateien oder direkt nach dem Start einer neuen Sitzung. Der Zeitpunkt variiert, und es gibt keinen verlässlichen Weg, das Verhalten zu reproduzieren. Das ist kein Problem Ihrer Prompt-Formulierung, sondern ein Ereignis der Transportschicht: Die Verbindung, die die gestreamte Antwort transportierte, wurde geschlossen, während die Antwort noch ankam.
Und ein Umstand wiegt schwerer als jede Vermutung. Die meisten öffentlichen Meldungen zu diesem Fehler stammen aus Versionen, die vor der Umstellung des Umgangs mit abgebrochenen Verbindungen in Claude Code erschienen sind. Wer das offizielle Changelog durchgeht, findet ab 2.1.179 fünf eigenständige Korrekturen rund um Verbindung und Wiederholungsversuche. Dieser Artikel stützt sich ausschließlich auf die offizielle Fehlerreferenz, das offizielle Changelog und Issues mit Paketmitschnitten und behandelt (1) die genaue Bedeutung der Meldung, (2) was jetzt zu tun ist, (3) wo die Verbindung tatsächlich schließt, (4) was sich zwischen den Versionen geändert hat und (5) wie man als Entwickler vorbeugt.
Alles bereits Übertragene ist unversehrt. Der dokumentierte Weg zum Fortsetzen ist die Antwort continue.
2.1.198 verhinderte, dass kurze Netzabbrüche den ganzen Zug kippen; 2.1.214 verhinderte, dass Wiederholungen eine tote Verbindung weiterverwenden.
Ihr Rechner, der Weg (Proxy/VPN) oder die Serverseite — jede Ebene verlangt eine andere Antwort. Vom Server ausgelöste Schließungen wurden gemeldet.
1. Was die Meldung wirklich bedeutet — die offizielle Definition
Zunächst: Dieser Text ist ein Hinweis, den Claude Code selbst schreibt, keine Fehlerantwort der API. Die offizielle Fehlerreferenz von Claude Code erklärt die gesamte Familie der Meldungen, die auf „The response above may be incomplete." enden, so: Wenn eine gestreamte Antwort scheitert, nachdem Claude bereits sichtbare Ausgabe erzeugt hat, könnte ein erneutes Senden dieselben Tool-Aufrufe zweimal ausführen; deshalb behält Claude Code das bereits Übertragene und hängt diesen Hinweis an, statt den Zug zu verwerfen.
Das Satzende ist dann der Name der Ursache. Die Referenz nennt drei Varianten.
Die offizielle Erklärung passt in eine Zeile: Die Verbindung ist abgebrochen. Der Stream lief, doch die tragende Verbindung wurde geschlossen.
Offiziell: Der Stream hat aufgehört, Daten zu senden. Die Verbindung lebt, verstummt aber. Kein Abriss, sondern Stillstand.
Ein Überlast- oder 5xx-Fehler mitten im Stream. Laut Dokumentation setzt diese Variante v2.1.199 oder neuer voraus; davor wurde die Teilausgabe verworfen und der ganze Zug als Fehler gemeldet.
Alle drei in einem Satz. Connection closed heißt: die Leitung wurde gekappt; Response stalled: sie ist verstummt; Server error: der Server ist gestürzt. Alles wirkt wie „mittendrin stehen geblieben", passierte aber an jeweils anderer Stelle des Transports.
Die Referenz nennt noch ein wissenswertes Verhalten. Tritt derselbe Fehler auf, bevor überhaupt sichtbare Ausgabe erscheint, wiederholt Claude Code die Anfrage, statt den Zug abzuschließen. Anders gesagt: Dass Sie diese Meldung sehen, heißt, dass bereits Ausgabe erschienen war — ein erneutes Senden könnte also Nebenwirkungen verdoppeln, und Claude Code hat bewusst nicht automatisch wiederholt. Ein Fehler bedeutet nicht, dass nichts versucht wurde.
2. Das Erste, was zu tun ist — nichts ist verloren
Bevor Sie hektisch dieselbe Anweisung erneut abschicken, gehen Sie in dieser Reihenfolge vor.
Wie die Dokumentation sagt: Nichts ist verloren. Es fehlen meist nur die letzten Sätze oder der letzte Tool-Aufruf.
continueDer in der offiziellen Fehlerreferenz genannte Wiederaufnahmeschritt. Lassen Sie Claude dort weitermachen, wo es aufgehört hat, statt neu zu beginnen.
Brach es während Dateiänderungen oder Befehlsausführungen ab, ist möglicherweise schon ein Teil gelaufen. Sehen Sie sich mit git status den tatsächlichen Stand an, bevor Sie fortfahren.
Tritt es mehrfach in einer Sitzung auf, prüfen Sie zuerst die Version. Dieser Bereich wurde wiederholt korrigiert.
Übergehen Sie Schritt 3 nicht. Wenn die Dokumentation schreibt, ein erneutes Senden könne „dieselben Tool-Aufrufe zweimal ausführen", heißt die Kehrseite: Einige Tools sind zum Zeitpunkt des Abbruchs vielleicht schon gelaufen. Passierte es mitten beim Schreiben von Dateien, beim Commit oder beim Deployment, ist zuerst der Blick auf den tatsächlichen Stand der kürzeste Weg zurück.
3. Warum es abreißt — die drei Ebenen, auf denen die Verbindung schließt
Mit „Die Verbindung ist abgebrochen" allein lässt sich nichts anfangen; daher trennen wir die Orte, von denen das Schließen ausgehen kann. Die Meldungen verteilen sich auf drei Ebenen.
Ein kurzer WLAN-Aussetzer, ein Zellwechsel im Mobilfunk, das Aufwachen aus dem Ruhezustand. Das offizielle Changelog enthält sogar einen Fix für „Streaming-Anfragen, die nach dem Aufwachen der Maschine scheitern" (2.1.186) — diese Ebene ist also real.
Was hilft: kabelgebunden oder stabil anbinden; den Rechner bei langen Aufgaben nicht schlafen lassen.
Die offizielle Fehlerdokumentation der Claude API hält fest, dass manche Netze im Leerlauf stehende Verbindungen nach unterschiedlich langer Zeit kappen, und empfiehlt TCP-Keep-Alive. Firmen-Proxys und VPNs neigen genau dazu.
Was hilft: Proxy/VPN kurz umgehen und prüfen, ob es weiterhin auftritt.
Es gibt Belege auf Paketebene, dass die Verbindung serverseitig geschlossen wird, während der Stream läuft (nächster Abschnitt). Dagegen hilft keine lokale Einstellung.
Was hilft: das Wiederholungsverhalten des Clients — deshalb wirkt ein Update.
Tatsächlich beschreibt der Melder von GitHub-Issue #69415 ([BUG] API Error: Connection closed mid-response ==> frequent enough to make Claude Code unusable for any task, eröffnet am 18. Juni 2026 und zum Redaktionsschluss noch offen) folgende Umgebung: Windows 11 mit WSL2, Direktverbindung ohne Unternehmens-Firewall und ohne Proxy, Claude Code 2.1.181. Die Behauptung lautet also, dass es selbst nach Ausschluss der Ebenen 1 und 2 auftritt. Das Issue trägt die Labels area:networking, platform:vscode und platform:wsl.
Derselbe Melder schreibt, auf demselben Rechner und im selben Netz brächten andere KI-Assistenten (GitHub Copilot, Cursor und weitere) dieselbe Aufgabe zu Ende. Das ist allerdings ein Vergleich eines Nutzers und keine Ursachenfeststellung durch Anthropic — diese Unterscheidung sollte man beibehalten.
Eine weitere Meldung beschreibt deutlich andere Bedingungen. Issue #69336 (occurs immediately in new context window, eröffnet am 18. Juni 2026 und offen, Claude Code 2.1.173, Debian 13, ein selbst gehostetes Claude Agent SDK) berichtet, die Häufigkeit steige, nachdem die Kontextzusammenfassung (compact) gelaufen ist. Es trägt area:agent-sdk, area:api und platform:linux; als vorübergehender Ausweg wird das Starten einer völlig neuen Unterhaltung genannt. Issue #69517 (in Claude Cowork, 19. Juni 2026, macOS, 2.1.183) wurde als Duplikat geschlossen.
4. Was Paketmitschnitte zeigten: ein Schließen vom Server aus
Die gründlichste Untersuchung aus erster Hand zu dieser Fehlerklasse ist Issue #67766 (eröffnet am 12. Juni 2026, weiterhin offen). Der Melder hat in seiner Umgebung Pakete mitgeschnitten und zehn Vorfälle abgeglichen.
Quelle: die vom Melder des GitHub-Issues #67766 veröffentlichten Paketmitschnitte und Sitzungsaufzeichnungen. Es handelt sich um Messungen eines einzelnen Nutzers, nicht um von Anthropic verifizierte Ergebnisse.
Technisch am aufschlussreichsten ist, dass das Schließen selektiv erfolgte. Laut Bericht blieben andere Verbindungen zum selben Ziel während des Ereignisses am Leben; geschlossen wurde genau die Verbindung des Prozesses, der die Anfrage ausführte. Die Verbindungen zweier weiterer, gleichzeitig laufender claude-Prozesse blieben unangetastet. Ein Leitungsausfall hätte alle mitgerissen; das geschah nicht.
Zudem beobachtete der Melder, dass in vier der zehn Vorfälle Schübe von Schließungen mehrere Verbindungen des Pools gleichzeitig trafen und drei davon in benachbarten Minuten jeweils bei Sekunde :54 auftraten (01:19:54, 01:20:54 und 01:22:54 UTC) — für ihn ein Hinweis auf einen Vorgang im 60-Sekunden-Takt.
🟡 Wie belastbar ist dieser Abschnitt?
Die in Issue #67766 gezeigte Meldung lautet „API Error: The socket connection was closed unexpectedly" und ist damit anders formuliert als die dieses Artikels. Man kann nicht behaupten, es handle sich um denselben Defekt. Gleichwohl ist dies derzeit der einzige öffentliche Beleg auf Paketebene für dieselbe Art von Verhalten — eine Verbindung, die bei laufendem Stream schließt — und damit als Arbeitshypothese wertvoll. Ergänzend gilt: Anthropic hat zu dieser Meldung keine Erklärung veröffentlicht.
5. Prüfen Sie Ihre Version — die Chronologie der Fixes
Das ist der praktisch nützlichste Teil des Artikels. Wer das offizielle Claude-Code-Changelog durchgeht, sieht: Der Umgang mit Verbindungsabbrüchen mitten im Stream wurde fortlaufend verbessert. Jeder der folgenden Punkte steht tatsächlich im Changelog.
Teilantworten bleiben bei Verbindungsabbrüchen mitten im Stream nun erhalten. Zuvor erschien ein roher Fehler, und die Fortschrittsanzeige konnte bei „running tool" hängen bleiben.
Der Hinweis auf einen stockenden Stream lautet nun „Waiting for API response · will retry in …" und erscheint nach 20 statt nach 10 Sekunden Stille, sodass kurze Schwankungen keine Warnung mehr auslösen.
Behoben, dass kurze Netzabbrüche mitten in der Antwort den Zug abbrachen. Vorübergehende Fehler wie ECONNRESET werden nun mit Backoff wiederholt, statt zu scheitern.
Behoben, dass gestreamte Antworten verworfen wurden, wenn mitten im Stream ein Überlast- oder Serverfehler eintraf. Der Teil bleibt nun mit einem Hinweis auf eine unvollständige Antwort erhalten — daher stammt die Variante Server error mid-response.
Der Keep-Alive-Verbindungspool wird nach einem Fehler durch eine veraltete Verbindung nun deaktiviert, sodass Wiederholungen einen frischen Socket öffnen. Das trifft genau das Muster aus #67766: eine wiederverwendete Verbindung, die geschlossen wird.
Halten Sie diese Chronologie nun neben die Versionen der oben genannten Meldungen.
| Meldung | Version damals | Damals noch fehlende Fixes |
|---|---|---|
| #69336 | 2.1.173 | Alle: 2.1.179 / 198 / 199 / 214 |
| #69415 | 2.1.181 | 2.1.198 / 199 / 214 (Wiederholungs-Verbesserung und Pool-Fix) |
| #69517 | 2.1.183 | 2.1.198 / 199 / 214 |
Alle drei liegen vor 2.1.198 — jener Version, die vorübergehende Abbrüche durch Wiederholungen abfängt. Prüfen Sie also zuerst Ihre eigene Version.
claude --versionLiegt sie unter 2.1.198, bringt ein Update mehr als Fehlersuche. Der jüngste Changelog-Eintrag zum Redaktionsschluss ist 2.1.220 und enthält sämtliche oben genannten Fixes.
Trotzdem lässt sich nicht sagen, dass ein Update den Fehler sicher beseitigt. Im Changelog steht kein Eintrag, der „Connection closed" selbst benennt; alles Obige sind Verbesserungen benachbarter Verbindungsbehandlung. Betrachten Sie das Update als den ersten Schritt mit dem besten Aufwand-Nutzen-Verhältnis, nicht als bewiesene Heilung.
6. Bedingungen, die es wahrscheinlicher machen
Diese Faktoren tauchen in den Meldungen immer wieder auf.
Mehrere große Dateien lesen und einen strukturierten Bericht erzeugen — alles, was den Stream lange offen hält (#69415).
Berichtet wird ein Anstieg der Häufigkeit, nachdem die Kontextzusammenfassung gelaufen ist (#69336). Danach werden Anfragen tendenziell größer.
In den Messungen zu #67766 trugen die geschlossenen Verbindungen Anfragerümpfe von 1 bis 2,5 MB. Zum Vergleich: Das offizielle Limit der Messages API liegt bei 32 MB.
Firmen-Proxys, VPNs, Verbindungen über weite Strecken. Genau die Ebene, die die offizielle Dokumentation meint, wenn sie von Netzen spricht, die Leerlaufverbindungen kappen.
Changelog 2.1.186 behob Streaming-Anfragen, die nach dem Aufwachen der Maschine scheiterten. Lassen Sie den Rechner bei langen Aufgaben nicht einschlafen.
In #67766 traten 87 von 171 Vorfällen weniger als fünf Sekunden nach dem vorherigen Aufruf auf — ein Muster, das Leerlauf-Timeouts allein nicht erklären.
7. Sofort beheben — Checkliste für Anwender
Arbeiten Sie die Liste von oben ab; das Günstigste zuerst.
| Nr. | Was tun | Wozu |
|---|---|---|
| 1 | continue antworten | Der dokumentierte Wiederaufnahmeschritt. Nutzt das bereits Angekommene, statt neu zu beginnen. |
| 2 | claude --version ausführen und bei alter Version aktualisieren | Bringt die Wiederholungs-Verbesserung aus 2.1.198 und den Pool-Fix aus 2.1.214. Zuerst erledigen. |
| 3 | Nebenwirkungen prüfen (git status und Ähnliches) | Feststellen, ob Tools vor dem Abbruch teilweise gelaufen sind. Verhindert doppelte Ausführung. |
| 4 | Die Aufgabe aufteilen | Kürzere Antworten bedeuten weniger Zeit im Risiko. Zerlegen Sie „lies alle Dateien und schreib den Bericht" in Etappen. |
| 5 | Proxy/VPN kurz umgehen und erneut testen | Grenzt Ebene 2 ein. Verschwindet der Fehler, liegt es am Weg. |
| 6 | Ruhezustand und Energiesparen ausschalten, kabelgebunden arbeiten | Grenzt Ebene 1 ein — besonders auf Notebooks mit langen Aufgaben. |
| 7 | In einer völlig neuen Sitzung probieren | Der in #69336 gemeldete vorübergehende Ausweg. Hilft mitunter, wenn es direkt nach einer Zusammenfassung gehäuft auftritt. |
| 8 | Bei Reproduzierbarkeit mit Details melden | Wie die offizielle API-Dokumentation rät, die request_id (die Kennung, die mit req_ beginnt) beilegen — das beschleunigt die Analyse. |
Was Sie nicht tun sollten. Die TLS-Prüfung abzuschalten (NODE_TLS_REJECT_UNAUTHORIZED=0 und Ähnliches), weil „die Verbindung ständig abbricht", behandelt ein völlig anderes Symptom und opfert die Sicherheit Ihres gesamten Datenverkehrs. Zertifikatsfehler sind ein anderer Fehler mit einer anderen Lösung.
8. Für Entwickler — Vorbeugung auf API-/SDK-Ebene
Wenn Sie dieselbe Art von Abbruch über das Claude Agent SDK oder eine eigene API-Integration erleben, liefert die offizielle Fehlerdokumentation der Claude API konkrete Entwurfsleitlinien.
Die Dokumentation empfiehlt die Messages API im Streaming-Modus oder die Message Batches API für lange Anfragen, besonders jenseits von 10 Minuten. Ein großes max_tokens ohne Streaming ist die anfälligste Form.
Laut Dokumentation verringert TCP-Keep-Alive die Auswirkung von Leerlauf-Timeouts, wenn Sie direkt integrieren. Die offiziellen SDKs setzen es bereits. Prüfen, falls Sie einen eigenen HTTP-Client gebaut haben.
Die offiziellen SDKs wiederholen vorübergehende Fehlschläge — Verbindungsfehler, Ratenlimits, 5xx — standardmäßig zweimal mit exponentiellem Backoff und beachten den retry-after-Header. Eine Client-Option erlaubt Anpassung oder Abschaltung.
Die Falle, die die Dokumentation ausdrücklich nennt: Bei SSE kann ein Fehler auftreten, nachdem die API bereits 200 zurückgegeben hat, er läuft also nicht über den üblichen HTTP-Fehlerpfad. Behandeln Sie Fehlerereignisse im Stream gesondert.
Claude Code selbst hat diesen Weg in 2.1.179 und 2.1.199 eingeschlagen. Empfangene Blöcke behalten und den Rest anfordern kostet weniger — an Tokens wie an Nebenwirkungen — als alles zu verwerfen und neu zu senden.
In 2.1.214 hat Claude Code den Keep-Alive-Pool so geändert, dass er nach einem Fehler durch eine veraltete Verbindung deaktiviert wird und Wiederholungen einen frischen Socket öffnen. Es lohnt zu prüfen, ob Ihre Wiederholung dieselbe tote Verbindung greift.
Für Lasten, bei denen Sie gar keine ununterbrochene Verbindung voraussetzen wollen — Stapelverarbeitung ist das offensichtliche Beispiel —, ist der offiziell empfohlene Weg die Message Batches API mit Abruf der Ergebnisse per Polling. Das beseitigt das Netzrisiko strukturell, statt es nur zu mildern.
9. Abgrenzung zu ähnlichen Fehlern
Die Transportfehler von Claude Code sehen sich sehr ähnlich. Am schnellsten trennt man sie danach, wie weit die Anfrage gekommen ist.
| Meldung | Wo es stehen blieb | Hauptmaßnahme |
|---|---|---|
| Connection closed mid-response (dieser Artikel) | Verbunden, Stream lief, dann gekappt | continue / Update / Weg eingrenzen |
| Response stalled mid-stream | Verbindung lebt, aber stumm | Separat behandelt (Achtung auf die Verkettung mit der Wiederholungsschleife) |
| Server error mid-response | Ein 5xx- oder Überlastfehler mitten im Stream | Warten und erneut versuchen. Siehe Artikel zu 529/500 |
| Unable to connect / SSL certificate verification failed | Gar nicht erst verbunden | Proxy, Unternehmens-CA, Firewall. Siehe Artikel zu Verbindungsfehlern |
| Prompt is too long | Schon vor dem Senden abgelehnt (das Netz ist in Ordnung) | Kontext kürzen. Siehe eigenen Artikel |
Die größte Weiche ist schlicht, ob überhaupt eine Antwort auf dem Bildschirm erschien. Kam kein einziges Zeichen durch, verdächtigen Sie die Verbindung selbst: Konfiguration und Weg. Erschien Ausgabe und brach dann ab, ist das der Beweis, dass die Verbindung stand — hören Sie also auf, an Einstellungen zu drehen, und folgen Sie stattdessen der Eingrenzung aus diesem Artikel.
10. Offizieller Stand und was noch offen ist
Um Missverständnisse zu vermeiden: Das lässt sich offiziell bestätigen — und das nicht.
- Die Meldung ist in der offiziellen Fehlerreferenz förmlich dokumentiert und bedeutet „die Verbindung ist abgebrochen"
- Bereits übertragene Ausgabe bleibt erhalten — so gewollt
- Der Wiederaufnahmeschritt ist die Antwort
continue - Fehlschläge vor jeder sichtbaren Ausgabe werden automatisch wiederholt
- Fixes zur Verbindungsbehandlung kamen in 2.1.179 / 198 / 199 / 214
- Server, die mitten im Stream ein FIN senden (in #67766 gemessen — allerdings unter anderer Meldung)
- Die Beteiligung eines 60-Sekunden-Durchlaufs (Schlussfolgerung des Melders selbst)
- Häufungen direkt nach einem compact (#69336)
- Dass andere KI-Assistenten unter gleichen Bedingungen nicht scheitern (Vergleich des Melders von #69415)
- Eine offizielle Ursachenerklärung von Anthropic (keine öffentliche Antwort in #69415, #69336 oder #67766)
- Ein Fix-Eintrag, der „Connection closed" benennt (diese Zeichenfolge steht nicht im Changelog)
- #69415, #69336 und #67766 sind alle noch offen
Kurz: Symptom und Vorgehen sind offiziell dokumentiert, eine offizielle Erklärung, warum es abreißt, wurde jedoch nicht veröffentlicht. In dieser Lage schlagen Arbeitsgewohnheiten die Ursachensuche: kurze Züge, bei Operationen mit Nebenwirkungen den Zustand laufend prüfen, und auf einer aktuellen Version bleiben.
Häufige Fragen
Q1. Geht bei „Connection closed mid-response" die bisherige Ausgabe verloren?
Nein. Wie die offizielle Fehlerreferenz ausdrücklich festhält, bleibt alles bereits Übertragene erhalten. Claude Code hängt den Hinweis bewusst an, statt erneut zu senden, weil ein erneutes Senden dieselben Tool-Aufrufe zweimal ausführen könnte. Es fehlen meist nur die letzten Sätze oder der letzte Tool-Aufruf.
Q2. Was antworte ich, um dort weiterzumachen, wo es aufgehört hat?
Antworten Sie continue. Das ist der in der offiziellen Fehlerreferenz genannte Wiederaufnahmeschritt. Die ursprüngliche Anweisung zu wiederholen birgt das Risiko, bereits ausgeführte Operationen zu duplizieren.
Q3. Sind die Tokens verschwendet?
Was bis zum Abbruch erzeugt wurde, ist verbraucht. Der Melder von Issue #69336 hält fest, dass verbrauchte Tokens nicht erstattet werden. Genau deshalb zählt continue statt Neuanfang auch bei den Kosten, nicht nur bei der Zeit.
Q4. Ist das dasselbe wie „Response stalled mid-stream"?
Nein. Nach den offiziellen Definitionen bedeutet Connection closed „die Verbindung ist abgebrochen" und Response stalled „der Stream hat aufgehört, Daten zu senden" — gekappt gegenüber verstummt. Auf dem Bildschirm ähneln sie sich, doch die Variante stalled wurde zusammen mit einer Wiederholungsschleife des Modells gemeldet, und die Abhilfe unterscheidet sich. Siehe den Artikel zu Response stalled mid-stream.
Q5. Liegt es an meinem Netzwerk?
Möglich, aber nicht zwingend. Der Melder von Issue #69415 beobachtete es auf einer Direktverbindung ohne Proxy und ohne Firewall, und die Paketmitschnitte in Issue #67766 deuten darauf hin, dass das Schließen serverseitig ausgelöst wurde. Umgehen Sie zuerst Proxy oder VPN und prüfen Sie, ob es weiterhin auftritt; ändert sich nichts, ist es nicht rein lokal.
Q6. Behebt ein Update von Claude Code das Problem?
Es ist der Schritt mit dem besten Verhältnis, den Sie zuerst versuchen sollten. Das offizielle Changelog zeigt, dass 2.1.198 „kurze Netzabbrüche mitten in der Antwort, die den Zug abbrachen" behoben hat und 2.1.214 den Keep-Alive-Pool so geändert hat, dass er nach einem Fehler durch eine veraltete Verbindung deaktiviert wird und Wiederholungen einen frischen Socket öffnen. Die Häufung der Meldungen (2.1.173 bis 2.1.183) liegt davor. Da jedoch kein Changelog-Eintrag „Connection closed" selbst benennt, ist ein Update eine wahrscheinliche Verbesserung, keine garantierte Heilung.
Q7. Bei langen Aufgaben passiert es ständig. Gibt es einen Ausweg?
Die Aufgabe so zu teilen, dass jede Antwort kürzer wird, ist die verlässlichste Option. Sammelaufträge nach dem Muster „lies alle großen Dateien und schreib den Bericht" halten den Stream sehr lange offen; allein das Trennen von Lesen und Schreiben verkürzt dieses Fenster und senkt die Wahrscheinlichkeit, einen Abbruch zu treffen. Issue #69336 berichtet zudem, dass eine neue Unterhaltung vorübergehend geholfen hat.
Q8. Wie verhindere ich das als Entwickler in meiner eigenen Anwendung?
Die Leitlinien der offiziellen Claude-API-Dokumentation sind eindeutig: (1) lange Antworten immer streamen, jenseits von 10 Minuten die Batches API erwägen; (2) TCP-Keep-Alive setzen (die offiziellen SDKs tun das bereits); (3) bei SSE können Fehler nach einem 200 eintreffen, behandeln Sie Fehlerereignisse im Stream also gesondert; (4) bei einem Abbruch das Empfangene behalten und den Rest anfordern. Legen Sie beim Kontakt mit dem Support die request_id bei.
Q9. Ich bekomme denselben Fehler in Claude Cowork und im Agent SDK.
Dieselbe Meldung wurde auch dort berichtet. Issue #69517 meldet sie in Claude Cowork (als Duplikat geschlossen) und #69336 über ein selbst gehostetes Claude Agent SDK. Es ist ein Verhalten der Schicht, die gestreamte Antworten verarbeitet; der Ansatz bleibt daher gleich: fortsetzen statt neu starten, auf einer aktuellen Version bleiben und die Wiederholungslogik sauber entwerfen.
Verwandte Artikel
- Claude Code „court"-Endlosschleife und „Response stalled mid-stream": Ursachen und sofortige Abhilfe
- Claude Code Verbindungsfehler: Proxy, TLS und Firewall beheben
- Claude Code: 529 Overloaded und 500 Server Error — Ursachen und Lösung
- Claude Code „Prompt is too long" — Kontextfenster verstehen und beheben
- Häufige Claude-Code-Fehler und ihre Lösungen — Die vollständige Referenz
