Perbaikan Codex “stream disconnected before completion”

Codex sedang membaca stream Responses, atau mencoba membukanya, dan stream berakhir sebelum event response.completed tiba: koneksi ditutup, menjadi diam, rusak di tingkat jaringan, atau server melaporkan kegagalan. Codex mencoba ulang secara otomatis, lima kali secara default. Alasan yang dicetak setelah titik dua memberi tahu Anda apa yang terjadi, dan menentukan tempat pemeriksaan.

Error

Output Codex (tata letak bervariasi menurut klien)

# 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_tokens

Ringkasan penyebab dan perbaikan

Penyebab	Perbaikan
VPN, proxy, firewall, atau middlebox yang memeriksa TLS menutup koneksi	Coba lagi dari jaringan lain; jika error berhenti, kecualikan host API dari proxy atau pemeriksaan tersebut.
Server gagal di tengah respons — alasannya adalah pesan milik server sendiri	Tidak ada yang perlu diubah secara lokal: biarkan Codex mencoba lagi, periksa status provider, lalu coba lagi nanti.
Tidak ada data yang tiba selama stream_idle_timeout_ms (300.000 ms secara default)	Upstream yang macet atau proxy buffering; naikkan timeout hanya untuk keheningan yang memang sah.
Provider kustom yang mengakhiri stream tanpa response.completed	Jalankan curl -N terhadapnya: setiap respons yang berhasil harus diakhiri event tersebut.
Respons sengaja diakhiri — "Incomplete response returned"	Batas token, filter konten, atau penyebab lain yang disebutkan dalam alasan. Percobaan ulang biasanya mengulanginya, jadi ubah permintaannya.

Baca alasan setelah titik dua

Codex menggunakan satu error ini untuk stream yang berakhir lebih awal tanpa diagnosis yang lebih spesifik, lalu menambahkan alasannya. Dalam source-nya, stream yang sekadar berakhir menghasilkan "stream closed before response.completed"; stream yang diam lebih lama daripada stream_idle_timeout_ms menghasilkan "idle timeout waiting for SSE" ("idle timeout waiting for websocket" pada transport WebSocket yang digunakan provider OpenAI bawaan); permintaan yang rusak di jaringan mempertahankan teks klien HTTP, "error sending request" (build sebelum 0.156 menambahkan URL); dan event response.failed generik menempatkan pesan server setelah titik dua. Sejak Codex 0.148, koneksi yang sama sekali tidak dapat dibuka — DNS, TLS, port ditolak — dilaporkan sebagai error terpisah, "Connection failed", yang terus dicoba ulang oleh build saat ini sambil menunggu jaringan.

what each reason means

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 names

Ketahui apa yang sudah dicoba ulang Codex, lalu sesuaikan per provider

Ada dua anggaran percobaan ulang. request_max_retries (default 4) mencakup permintaan HTTP sebelum stream apa pun tersedia; Codex mencoba ulang respons 5xx dan error transport di sana, tetapi bukan 429. stream_max_retries (default 5) mencakup semua hal di halaman ini: setiap percobaan ulang mengirim ulang giliran, yang dihitung oleh "Reconnecting... 1/5", dan saat anggaran habis, error tetap tampil dan giliran dihentikan. Keduanya dibatasi maksimum 100, dan keduanya berada dalam blok [model_providers.<id>]. ID provider openai bawaan dicadangkan dan tidak dapat didefinisikan ulang, sehingga pengaturan ini berlaku untuk provider kustom.

~/.codex/config.toml

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)

Reproduksi stream tanpa Codex

Stream Responses berakhir dengan satu event terminal, dan Codex memerlukan event tersebut berupa response.completed. Kirim jenis permintaan yang sama menggunakan curl dari mesin yang sama. Jika permintaan selalu selesai sementara Codex terus terputus, periksa build Codex dan issue terbukanya; jika curl juga terputus, ulangi dari jaringan lain sebelum menyalahkan provider. Catat kapan kegagalan terjadi: putus pada waktu berlalu yang sama di setiap proses mengarah pada timer di suatu tempat pada jalur, bukan jaringan yang tidak stabil.

reproduce.sh

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"

Hilangkan jalur jaringan, lalu periksa provider

Uji dari jaringan kedua sebelum menarik kesimpulan. Di forum OpenAI, error seorang pengguna pada mesin kerja berhenti segera setelah menonaktifkan Zscaler perusahaan; dalam thread GPT-5.6, error seorang pengguna hilang melalui VPN atau hotspot ponsel, sedangkan error pengguna lain tetap ada setelah berpindah jaringan. Jika jaringan lain memperbaikinya, kecualikan host API dari proxy atau pemeriksaan TLS, bukan menaikkan timeout. Untuk provider kustom, codex doctor melaporkan apakah konfigurasi dimuat dan apakah variabel key provider tersedia; provider harus melayani Responses API, karena wire_api tidak memiliki nilai lain, dan supports_websockets harus tetap tidak disetel kecuali provider menjalankan transport Responses WebSocket. Jika curl selesai dengan baik tetapi Codex tetap gagal, tambahkan reproduksi Anda ke issue openai/codex #41340 atau #41989, yang melaporkan error ini terhadap provider Responses kustom yang melakukan streaming dengan benar di luar Codex dan masih terbuka pada 23 September 2026.

Jika Anda melakukan panggilan melalui Kunavo

Melalui Kunavo, stream /v1/responses model GPT adalah stream peristiwa milik upstream yang diteruskan frame demi frame: hanya ID model yang ditulis ulang, dan Kunavo tidak menambahkan peristiwa keepalive. Hingga peristiwa output pertama tiba, selama paling lama 30 detik, stream ditahan, sehingga upstream yang mengalami error, timeout, atau terputus pada tahap tersebut masih dapat dicoba ulang pada channel model berikutnya jika dikonfigurasi. Jika tidak ada yang melayaninya, Codex menerima error HTTP, bukan stream — 502 ketika upstream mengalami error, tidak pernah menjawab, atau menolak kunci milik Kunavo, dengan penyebab di kode JSON, seperti upstream_524 atau upstream_403 (upstream 4xx lainnya mempertahankan statusnya sendiri) — yang dicetak Codex sebagai unexpected status 502 Bad Gateway: Upstream provider error, bukan sebagai pesan ini, dan juga dicoba ulang. Setelah peristiwa output pertama, tidak ada yang dapat dicoba ulang tanpa menggandakan output: response.failed dari upstream diteruskan sebagaimana dikirim, sehingga Codex menanganinya persis seperti jika berasal langsung dari OpenAI (kegagalan umum mencetak pesannya setelah titik dua), dan koneksi upstream yang terputus di tengah jawaban mengakhiri stream Kunavo tanpa peristiwa terminal, yang dilaporkan Codex sebagai stream closed before response.completed. Dalam kedua kasus, percobaan ulang milik Codex mengambil alih. Tidak ada batas dari sisi Kunavo untuk stream yang terus mengalir — batas 240 detik hanya mencakup penantian header upstream — tetapi keheningan mengakhiri stream: Kunavo berhenti membaca upstream yang tidak mengirim apa pun selama 300 detik, sama seperti default idle Codex, dan edge menutup koneksi yang tidak membawa byte selama 600 detik. Setiap kegagalan tersebut dicatat dengan biaya nol. Blok provider yang disetel di atas adalah yang dikonfigurasi pada halaman integrasi Codex CLI.

Pertanyaan umum

Apa arti “stream closed before response.completed”?

Respons HTTP telah dimulai, lalu koneksi berakhir tanpa peristiwa response.completed yang ditunggu Codex. Sesuatu menutupnya lebih awal: proxy atau firewall di sepanjang jalur, server, atau endpoint khusus yang tidak pernah mengirim peristiwa tersebut.

Apakah Codex otomatis mencoba ulang “stream disconnected before completion”?

Ya. Codex mengirim ulang giliran tersebut hingga stream_max_retries kali (default 5, maksimum 100) dan menampilkan Reconnecting... 1/5 selama proses berlangsung. Ketika anggaran habis, error tetap tampil di layar dan giliran berhenti; pengiriman pesan lain memulai permintaan baru.

Haruskah saya meningkatkan stream_idle_timeout_ms?

Hanya jika alasannya adalah "idle timeout waiting for SSE" dan keheningan tersebut memang wajar. Ini tidak berpengaruh pada "stream closed before response.completed", ketika koneksi berakhir alih-alih menjadi hening. Melalui Kunavo, nilai di atas 300000 tidak memberi manfaat setelah stream dimulai: Kunavo berhenti membaca upstream yang tidak mengirim apa pun selama 300 detik dan mengakhiri stream Anda.

Mengapa Codex mengatakan “Incomplete response returned, reason: max_output_tokens”?

Server menghentikan respons pada batas tokennya dan menyatakannya melalui peristiwa response.incomplete. Codex melaporkannya sebagai error yang sama dan mencoba ulang, tetapi percobaan ulang giliran yang sama biasanya kembali mencapai batas tersebut, jadi bagi tugas atau gunakan model dengan batas output yang lebih besar. Melalui Kunavo, penghentian max-token model Claude mencapai Codex dengan cara yang sama.

Apakah saya dikenai biaya untuk percobaan ulang?

Setiap percobaan ulang adalah permintaan baru. Melalui Kunavo, panggilan GPT yang gagal di upstream — error sebelum streaming, response.failed, koneksi terputus — dicatat dengan biaya nol. Percobaan yang dihentikan Codex saat upstream masih bekerja ditagihkan berdasarkan jumlah yang dilaporkan upstream telah dihasilkan, karena pekerjaan tersebut sudah dilakukan.

Panduan terkait

Detail semantik error lainnya tersedia di referensi error; mendapatkan kunci hanya perlu satu menit melalui pendaftaran dan panduan autentikasi.