Codex hat einen Responses-Stream gelesen oder versucht, einen zu öffnen, und er endete, bevor das Ereignis response.completed eintraf: Die Verbindung wurde geschlossen, blieb stumm, brach auf Netzwerkebene ab oder der Server meldete einen Fehler. Codex versucht dies standardmäßig fünfmal selbst erneut. Der nach dem Doppelpunkt ausgegebene Grund zeigt, was passiert ist, und bestimmt, wo Sie suchen sollten.
Der Fehler
# Codex CLI, once its retries are spent
■ stream disconnected before completion: stream closed before response.completed
# While it retries (VS Code extension, an early-2026 build)
Reconnecting... 1/5
stream disconnected before completion: error sending request for url (https://…/responses)
# The reason after the colon varies, and it is the diagnosis:
# stream closed before response.completed
# idle timeout waiting for SSE
# error sending request (Codex before 0.156 adds: for url (…))
# An error occurred while processing your request. You can retry your request, …
# Incomplete response returned, reason: max_output_tokensUrsachen und Lösungen im Überblick
| Ursache | Lösung |
|---|---|
| Ein VPN, Proxy, eine Firewall oder ein TLS-überwachendes Zwischenmodul hat die Verbindung geschlossen | Versuchen Sie es über ein anderes Netzwerk; wenn der Fehler verschwindet, nehmen Sie den API-Host von diesem Proxy oder der Überwachung aus. |
| Der Server ist während der Antwort fehlgeschlagen – der Grund ist die eigene Meldung des Servers | Lokal muss nichts geändert werden: Lassen Sie Codex den Versuch wiederholen, prüfen Sie den Status des Anbieters und versuchen Sie es später erneut. |
| Während des durch stream_idle_timeout_ms festgelegten Zeitraums (standardmäßig 300.000 ms) ist nichts eingetroffen | Ein angehaltener Upstream oder ein puffender Proxy; erhöhen Sie das Timeout nur für legitime Stillephasen. |
| Ein benutzerdefinierter Anbieter, der Streams ohne response.completed beendet | Führen Sie curl -N dagegen aus: Jede erfolgreiche Antwort muss mit diesem Ereignis enden. |
| Die Antwort wurde absichtlich beendet – „Unvollständige Antwort zurückgegeben“ | Eine Token-Grenze, ein Inhaltsfilter oder ein anderer Grund, den die Meldung nennt. Ein erneuter Versuch wiederholt dies normalerweise, ändern Sie daher die Anfrage. |
Lesen Sie den Grund nach dem Doppelpunkt
Codex verwendet diesen einen Fehler für einen Stream, der ohne spezifischere Diagnose vorzeitig endet, und hängt den Grund an. Im Quellcode ergibt ein Stream, der einfach endet, „stream closed before response.completed“; einer, der länger als stream_idle_timeout_ms stumm bleibt, ergibt „idle timeout waiting for SSE“ („idle timeout waiting for websocket“ beim WebSocket-Transport des integrierten OpenAI-Anbieters); bei einer Anfrage, die auf der Leitung abbricht, bleibt die Formulierung des HTTP-Clients erhalten, „error sending request“ (Builds vor 0.156 fügen die URL hinzu); und ein allgemeines response.failed-Ereignis setzt die Servermeldung nach den Doppelpunkt. Seit Codex 0.148 wird eine Verbindung, die überhaupt nicht geöffnet werden kann – DNS, TLS, abgelehnter Port – als separater Fehler „Connection failed“ gemeldet; aktuelle Builds versuchen es weiter, während sie auf das Netzwerk warten.
stream closed before response.completed the connection ended with no terminal event:
network path, server, or a provider that
never sends response.completed
idle timeout waiting for SSE no event for stream_idle_timeout_ms
error sending request the request broke on the wire: a reset, a
proxy or a middlebox (before 0.148, also
a connection that never opened)
…error decoding response body the body broke mid-read: network or middlebox
An error occurred while processing… the server's own response.failed message
Incomplete response returned, reason: … the server stopped it: a token cap, a content
filter, or whatever the reason namesErfahren Sie, was Codex bereits erneut versucht, und passen Sie es pro Anbieter an
Es gelten zwei Wiederholungsbudgets. request_max_retries (Standardwert 4) deckt die HTTP-Anfrage ab, bevor ein Stream existiert; Codex versucht dort 5xx-Antworten und Transportfehler erneut, aber keine 429er. stream_max_retries (Standardwert 5) deckt alles auf dieser Seite ab: Jeder Versuch sendet den Turn erneut, was „Reconnecting... 1/5“ zählt, und wenn das Budget erschöpft ist, bleibt der Fehler auf dem Bildschirm und der Turn wird beendet. Beide Werte sind auf 100 begrenzt und befinden sich in einem Block [model_providers.<id>]. Die integrierte Anbieter-ID openai ist reserviert und kann nicht neu definiert werden; diese Einstellungen gelten daher für benutzerdefinierte Anbieter.
model = "gpt-5-6-sol"
model_provider = "kunavo"
[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"
# wire_api defaults to "responses", the only supported value
stream_max_retries = 10 # dropped or failed streams (default 5, max 100)
request_max_retries = 4 # 5xx and network errors before streaming (default 4, max 100)
stream_idle_timeout_ms = 300000 # silence before giving up (default 300000)Reproduzieren Sie den Stream ohne Codex
Ein Responses-Stream endet mit einem terminalen Ereignis, und Codex benötigt dafür response.completed. Senden Sie mit curl vom selben Rechner eine Anfrage derselben Art. Wenn sie jedes Mal abgeschlossen wird, während Codex weiterhin die Verbindung verliert, prüfen Sie den Codex-Build und seine offenen Issues; wenn curl ebenfalls abbricht, wiederholen Sie den Test über ein anderes Netzwerk, bevor Sie den Anbieter verantwortlich machen. Notieren Sie, wann die Fehler auftreten: Ein Abbruch nach derselben verstrichenen Zeit bei jedem Durchlauf deutet auf einen Timer irgendwo auf dem Übertragungsweg hin, nicht auf ein instabiles Netzwerk.
curl -sN https://api.kunavo.com/v1/responses \
-H "Authorization: Bearer $KUNAVO_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"gpt-5-6-sol","stream":true,
"input":"Write a 600-word story about a lighthouse keeper."}' \
| grep -oE '"type": ?"response\.(completed|failed|incomplete)"'
# a healthy run prints exactly one line: "type":"response.completed"Nehmen Sie den Netzwerkpfad aus der Gleichung, dann prüfen Sie den Anbieter
Testen Sie über ein zweites Netzwerk, bevor Sie Schlussfolgerungen ziehen. Im OpenAI-Forum hörten die Fehler eines Nutzers auf einem Arbeitsrechner sofort auf, als er den Zscaler des Unternehmens deaktivierte; in einem GPT-5.6-Thread verschwanden die Fehler eines Nutzers über ein VPN oder einen Handy-Hotspot, während sie bei einem anderen nach dem Netzwerkwechsel bestehen blieben. Wenn ein anderes Netzwerk das Problem behebt, nehmen Sie den API-Host vom Proxy oder der TLS-Inspektion aus, statt Timeouts zu erhöhen. Für einen benutzerdefinierten Anbieter meldet codex doctor, ob die Konfiguration geladen wurde und ob die Schlüsselvariable des Anbieters vorhanden ist; der Anbieter muss die Responses API bereitstellen, da wire_api keinen anderen Wert hat, und supports_websockets sollte nicht gesetzt werden, sofern der Anbieter nicht den Responses-WebSocket-Transport ausführt. Wenn curl sauber abgeschlossen wird und Codex weiterhin fehlschlägt, fügen Sie Ihre Reproduktion den Issues #41340 oder #41989 im Repository openai/codex hinzu. Diese Issues melden diesen Fehler bei benutzerdefinierten Responses-Anbietern, die außerhalb von Codex korrekt streamen; die Issues waren am 23. September 2026 offen.
Wenn Sie Kunavo verwenden
Über Kunavo ist der /v1/responses-Stream eines GPT-Modells der eigene Ereignisstream des Upstreams, der Frame für Frame weitergeleitet wird: Nur die Modell-ID wird umgeschrieben, und Kunavo fügt keine Keepalive-Ereignisse hinzu. Bis das erste Ausgabereignis eintrifft, wird der Stream höchstens 30 Sekunden zurückgehalten; daher kann ein Upstream, der in dieser Phase einen Fehler meldet, ein Timeout erreicht oder die Verbindung trennt, noch über den nächsten Modellkanal erneut versucht werden, sofern einer konfiguriert ist. Wenn keiner ihn bereitstellt, erhält Codex statt eines Streams einen HTTP-Fehler – 502, wenn der Upstream einen Fehler meldete, nie antwortete oder Kunavos eigenen Schlüssel ablehnte, wobei die Ursache im JSON-Code steht, etwa upstream_524 oder upstream_403 (jeder andere Upstream-4xx-Status behält seinen eigenen Status) – den Codex als unexpected status 502 Bad Gateway: Upstream provider error ausgibt, nicht als diese Meldung, und ebenfalls erneut versucht. Nach dem ersten Ausgabereignis kann nichts erneut versucht werden, ohne die Ausgabe zu duplizieren: Ein Upstream-response.failed wird unverändert weitergeleitet, sodass Codex es genau wie direkt von OpenAI behandelt (ein allgemeiner Fehler gibt seine Meldung nach dem Doppelpunkt aus), und eine während der Antwort abreißende Upstream-Verbindung beendet Kunavos Stream ohne terminales Ereignis; Codex meldet dies als stream closed before response.completed. In beiden Fällen greifen Codex’ eigene Wiederholungsversuche. Auf Kunavos Seite begrenzt nichts einen weiter fließenden Stream – das Limit von 240 Sekunden gilt nur für das Warten auf Upstream-Header –, aber Stille beendet ihn: Kunavo liest einen Upstream nicht weiter, der 300 Sekunden lang nichts sendet, ebenso wie Codex’ Standard-Leerlaufzeit, und die Edge schließt eine Verbindung, die 600 Sekunden lang keine Bytes überträgt. Jeder dieser Fehler wird mit Kosten von null erfasst. Der oben angepasste Anbieterblock befindet sich auf der Codex-CLI-Integrationsseite.
Häufig gestellte Fragen
Was bedeutet „stream closed before response.completed“?
Die HTTP-Antwort wurde gestartet, und die Verbindung endete anschließend ohne das Ereignis response.completed, auf das Codex wartet. Etwas hat sie vorzeitig geschlossen: ein Proxy oder eine Firewall auf dem Übertragungsweg, der Server oder ein benutzerdefinierter Endpunkt, der dieses Ereignis nie sendet.
Versucht Codex „stream disconnected before completion“ automatisch erneut?
Ja. Codex sendet den Turn bis zu stream_max_retries-mal erneut (standardmäßig 5-mal, höchstens 100-mal) und zeigt dabei Reconnecting... 1/5 an. Wenn das Budget erschöpft ist, bleibt der Fehler auf dem Bildschirm und der Turn wird beendet; das Senden einer weiteren Nachricht startet eine neue Anfrage.
Soll ich stream_idle_timeout_ms erhöhen?
Nur wenn der Grund „idle timeout waiting for SSE“ lautet und die Stille legitim ist. Bei „stream closed before response.completed“ bewirkt dies nichts, da die Verbindung beendet wurde, statt still zu bleiben. Über Kunavo bringen Werte über 300000 nach dem Start des Streams nichts mehr: Kunavo liest einen Upstream, der 300 Sekunden lang nichts sendet, nicht weiter und beendet Ihren Stream.
Warum sagt Codex „Incomplete response returned, reason: max_output_tokens“?
Der Server hat die Antwort an seiner Token-Grenze beendet und dies mit einem response.incomplete-Ereignis gemeldet. Codex gibt dies unter demselben Fehler aus und versucht es erneut; ein erneuter Versuch desselben Turns stößt normalerweise wieder an dieselbe Grenze. Teilen Sie daher die Aufgabe auf oder verwenden Sie ein Modell mit einer größeren Ausgabelimitierung. Über Kunavo erreicht der Max-Token-Abbruch eines Claude-Modells Codex auf dieselbe Weise.
Werden mir die erneuten Versuche berechnet?
Jeder erneute Versuch ist eine neue Anfrage. Über Kunavo wird ein GPT-Aufruf, der beim Upstream fehlschlägt – ein Fehler vor dem Streaming, ein response.failed oder eine abgebrochene Verbindung –, mit Kosten von null erfasst. Ein Versuch, den Codex aufgegeben hat, während der Upstream weiterarbeitete, wird für die vom Upstream gemeldete Produktion berechnet, da diese Arbeit ausgeführt wurde.
Verwandte Anleitungen
- 401-Fehler in Codex CLI: Den richtigen Authentifizierungsweg beheben
- LLM-Streaming-Fehler — SSE-Abbrüche, hängende Streams und fehlende Nutzungsdaten
- Codex-CLI-API-Schlüssel – die funktionierende Einrichtung für benutzerdefinierte Provider
Weitere Informationen zur Fehlersemantik finden Sie unter Fehlerreferenz; einen Schlüssel erhalten Sie in einer Minute über Registrierung und die Authentifizierungsanleitung.