O Codex estava lendo um stream de Responses, ou tentando abrir um, e ele terminou antes da chegada do evento response.completed: a conexão foi fechada, ficou silenciosa, sofreu uma falha no nível da rede ou o servidor informou uma falha. O Codex tenta novamente por conta própria, cinco vezes por padrão. O motivo exibido após os dois-pontos informa qual desses casos ocorreu, e isso determina onde procurar.
O erro
# 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_tokensCausas e soluções em resumo
| Causa | Solução |
|---|---|
| Uma VPN, proxy, firewall ou intermediário que inspeciona TLS fechou a conexão | Tente novamente em outra rede; se o erro parar, isente o host da API desse proxy ou dessa inspeção. |
| O servidor falhou no meio da resposta — o motivo é a própria mensagem do servidor | Não há nada a alterar localmente: deixe o Codex tentar novamente, verifique o status do provedor e tente mais tarde. |
| Nada chegou durante stream_idle_timeout_ms (300,000 ms por padrão) | Um upstream travado ou um proxy que armazena dados em buffer; aumente o timeout apenas para silêncios legítimos. |
| Um provedor personalizado que encerra streams sem response.completed | Execute curl -N contra ele: toda resposta bem-sucedida precisa terminar com esse evento. |
| A resposta foi encerrada intencionalmente — "Incomplete response returned" | Um limite de tokens, um filtro de conteúdo ou outra causa que o motivo identifica. Uma nova tentativa geralmente repete o problema, portanto altere a solicitação. |
Leia o motivo após os dois-pontos
O Codex usa este erro para um stream que termina antecipadamente sem um diagnóstico mais específico e acrescenta o motivo. No código-fonte, um stream que simplesmente termina produz "stream closed before response.completed"; um que permanece silencioso por mais tempo que stream_idle_timeout_ms produz "idle timeout waiting for SSE" ("idle timeout waiting for websocket" no transporte WebSocket usado pelo provedor OpenAI integrado); uma solicitação que falha na rede mantém a formulação do cliente HTTP, "error sending request" (compilações anteriores à 0.156 acrescentam a URL); e um evento response.failed genérico coloca a mensagem do servidor após os dois-pontos. Desde o Codex 0.148, uma conexão que não pode ser aberta — DNS, TLS ou porta recusada — é informada como um erro separado, "Connection failed", que as compilações atuais continuam tentando novamente enquanto aguardam a rede.
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 namesSaiba o que o Codex já tenta novamente e ajuste por provedor
Dois orçamentos de novas tentativas se aplicam. request_max_retries (padrão 4) cobre a solicitação HTTP antes de existir um stream; o Codex tenta novamente respostas 5xx e erros de transporte, mas não 429. stream_max_retries (padrão 5) cobre tudo nesta página: cada nova tentativa reenvia o turno, que é o que "Reconnecting... 1/5" contabiliza, e quando o orçamento acaba o erro permanece na tela e o turno é interrompido. Ambos têm limite de 100 e ficam em um bloco [model_providers.<id>]. O ID do provedor openai integrado é reservado e não pode ser redefinido, portanto essas são opções para provedores personalizados.
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)Reproduza o stream sem o Codex
Um stream de Responses termina com um evento terminal, e o Codex precisa que ele seja response.completed. Envie o mesmo tipo de solicitação com curl a partir da mesma máquina. Se ele for concluído sempre enquanto o Codex continua se desconectando, examine a compilação do Codex e seus problemas em aberto; se o curl também falhar, repita em outra rede antes de culpar o provedor. Observe quando as falhas ocorrem: uma queda no mesmo tempo decorrido em todas as execuções aponta para um temporizador em algum ponto do caminho, não para uma rede instável.
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"Elimine o caminho de rede e depois verifique o provedor
Teste em uma segunda rede antes de concluir qualquer coisa. No fórum da OpenAI, os erros de um usuário em uma máquina de trabalho pararam assim que ele desativou o Zscaler da empresa; em uma discussão sobre GPT-5.6, os erros de um usuário desapareceram com uma VPN ou hotspot do celular, enquanto os de outro persistiram após a troca de rede. Se outra rede resolver, isente o host da API do proxy ou da inspeção TLS, em vez de aumentar os timeouts. Para um provedor personalizado, codex doctor informa se a configuração foi carregada e se a variável da chave do provedor está presente; o provedor precisa oferecer a Responses API, pois wire_api não tem outro valor, e supports_websockets deve permanecer indefinido, a menos que ele execute o transporte Responses WebSocket. Se o curl for concluído corretamente e o Codex continuar falhando, adicione sua reprodução aos problemas #41340 ou #41989 de openai/codex, que relatam este erro com provedores Responses personalizados que transmitem corretamente fora do Codex e estavam abertos em 23 de setembro de 2026.
Se você estiver chamando pela Kunavo
Através do Kunavo, o stream /v1/responses de um modelo GPT é o próprio stream de eventos do upstream, retransmitido quadro a quadro: apenas o ID do modelo é reescrito, e o Kunavo não adiciona eventos de keepalive. Até a chegada do primeiro evento de saída, por no máximo 30 segundos, o stream fica retido, portanto um upstream que falha, atinge o timeout ou encerra a conexão nessa etapa ainda pode ser tentado novamente no próximo canal do modelo, quando houver um configurado. Se nenhum canal o atender, o Codex recebe um erro HTTP em vez de um stream — 502 quando o upstream falhou, nunca respondeu ou recusou a própria chave do Kunavo, com a causa no código JSON, como upstream_524 ou upstream_403 (qualquer outro 4xx do upstream mantém seu próprio status) — que o Codex exibe como unexpected status 502 Bad Gateway: Upstream provider error, e não como esta mensagem, e também tenta novamente. Após o primeiro evento de saída, nada pode ser tentado novamente sem duplicar a saída: um response.failed do upstream passa como enviado, portanto o Codex o trata exatamente como trataria diretamente da OpenAI (uma falha genérica exibe sua mensagem após os dois-pontos), e uma conexão do upstream que cai no meio da resposta encerra o stream do Kunavo sem evento terminal, o que o Codex informa como stream closed before response.completed. Em ambos os casos, as novas tentativas do próprio Codex assumem o controle. Nada no lado do Kunavo limita um stream que continua fluindo — o limite de 240 segundos cobre apenas a espera pelos cabeçalhos do upstream — mas o silêncio encerra um: o Kunavo para de ler um upstream que não envia nada por 300 segundos, igual ao padrão de inatividade do Codex, e a borda fecha uma conexão que não transporta bytes por 600 segundos. Cada uma dessas falhas é registrada com custo zero. O bloco do provedor ajustado acima é o configurado em a página de integração da CLI do Codex.
Perguntas frequentes
O que significa “stream closed before response.completed”?
A resposta HTTP começou e a conexão terminou sem o evento response.completed que o Codex aguarda. Algo a fechou antecipadamente: um proxy ou firewall no caminho, o servidor ou um endpoint personalizado que nunca envia esse evento.
O Codex tenta novamente “stream disconnected before completion” automaticamente?
Sim. O Codex reenvia a mensagem até stream_max_retries vezes (5 por padrão, 100 no máximo) e mostra Reconnecting... 1/5 enquanto faz isso. Quando o orçamento acaba, o erro permanece na tela e a mensagem é interrompida; enviar outra mensagem inicia uma nova solicitação.
Devo aumentar stream_idle_timeout_ms?
Somente quando o motivo é "idle timeout waiting for SSE" e o silêncio é legítimo. Isso não tem efeito em "stream closed before response.completed", quando a conexão terminou em vez de ficar silenciosa. Através do Kunavo, valores acima de 300000 não trazem benefício depois que o stream começa: o Kunavo para de ler um upstream que não envia nada por 300 segundos e encerra seu stream.
Por que o Codex diz “Incomplete response returned, reason: max_output_tokens”?
O servidor interrompeu a resposta no limite de tokens e informou isso com um evento response.incomplete. O Codex relata isso sob o mesmo erro e tenta novamente, e uma nova tentativa da mesma mensagem geralmente encontra o mesmo limite; portanto, divida a tarefa ou use um modelo com um limite de saída maior. Através do Kunavo, uma interrupção por limite máximo de tokens de um modelo Claude chega ao Codex da mesma maneira.
Sou cobrado pelas novas tentativas?
Cada nova tentativa é uma nova solicitação. Por meio da Kunavo, uma chamada GPT que falha upstream — um erro antes do streaming, um response.failed, uma conexão interrompida — é registrada com custo zero. Uma tentativa da qual o Codex desistiu enquanto o upstream continuou trabalhando é cobrada pelo que o upstream informa ter produzido, porque esse trabalho foi realizado.
Guias relacionados
- Erro 401 do Codex CLI: corrija a rota de autenticação correta
- Erros de streaming de LLM — cortes de SSE, streams travados e uso ausente
- Chave de API da CLI do Codex — configuração funcional de provedor personalizado
Mais detalhes sobre o significado dos erros estão em referência de erros; obter uma chave leva um minuto por meio de cadastro e da guia de autenticação.