Inhaltsverzeichnis
- 1. Das Erste, was zu tun ist — Ihre Ausgabe ist nicht verloren
- 2. Die offiziellen Definitionen — vier Meldungen für „mittendrin abgebrochen“
- 3. v2.1.227 hat „closed“ in „lost“ umbenannt
- 4. Warum nicht automatisch erneut versucht wird
- 5. Wo die Verbindung abreißt — drei Ebenen
- 6. Was Sie jetzt versuchen — die Checkliste zur Eingrenzung
- 7. Timer und Wiederholungen über Umgebungsvariablen einstellen
- 8. Wie Sie sie von ähnlichen Meldungen unterscheiden
- 9. Echte Meldungen — wenn ECONNRESET nicht aufhört
- 10. Was bestätigt ist und was nicht
- FAQ
Wenn Sie Claude Code eine längere Aufgabe geben, kann es mitten in der Antwort plötzlich hiermit stehen bleiben.
API Error: Connection lost mid-response. The response above may be incomplete.
Suchen Sie genau nach dieser Zeichenfolge, kommt erstaunlich wenig zurück. Der Grund liegt offen: Das ist ein recht neuer Name. Die offizielle Fehlerreferenz von Claude Code schreibt es wörtlich — „Vor v2.1.227 erschien Connection lost mid-response als Connection closed mid-response“. Das zugrunde liegende Ereignis gibt es längst; geändert hat sich allein das Wort auf dem Bildschirm, von closed zu lost. Weil das vorhandene Material im Netz unter dem alten Namen geschrieben ist, findet niemand etwas, der nach dem neuen sucht.
Ausgehend von dieser Umbenennung ordnet dieser Artikel (1) was die Meldung genau bedeutet, (2) was jetzt vor dem Bildschirm zu tun ist, (3) warum nicht automatisch erneut versucht wird, (4) wie sich die abreißende Ebene eingrenzen lässt, (5) wie sich das über Umgebungsvariablen einstellen lässt und (6) wie sie sich von den sehr ähnlichen Meldungen unterscheiden lässt — allein anhand der offiziellen Dokumentation und öffentlicher Issues. Wo Schlussfolgerungen einfließen, tragen sie ein Konfidenzlabel.
Was schon auf dem Bildschirm angekommen ist, wurde nicht verworfen. Offiziell gilt: Wer continue antwortet, setzt beim letzten abgeschlossenen Block wieder auf.
Vor v2.1.227 stand dort Connection closed mid-response. Material unter dem alten Namen gilt unverändert weiter.
Was zu tun ist, hängt davon ab, wo es abreißt: Ihr Rechner, der Weg oder die Serverseite. Es gibt Meldungen, in denen rohes HTTPS durchgeht und allein Claude Code abbricht.
1. Das Erste, was zu tun ist — Ihre Ausgabe ist nicht verloren
Vor jeder Abhilfe klären wir den Punkt, der am häufigsten falsch gelesen wird. Auch wenn diese Meldung erscheint, bleibt alles erhalten, was bereits auf den Bildschirm gestreamt wurde. Es wird nicht verworfen.
Die offizielle Fehlerreferenz erklärt die Familie der Meldungen, die auf „The response above may be incomplete.“ enden, so — schlägt das Streaming fehl, nachdem Claude einen Textblock oder einen Tool-Aufruf abgeschlossen hat, könnte ein erneutes Senden denselben Tool-Aufruf zweimal ausführen; deshalb behält Claude Code das Abgeschlossene und hängt diesen Hinweis an, statt den Turn wegzuwerfen.
Es gibt also nur drei Dinge zu tun.
Claude Code behält jeden Block, der abgeschlossen wurde, verwirft aber den letzten Block, der beim Ende des Turns noch lief. Was fehlt, sind meist die letzten Sätze oder der letzte Tool-Aufruf.
continueDas ist der offizielle Wiederherstellungsschritt selbst. Er setzt beim letzten abgeschlossenen Block auf. Geben Sie die Anweisung nicht von vorn ein — das führt bereits ausgeführte Operationen ein zweites Mal aus.
Fiel der Abbruch mitten in einen Dateischreibvorgang oder einen Kommandolauf, ist das Protokoll auf dem Bildschirm der Beleg dafür, wie weit es kam. Sehen Sie sich den echten Zustand mit git status an, bevor Sie weitermachen.
-p-Läufen, dem Agent SDK und Cloud-Sitzungen die Fortsetzung selbst bei Claude an, sofern die unterbrochene Antwort nur Text enthält und keinen Tool-Aufruf — bis zu drei Mal hintereinander. Dieser Hinweis erscheint erst, wenn diese Fortsetzungen aufgebraucht sind. Subagenten setzen auf dieselbe Weise automatisch fort.
2. Die offiziellen Definitionen — vier Meldungen für „mittendrin abgebrochen“
Als Erstes gilt es zu begreifen, dass dieser Wortlaut ein Hinweis ist, den Claude Code selbst schreibt, und nicht der Rumpf einer von der API zurückgegebenen Fehlerantwort. Deshalb variiert Claude Code den Schlusssatz nach Ursache, obwohl das Erlebnis des Abbruchs dasselbe ist. Die offizielle Referenz führt diese vier auf.
API Error: Connection lost mid-response. The response above may be incomplete.
API Error: Your computer went to sleep mid-response. The response above may be incomplete.
API Error: The response stopped arriving. The response above may be incomplete.
Die offizielle Erläuterung ist eine Zeile — die Verbindung ging verloren. Der Stream lief normal, aber die Verbindung, die ihn trug, verschwand.
Mitten im Stream traf eine overloaded- oder 5xx-Antwort ein. Laut offizieller Doku stammt diese Anzeige selbst erst aus v2.1.199; davor wurde die Teilausgabe verworfen und der ganze Turn als Fehler behandelt.
Wenn Claude Code erkennt, dass der Rechner während der Antwort geschlafen hat. Nach dem Aufwachen gilt die Verbindung als defekt, und das Lesen wird eingestellt.
Die Verbindung bleibt offen, aber es kommen keine Daten mehr, und der Stream-Watchdog gibt auf. Ein Stillstand statt eines Abbruchs, mit anderer Ursache und anderer Abhilfe.
Lesen Sie zuerst genau, welche der vier Sie erwischt hat. Das Erlebnis des Abbruchs sieht bei allen gleich aus, aber Claude Code hat die Ursache bereits eingegrenzt und den Wortlaut entsprechend gewählt. Steht dort lost, lautet das Urteil, dass die Verbindung verloren ging — nicht, dass der Server ein 5xx zurückgab, und nicht, dass etwas in eine Zeitüberschreitung lief.
3. v2.1.227 hat „closed“ in „lost“ umbenannt
Das ist der Kern dieses Artikels. Direkt nach den vier Erläuterungen setzt die offizielle Fehlerreferenz diesen Hinweis.
„Vor v2.1.227 erschienConnection lost mid-responsealsConnection closed mid-response, undThe response stopped arrivingerschien alsResponse stalled mid-stream.“
— offizielle Fehlerreferenz von Claude Code (eigene Übersetzung)
Zwei Zeichenfolgen wurden also im selben Moment ausgetauscht. Als Tabelle ergibt sich diese Zuordnung.
| Anzeige vor v2.1.227 | Anzeige heute | Bedeutung (offiziell) |
|---|---|---|
Connection closed mid-response |
Connection lost mid-response |
Die Verbindung ging verloren |
Response stalled mid-stream |
The response stopped arriving |
Die Verbindung blieb offen, aber es kamen keine Daten mehr |
Connection closed while thinking, before producing a response |
Connection lost before a response was produced |
Es brach ab, bevor ein einziges Zeichen ausgegeben war (keine Teilausgabe) |
Response stalled while thinking, before producing a response |
The response stalled before a response was produced |
Es blieb bei offener Verbindung stehen, bevor ein einziges Zeichen ausgegeben war |
Beachten Sie, dass die dritte Zeile etwas anderes ist als die Meldung in diesem Artikel. mid-response heißt, dass es abbrach, nachdem bereits Ausgabe erschienen war, before a response was produced heißt, dass es vor dem ersten Zeichen abbrach — im selben Zug umbenannt, aber verschieden in Bedeutung und in dem, was danach geschieht. Der nächste Abschnitt behandelt das.
Was sich ändert, sobald Sie von der Umbenennung wissen
Es gibt drei praktische Wirkungen.
Suchen Sie nach „Connection closed mid-response“, und GitHub-Issues wie Erfahrungsberichte tauchen sofort auf. Es ist dasselbe Ereignis, also muss nichts umgedeutet werden.
Steht dort lost, ist dieses Claude Code v2.1.227 oder neuer. Steht dort closed, ist es älter.
Weil dasselbe Phänomen unter zwei Namen gemeldet wird, muss eine Issue-Suche beide Zeichenfolgen verwenden, sonst gehen vorhandene Meldungen verloren.
⚠️ Vor v2.1.222 kann der Hinweis selbst falsch sein. Die offizielle Fehlerreferenz hält unmissverständlich fest: „Claude Code vor v2.1.222 zeigte diesen Hinweis auch, wenn die Verbindung abriss oder stehen blieb, nachdem die Antwort bereits abgeschlossen war, und meldete den Turn als Fehler, obwohl die Antwort vollständig war“. Mit anderen Worten: Auf älteren Builds erscheint der Fehler, obwohl die gesamte Ausgabe angekommen ist. Ist claude --version kleiner als 2.1.222, aktualisieren Sie, bevor Sie irgendetwas eingrenzen — der Fehler, den Sie sehen, existiert womöglich gar nicht.
4. Warum nicht automatisch erneut versucht wird
Claude Code tut nicht nichts. Laut „Automatic retries“ in der offiziellen Referenz werden vorübergehende Fehler automatisch mit exponentiellem Backoff bis zu zehnmal wiederholt. Wenn diese Meldung dennoch erscheint, heißt das: Claude Code hat entschieden, dass eine Wiederholung hier falsch wäre.
Der Zweig hängt an genau einer Sache: ob Claude bereits etwas abgeschlossen hatte.
Reißt die Verbindung ab, bevor Claude irgendeinen Teil der Antwort abgeschlossen hat, das Denken eingeschlossen, sendet Claude Code die Anfrage mit demselben Backoff erneut, und der Turn läuft weiter. Das gilt auch, wenn bereits Text zu strömen begonnen hatte.
Ist das Denken beendet, aber weder Text noch ein Tool-Aufruf begonnen, sendet es höchstens zweimal in kurzem Abstand erneut, und reißt es weiter ab, beendet es den Turn mit Connection lost before a response was produced.
Bricht es ab, nachdem ein Textblock oder ein Tool-Aufruf abgeschlossen wurde (oder nach dem Denken begonnen hat), sendet Claude Code die Anfrage nicht erneut. Das könnte denselben Tool-Aufruf zweimal ausführen.
Stattdessen behält es das Abgeschlossene, führt die abgeschlossenen Tool-Aufrufe aus und setzt den Turn mit deren Ergebnissen fort. Danach gibt es diesen Hinweis aus.
Der Entwurf wirkt unbequem, irrt aber auf der sicheren Seite. Würde automatisch erneut gesendet, könnten Operationen mit Nebenwirkungen — eine Datei schreiben, ein Kommando ausführen — bei jedem Abbruch zweimal laufen. Deshalb lautet die offizielle Empfehlung continue statt eines erneuten Sendens — es ist der einzige Weg, der bereits erledigte Arbeit nicht noch einmal machen lässt.
Was während einer Wiederholung auf dem Bildschirm erscheint
Während eine Wiederholung läuft, erscheint neben dem Spinner ein Countdown: Retrying in Ns · attempt x/y. Das Label beginnt als API error, aber ab v2.1.198 wechselt es vom dritten Versuch an zum konkreten Grund (liegt CLAUDE_CODE_MAX_RETRIES unter 3, wechselt es beim letzten Versuch).
Kommen bei lebender Anfrage 20 Sekunden lang keine Daten, erscheint ein Banner, während noch nichts fehlgeschlagen ist: Waiting for API response · will retry in … · check your network. Das ist eine Anzeige mit der Bedeutung, dass bislang nichts fehlgeschlagen ist, und der Countdown läuft bis zu dem Punkt, an dem Claude Code die stehen gebliebene Verbindung aufgeben würde. Laut offizieller Doku lag diese Schwelle vor v2.1.185 bei 10 Sekunden, mit anderem Wortlaut.
5. Wo die Verbindung abreißt — drei Ebenen
Zu erfahren, dass die Verbindung verloren ging, entscheidet noch nicht, was zu tun ist. Es gibt drei grobe Stellen, an denen sie abreißen kann, und jede wird anders geprüft.
Ein Wechsel des WLAN-Zugangspunkts, ein kurzer Aussetzer auf einer Mobilfunkleitung, der Schlafmodus, ein VPN-Client, der neu verbindet.
So prüfen Sie es: Lässt es sich über Kabel oder auf einer anderen Leitung reproduzieren? Ist der Schlafmodus die Ursache, erscheint ein eigener Wortlaut, was die Sache klärt.
Unternehmensproxys, TLS-Inspektion, LLM-Gateways, VPNs. Geräte, die einen lange gehaltenen Stream als untätig behandeln und kappen, sind nicht selten.
So prüfen Sie es: Lässt es sich ohne gesetztes HTTPS_PROXY reproduzieren? Bestätigen Sie die Proxy-Zeile in /status.
Eine Störung auf der Dienstseite oder eine wiederverwendete Verbindung, die in Wahrheit längst tot war. Das Kennzeichen: Es bricht weiter ab, obwohl Ihre Leitung gesund ist.
So prüfen Sie es: Sehen Sie auf status.claude.com. Reproduziert es sich auf mehreren Leitungen gleich, ist es kein rein lokales Problem.
Stale connection — reloaded rotated mTLS client material im Protokoll von claude --debug erscheint.
6. Was Sie jetzt versuchen — die Checkliste zur Eingrenzung
Von oben nach unten sortiert nach größter Wirkung bei geringstem Aufwand. Prüfen Sie nach jedem Schritt, ob es sich noch reproduziert.
| # | Was zu tun ist | Wozu es dient |
|---|---|---|
| 1 | continue antworten | Den Verlust nicht endgültig werden lassen. Schneller als von vorn, ohne Risiko doppelter Ausführung |
| 2 | Claude Code auf den neuesten Build aktualisieren | Das Verbindungsverhalten ändert sich mit der Version. v2.1.198 hat ein Problem behoben, bei dem ein kurzer Netzaussetzer mitten in der Antwort den Turn unterbrach |
| 3 | Einen Turn in kleinere aufteilen | „Einen Stapel Dateien lesen und einen Bericht schreiben“ in Lesen und Schreiben trennen. Die Zeit verringern, die ein Stream überhaupt offen gehalten wird |
| 4 | Mit abgeschaltetem VPN und Proxy reproduzieren | Grenzt Ebene 2 ein. Behebt das Abschalten den Fehler, liegt der Verdacht auf einer Untätigkeitskappung auf dem Weg |
| 5 | Auf einer anderen Leitung reproduzieren | Trennt Ebene 1 von Ebene 3. Verhalten sich mehrere Leitungen gleich, ist es kein rein lokales Problem |
| 6 | Die Schlafeinstellungen durchsehen | Wird Ihr Bildschirm während einer langen Antwort dunkel, kann die Verbindung abreißen, bevor der eigene Wortlaut erscheinen kann |
| 7 | Auf status.claude.com sehen | Bestätigt Ebene 3. Bei einem 529 gibt Claude Code diesen Hostnamen selbst auf dem Bildschirm aus |
| 8 | Eine Sitzung mit claude --debug aufzeichnen | Das Protokoll landet in ~/.claude/debug/<session-id>.txt. Hängen Sie es an, wenn Sie eine Meldung einreichen |
| 9 | Prüfen, ob Sie über einen SOCKS-Proxy laufen | Die offizielle Dokumentation hält fest, dass SOCKS-Proxys nicht unterstützt werden. Nutzen Sie einen, nehmen Sie einen anderen Weg |
7. Timer und Wiederholungen über Umgebungsvariablen einstellen
Claude Code hält vier unabhängige Timer, um einen still gewordenen Stream aufzugeben. Die Liste in der offiziellen Dokumentation zur Netzwerkkonfiguration sieht so aus.
| Timer | Bedingung für das Aufgeben | Standardwert |
|---|---|---|
| First-byte deadline | Nach dem Senden trifft kein einziger Antwort-Header ein | 180 s bei der direkten API, sonst 300 s (plus 1 s je 32 KB Anfragerumpf) |
| Event-level watchdog | Kein einziges Antwort-Event lässt sich parsen | 300 s (bei jedem Anbieter aktiv) |
| Byte-level watchdog | Es treffen überhaupt keine Bytes ein, SSE-Keep-alive-Pings eingeschlossen | 180 s bei der direkten API, sonst 300 s |
| Body idle timeout | Fünf Minuten lang keine Bytes | 5 Minuten (für andere Anbieter als die direkte API) |
Allerdings landet das, was diese Timer aufgeben, in aller Regel beim Wortlaut der Stille — einer anderen Meldung als der dieses Artikels. Sie steht hier, weil Sie die Standardwerte brauchen, um beide auseinanderzuhalten, und nicht, weil „lost erschien, also verlängern wir einen Timer“. In einer Umgebung mit langen Stillephasen hinter einem Proxy ändert das Anpassen dieser Werte tatsächlich das Symptom auf der Stillstandsseite.
Auf der Seite der Wiederholungen gelten diese Variablen.
| Umgebungsvariable | Standard | Wirkung |
|---|---|---|
CLAUDE_CODE_MAX_RETRIES |
10 | Wie viele Wiederholungen. Ab v2.1.186 liegt die Obergrenze bei 15. In Skripten wird empfohlen, sie zu senken und schnell scheitern zu lassen |
CLAUDE_CODE_RETRY_WATCHDOG |
nicht gesetzt | Für unbeaufsichtigte Sitzungen wie CI. Auf 1 gesetzt wiederholt es 429 und 529 unbegrenzt und hebt ab v2.1.199 die Standardanzahl für vorübergehende Fehler einschließlich Abbrüchen auf 300 |
API_TIMEOUT_MS |
600000 | Zeitüberschreitung je Anfrage (Millisekunden, also 10 Minuten). Auf langsamen Leitungen oder hinter einem Proxy erhöhen |
CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS |
nicht gesetzt | Zeitüberschreitung allein für den Byte-Watchdog. Wird auf 10 Sekunden bis 30 Minuten begrenzt |
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS |
nicht gesetzt | Setzt die Frist bis zum ersten Byte direkt. Verfügbar ab v2.1.242 |
CLAUDE_CODE_MAX_RETRIES hilft dem Fehler, der abbricht, bevor Ausgabe erscheint; für einen Abbruch mitten in der Antwort tut es nichts. Was hilft, ist, jeden Turn kürzer zu machen.
8. Wie Sie sie von ähnlichen Meldungen unterscheiden
Für Leserinnen und Leser ist das vielleicht der nützlichste Teil. Das Erlebnis, mittendrin stehen zu bleiben, ist dasselbe, aber der Wortlaut, den Claude Code ausgibt, unterscheidet sich, und ebenso Ursache und Abhilfe. Hier ist es, abgebildet auf die vorhandenen Artikel dieser Website.
| Wortlaut auf dem Bildschirm | Was geschieht | Wo Sie nachlesen |
|---|---|---|
Connection lost mid-response |
Ausgabe war erschienen, und dann ging die Verbindung verloren | dieser Artikel |
Connection closed mid-response |
Der alte Name für dasselbe Ereignis (vor v2.1.227) | der closed-Artikel, der die Meldungen aus der Zeit des alten Namens sammelt |
The response stopped arrivingalt: Response stalled mid-stream |
Die Verbindung lebt, ist aber still geworden, und ein Timer hat aufgegeben | der stalled-Artikel (achten Sie auf die Verkettung mit einer Wiederholungsschleife) |
Server error mid-response |
Mitten im Stream gab die Serverseite ein 5xx oder overloaded zurück | der Artikel zu 529 und 500 |
Your computer went to sleep mid-response |
Claude Code hat erkannt, dass der Rechner geschlafen hat, während die Antwort lief | die Energie- und Schlafeinstellungen durchsehen (Abschnitt 6 dieses Artikels) |
Connection lost before a response was produced |
Es brach ab, bevor ein einziges Zeichen erschien (keine Teilausgabe) | ein Fall, der wiederholt wird. Abschnitt 4 dieses Artikels |
Unable to connect und SSL-Zertifikatsfehler |
Es verbindet sich überhaupt nicht | der Artikel zu Netzwerk und Proxy |
court- oder invoke-Tags erscheinen im Text |
Kein Netzwerkproblem — der Tool-Aufruf wird nicht ausgeführt | der Artikel zum court-Tag |
Der größte Zweig ist, ob überhaupt eine Antwort auf dem Bildschirm erschien. Kam kein einziges Zeichen durch, rücken die Verbindung oder die Konfiguration (Proxy, Zertifikate, Firewall) in den Verdacht. Kam Ausgabe bis zu einem Punkt, ist das der Beleg, dass die Verbindung funktionierte; dann ist der Weg über die Eingrenzung in diesem Artikel richtiger als das Ändern von Einstellungen.
Der zweite Zweig ist Abbruch gegen Stille
Ob die Verbindung verloren ging oder bei offener Leitung verstummte, dreht den nächsten Schritt vollständig um.
Verdächtigen Sie den Weg und die Wiederverwendung von Verbindungen. Die Werte für die Zeitüberschreitung zu verlängern, bringt nichts — nichts lief in eine Zeitüberschreitung; die Verbindung selbst ist weg.
Hier zählen die Timer. CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS und Ähnliches anzupassen hat Spielraum, und auch ein Modell, das lange verstummt, ist verdächtig.
9. Echte Meldungen — wenn ECONNRESET nicht aufhört
Das übelste Muster ist, dass allein Claude Code abbricht, während die lokale Leitung völlig gesund ist. Zwei öffentliche Issues tragen erhebliche Prüfarbeit. Beide sind unter dem neuen Namen dieses Artikels gemeldet oder enthalten den Wortlaut der Version unmittelbar davor.
Die meldende Person schreibt, dass auf Connection dropped (ECONNRESET) · Retrying in 17s · attempt 6/10 ein API Error: Connection lost mid-response. folgt. Darüber hinaus liefen ein 60-KB-POST per curl und ein POST derselben Größe per reinem Node.js mit https.request beide normal durch, und ein lang laufender SSE von einem anderen Host riss ebenfalls nicht ab.
MTU-Prüfungen, Winsock-LSP-Prüfungen, die Reproduktion auf einer minimalen Konfiguration und die Reproduktion in zwei voneinander unabhängigen Netzen sind alle erledigt, und es bleibt ungelöst. Issue #86473 ist als Duplikat markiert und dennoch offen.
Hier lautet es Connection dropped (ECONNRESET) · Retrying in 0s · attempt 4/10. Die meldende Person schreibt, dass es nach der vollständigen Deinstallation der Sicherheitssoftware und dem Ausschluss von VPN-Filtern, Proxy und IPv6 sowie einem Winsock-Reset auf drei Netzen identisch auftrat: Büro-WLAN, Heim-WLAN und Tethering über das Telefon.
Der angebotene Gegensatz ist, dass der Chat auf claude.ai ohne Probleme läuft, auf demselben Rechner und mit demselben Konto. Issue #85979 ist ebenfalls weiterhin offen (stale).
Trotzdem gibt es aus den beiden etwas Praktisches mitzunehmen. „ping funktioniert“ und „curl funktioniert“ sind kein Beleg dafür, dass dieser Fehler nicht auftritt. Verkehr, der eine Verbindung minutenlang für einen Stream offen hält, ist nicht in derselben Lage wie eine kurze Anfrage. Statt Zeit in die Untersuchung des lokalen Netzes zu stecken, ist das Aufteilen des Turns der einfachere Weg, die Häufigkeit zu senken.
10. Was bestätigt ist und was nicht
Um Fehldeutungen zu vermeiden, steht hier, was sich offiziell bestätigen lässt, getrennt von dem, was sich nicht bestätigen lässt.
- Dieser Wortlaut ist in der offiziellen Fehlerreferenz förmlich dokumentiert und bedeutet, dass die Verbindung verloren ging
- Vor v2.1.227 erschien er als
Connection closed mid-response(eine Umbenennung derselben Sache) - Ausgabe, die bereits gestreamt wurde, wird bewusst behalten (weil ein erneutes Senden doppelte Ausführung riskiert)
- Der Wiederherstellungsschritt ist,
continuezu antworten - Ein Abbruch, bevor Ausgabe erscheint, wird automatisch wiederholt (bis zu zehnmal, exponentielles Backoff)
- Nicht interaktive Sitzungen und Subagenten setzen von allein fort (ab v2.1.246 beziehungsweise ab v2.1.257)
- Rohes HTTPS ist gesund, während allein die CLI mit ECONNRESET stirbt (gemeldet in #86473 und #85979)
- Der Gegensatz, dass die Browser-Version auf demselben Rechner und Konto läuft (gemeldet in #85979)
- Die Möglichkeit, dass ein Fehler bei der Wiederverwendung von Verbindungen beteiligt ist (Erklärung des Supports, zitiert von der meldenden Person)
- Ein Hinweis auf serverseitige Störungen zu bestimmten Zeiten (ebenfalls über die meldende Person)
- Eine offizielle Erklärung der Ursache durch Anthropic (keines der beiden Issues oben hat eine öffentliche Antwort)
- Der Grund für die Umbenennung. Im CHANGELOG ist keine Änderung des Wortlauts verzeichnet
- #86473 und #85979 sind beide weiterhin offen
Kurz gesagt: Symptom, Bedeutung und Wiederherstellungsschritt sind offiziell dokumentiert, während keine offizielle Erklärung veröffentlicht ist, warum es abreißt. Was in dieser Lage verlässlich wirkt, ist nicht das Bestimmen der Ursache, sondern ein Betrieb, in dem ein Abbruch wenig kostet — Turns kurz aufteilen, Operationen mit Nebenwirkungen unter Prüfung des Zustands ausführen und die Version aktuell halten. Diese drei helfen, welche Ursache sich auch immer herausstellt.
FAQ
Q1. Sind „Connection lost mid-response“ und „Connection closed mid-response“ verschiedene Fehler?
Sie sind dasselbe. Wie die offizielle Fehlerreferenz ausdrücklich festhält, wurde dasselbe Ereignis vor v2.1.227 als Connection closed mid-response angezeigt. Eine geänderte Anzeige bedeutet nicht, dass eine neue Art von Störung aufgetreten ist. Material, das unter dem alten Namen geschrieben wurde, lässt sich unverändert weiterverwenden.
Q2. Geht die Ausgabe bis zu diesem Punkt verloren?
Nein. Jeder Block, den Claude abgeschlossen hat, bleibt erhalten. Verworfen wird allein der letzte Block, der beim Ende des Turns noch lief. Claude Code hängt diesen Hinweis bewusst an, statt erneut zu senden, weil ein erneutes Senden riskiert, denselben Tool-Aufruf zweimal auszuführen.
Q3. Was antworte ich, um dort fortzusetzen, wo es aufgehört hat?
Antworten Sie continue. Das ist der Wiederherstellungsschritt, den die offizielle Fehlerreferenz nennt, und er setzt beim letzten abgeschlossenen Block auf. Die Anweisung von vorn zu geben riskiert, bereits gelaufene Operationen zu verdoppeln.
Q4. Behebt es ein höherer Wiederholungszähler?
Nein. Wie Abschnitt 4 erklärt, ist dies der Hinweis für eine Lage, in der Claude Code eine Wiederholung bewusst vermeidet. CLAUDE_CODE_MAX_RETRIES (Standard 10, Obergrenze 15 ab v2.1.186) hilft dem Fehler, der abbricht, bevor Ausgabe erscheint. Was hier hilft, ist, jeden Turn kürzer zu machen.
Q5. Ist es mit -p oder in CI (nicht interaktive Läufe) dasselbe?
Das Verhalten unterscheidet sich. Laut offizieller Referenz fordert Claude Code in einer nicht interaktiven Sitzung die Fortsetzung selbst an, wenn die unterbrochene Antwort nur Text enthält und keinen Tool-Aufruf — bis zu drei Mal hintereinander. Dieser Hinweis erscheint, sobald sie aufgebraucht sind. Vor v2.1.246 endete der Turn beim ersten Abbruch. Wenn Sie --output-format json nutzen, landet diese Meldung im Feld result.
Q6. Sie erscheint auch in Subagenten (Task).
Subagenten setzen auf dieselbe Weise automatisch fort. Enthält die unterbrochene Antwort nur Text, fordert Claude Code den Subagenten zur Fortsetzung auf, und erst wenn die Fortsetzungen aufgebraucht sind, wird dieser Hinweis zur letzten Meldung. Vor v2.1.257 wurde der Hinweis beim ersten Abbruch ausgegeben.
Q7. Ist mein eigenes Netz schuld?
Vielleicht, aber nicht zwangsläufig allein. Die meldende Person in Issue #86473 hat gezeigt, dass POSTs derselben Größe per curl und per reinem Node.js durchlaufen, und meldet, dass allein die CLI abbricht. Prüfen Sie zuerst, ob es sich mit abgeschaltetem VPN und Proxy reproduziert, und versuchen Sie danach eine andere Leitung. Ändert beides nichts, ist es kein rein lokales Problem.
Q8. Verringern längere Zeitüberschreitungen es?
Für diese Meldung erwarten Sie das besser nicht. Das Urteil lautet, dass die Verbindung selbst verloren ging, und nicht, dass die Zeit ablief. Timer wie CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS zu verlängern hilft bei The response stopped arriving, dem Symptom, bei dem die Verbindung lebt, aber verstummt.
Q9. Wie prüfe ich, auf welcher Version ich bin?
Führen Sie claude --version aus. Steht auf dem Bildschirm lost, sind Sie auf v2.1.227 oder neuer; steht dort closed, auf etwas Älterem. Das Verbindungsverhalten hat sich über die Versionen geändert, und das offizielle CHANGELOG verzeichnet in v2.1.198 einen Fix dafür, dass ein kurzer Netzaussetzer mitten in der Antwort den Turn unterbrach. Ein Update ist der erste Versuch wert, aber keine Garantie für eine Heilung — beide oben zitierten Issues sind Meldungen zu neueren Versionen.
Q10. In einem Unternehmensnetz passiert es ständig. Welche Einstellungen sollte ich ansehen?
Die offizielle Dokumentation zur Netzwerkkonfiguration deckt das Wesentliche ab. Drei Punkte: erstens werden SOCKS-Proxys nicht unterstützt, nutzen Sie also keinen; zweitens legen Sie die Proxy-Variablen in den env-Block von ~/.claude/settings.json, statt sie aus der Shell zu exportieren (Hintergrundagenten erben die Shell-Umgebung nicht); drittens achten Sie bei mTLS auf die Zertifikatsrotation. Ob die Einstellungen gelesen wurden, lässt sich im Protokoll von claude --debug oder in der Anzeige von /status bestätigen.
Verwandte Artikel
- API Error: Connection closed mid-response in Claude Code: Ursachen und Lösung
- 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: „court“ und durchgesickerte invoke-Tags — wenn der Tool-Aufruf nicht läuft
- Häufige Claude-Code-Fehler und ihre Lösungen — Die vollständige Referenz
Herangezogene Primärquellen
- Claude Code — Error reference (offizielle Dokumentation): die Definitionen der vier Zeichenfolgen, die Umbenennung in v2.1.227, die Wiederherstellung per
continue, der Zweig der Automatic retries, die Umgebungsvariablen - Claude Code — Enterprise network configuration (offizielle Dokumentation): die vier Stream-Watchdog-Timer und ihre Standardwerte, die Proxy-Konfiguration, die fehlende SOCKS-Unterstützung, das Neuladen bei mTLS
- anthropics/claude-code — CHANGELOG (offiziell): der Fix in v2.1.198 für einen kurzen Netzaussetzer mitten in der Antwort, der den Turn unterbrach
- Issue #86473 — ECONNRESET / Connection lost mid-response (v2.1.229 unter Windows 11)
- Issue #85979 — ECONNRESET weiterhin auf v2.1.228 (Windows 11)
- Claude-Dienststatus (offizielle Statusseite)
