Sumário
- 1. O que fazer primeiro — a saída na tela não sumiu
- 2. A definição oficial — as 4 mensagens de resposta interrompida
- 3. Na v2.1.227, closed virou lost
- 4. Por que não há nova tentativa automática
- 5. Onde a conexão se rompe — as 3 camadas
- 6. O que testar agora — checklist de isolamento
- 7. Ajustar temporizadores e retentativas por variáveis de ambiente
- 8. Como distinguir das mensagens parecidas
- 9. Relatos reais — o ECONNRESET que não para
- 10. O que está confirmado e o que não está
- FAQ
Quando você deixa o Claude Code em uma tarefa mais longa, a resposta às vezes para no meio e aparece isto.
API Error: Connection lost mid-response. The response above may be incomplete.
Pesquisar essa frase exata devolve pouquíssima coisa. O motivo é claro: este é um nome relativamente novo. A referência oficial de erros do Claude Code traz a frase literalmente — “antes da v2.1.227, Connection lost mid-response aparecia como Connection closed mid-response”. Ou seja, o fenômeno já existia antes; só a palavra exibida trocou de closed para lost. Como o material que circula na internet foi escrito com o nome antigo, quem pesquisa pelo nome novo não encontra nada.
Partindo desse fato, este artigo organiza 1) o sentido exato da mensagem, 2) o que fazer agora, diante da tela, 3) por que não há nova tentativa automática, 4) como isolar a camada em que a conexão cai, 5) o ajuste por variáveis de ambiente e 6) a distinção em relação a outras mensagens parecidas, apoiado apenas na documentação oficial e em issues públicas. Onde houver suposição, o grau de confiança vem marcado.
O que já apareceu na tela não foi apagado. Se você responder continue, o trabalho segue do último bloco concluído — é o que orienta a documentação oficial.
Antes da v2.1.227 a mensagem era Connection closed mid-response. O material escrito com o nome antigo continua válido.
A solução muda conforme a queda seja no seu computador, no caminho da rede ou no lado do servidor. Há relatos de HTTPS puro passando enquanto só o Claude Code cai.
1. O que fazer primeiro — a saída na tela não sumiu
Antes de qualquer providência, vale esclarecer o ponto que mais gera confusão. Mesmo com essa mensagem, tudo o que já tinha chegado à tela permanece. Nada foi descartado.
A referência oficial de erros explica assim o grupo de mensagens terminadas em “The response above may be incomplete.” (a resposta acima pode estar incompleta) — se o streaming falha depois que o Claude concluiu um bloco de texto ou uma chamada de ferramenta, reenviar a requisição correria o risco de executar a mesma chamada de ferramenta duas vezes; por isso o Claude Code mantém o que foi concluído e acrescenta esse aviso em vez de jogar o turno fora.
Portanto, são só três movimentos.
O Claude Code preserva todos os blocos concluídos, mas descarta o último bloco que ainda estava em andamento no momento em que o turno termina. O que falta costuma ser algumas frases finais ou a última chamada de ferramenta.
continueÉ exatamente o procedimento de retomada da documentação oficial: o trabalho segue do último bloco concluído. Não repita a instrução desde o começo — isso reexecutaria operações que já rodaram.
Se a queda ocorreu no meio de uma escrita em arquivo ou de um comando, o registro da tela é a fonte do que chegou a ser executado. Veja o estado real com git status antes de seguir.
-p, Agent SDK, sessões na nuvem — se a resposta interrompida contiver apenas texto, sem chamadas de ferramenta, o próprio Claude Code pede a continuação ao Claude, até 3 vezes seguidas. Esse aviso só aparece depois que essas continuações se esgotam. Os subagentes também continuam sozinhos.
2. A definição oficial — as 4 mensagens de resposta interrompida
O primeiro ponto a fixar é que esse texto é um aviso que o próprio Claude Code acrescenta, e não o corpo de uma resposta de erro devolvida pela API. Por isso, dentro da mesma experiência de “cortou no meio”, o Claude Code muda a frase final conforme a causa. A referência oficial lista estas quatro.
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.
A explicação oficial cabe em uma frase — a conexão se perdeu. O stream fluía normalmente, mas a conexão que o transportava deixou de existir.
Ocorreu overloaded ou um 5xx no meio do stream. Pela documentação oficial, essa própria exibição existe desde a v2.1.199; antes disso a saída parcial era descartada e o turno inteiro virava erro.
Quando o Claude Code detecta que o computador entrou em suspensão durante a resposta. Ao voltar, ele trata a conexão como quebrada e para de ler.
A conexão continua aberta, mas os dados param de chegar e o temporizador de vigilância do stream encerra. É parada, não desconexão: causa e tratamento são outros.
Antes de tudo, identifique com precisão qual das quatro você viu. A experiência de “parou no meio” parece idêntica, mas o Claude Code já separou a causa antes de escolher a frase. Se aparece lost, o veredito é a conexão se perdeu, e não que o servidor devolveu 5xx nem que houve tempo esgotado.
3. Na v2.1.227, closed virou lost
Aqui está o centro deste artigo. Logo depois de listar as quatro explicações, a referência oficial de erros coloca esta observação.
“Antes da v2.1.227,Connection lost mid-responseaparecia comoConnection closed mid-response, eThe response stopped arrivingaparecia comoResponse stalled mid-stream”
— Referência oficial de erros do Claude Code (tradução do autor)
Ou seja, duas frases foram trocadas ao mesmo tempo. A correspondência fica assim.
| Exibição anterior à v2.1.227 | Exibição atual | Sentido (oficial) |
|---|---|---|
Connection closed mid-response |
Connection lost mid-response |
A conexão se perdeu |
Response stalled mid-stream |
The response stopped arriving |
A conexão seguiu aberta, mas os dados pararam de chegar |
Connection closed while thinking, before producing a response |
Connection lost before a response was produced |
Caiu antes de sair um único caractere (sem saída parcial) |
Response stalled while thinking, before producing a response |
The response stalled before a response was produced |
Parou com a conexão aberta antes de sair um único caractere |
Atenção: a terceira linha é outra coisa, diferente da mensagem deste artigo. mid-response significa “caiu depois que parte da saída já tinha aparecido”; before a response was produced significa “caiu sem que um único caractere saísse”. As duas passaram pela mesma renomeação, mas o sentido e o comportamento posterior são diferentes. O próximo capítulo trata disso em detalhe.
O que muda quando você conhece essa renomeação
Na prática, o efeito é triplo.
Pesquisando por “Connection closed mid-response”, o número de issues no GitHub e de artigos explicativos cresce de uma vez. É o mesmo fenômeno, então não há nada a reinterpretar.
Se aparece lost, aquele Claude Code é v2.1.227 ou posterior. Se aparece closed, é anterior a ela.
Como o mesmo fenômeno é relatado sob dois nomes, a busca por issues precisa cobrir as duas frases para não perder relatos existentes.
⚠️ Antes da v2.1.222 o aviso pode ser falso. A referência oficial de erros diz explicitamente que “versões do Claude Code anteriores à v2.1.222 também emitiam essa notificação quando a conexão caía ou estagnava depois de a resposta ter sido concluída, relatando como erro um turno que estava completo”. Ou seja, em versões antigas a saída chegava inteira e mesmo assim o erro aparecia. Se claude --version for menor que 2.1.222, atualize antes de começar qualquer isolamento — o erro que você vê pode não existir.
4. Por que não há nova tentativa automática
O Claude Code não fica parado. Segundo a seção “Automatic retries” da referência oficial, falhas temporárias são repetidas automaticamente até 10 vezes com backoff exponencial. Se ainda assim essa mensagem aparece, é porque o Claude Code decidiu que ali não se deve repetir.
O que separa os dois caminhos é um único critério: o Claude já tinha concluído alguma coisa?
Se a conexão cai sem que o Claude tenha concluído nenhuma parte da resposta, raciocínio incluído, o Claude Code reenvia a requisição com o mesmo backoff e o turno continua. Vale igualmente se o texto já tinha começado a fluir.
Se o raciocínio terminou mas nem texto nem chamada de ferramenta começaram, ele reenvia no máximo 2 vezes em intervalos curtos e, se continuar caindo, encerra o turno com Connection lost before a response was produced.
Se a queda ocorre depois de concluído um bloco de texto ou uma chamada de ferramenta (ou depois de iniciado algo após o raciocínio), o Claude Code não reenvia a requisição. Porque poderia executar a mesma chamada de ferramenta duas vezes.
Em vez disso, guarda o que foi concluído, executa as chamadas de ferramenta já concluídas e segue o turno a partir dos resultados. E então emite esse aviso.
Esse desenho parece incômodo, mas erra para o lado seguro. Se houvesse reenvio automático, operações com efeito colateral — reescrever um arquivo, executar um comando — poderiam rodar em duplicidade a cada queda. Por isso a orientação oficial é continue em vez de reenviar: é o único caminho que não refaz o trabalho já terminado.
O que aparece na tela durante as retentativas
Enquanto a repetição acontece, ao lado do indicador de atividade surge a contagem Retrying in Ns · attempt x/y. O rótulo começa como API error, mas desde a v2.1.198 ele passa ao motivo concreto a partir da terceira tentativa (se CLAUDE_CODE_MAX_RETRIES for menor que 3, a troca ocorre na última tentativa).
Além disso, se a requisição continua viva mas não chegam dados por 20 segundos, ainda antes de haver falha aparece o aviso Waiting for API response · will retry in … · check your network. Esse texto significa “ainda não falhou”, e a contagem aponta o momento em que o Claude Code encerraria a conexão estagnada. Pela documentação oficial, esse limiar era de 10 segundos antes da v2.1.185, com outra redação.
5. Onde a conexão se rompe — as 3 camadas
Saber apenas que “a conexão se perdeu” não define a ação. Há basicamente três lugares onde ela pode se romper, e a forma de verificar é diferente em cada um.
Troca de rede Wi-Fi, microcortes da rede móvel, suspensão do computador, reconexão do cliente de VPN.
Como verificar: reproduzir em rede cabeada ou em outra conexão. Se a causa for a suspensão, aparece uma frase própria, o que já resolve o isolamento.
Proxy corporativo, inspeção de TLS, gateway de LLM, VPN. Não é raro um equipamento tratar como ocioso um stream que fica aberto por muito tempo e cortá-lo.
Como verificar: reproduzir sem HTTPS_PROXY. Confira a linha de proxy com /status.
Incidente do lado do serviço, ou uma conexão reaproveitada que na verdade já estava morta. A marca é continuar caindo com a rede local sadia.
Como verificar: consultar status.claude.com. Se reproduz igual em várias conexões, o problema não é só local.
claude --debug traz Stale connection — reloaded rotated mTLS client material.
6. O que testar agora — checklist de isolamento
A ordem é de cima para baixo, do maior efeito com menor esforço. Verifique se o problema se repete a cada item testado.
| # | O que fazer | Objetivo |
|---|---|---|
| 1 | Responder continue | Antes de tudo, não consolidar a perda. É mais rápido que refazer e não corre risco de execução dupla |
| 2 | Atualizar o Claude Code | O comportamento de conexão muda com a versão. A v2.1.198 corrigiu o problema de uma queda curta de rede no meio da resposta interromper o turno |
| 3 | Dividir o turno em partes menores | Separar “ler muitos arquivos e escrever um relatório” em leitura e redação. Reduz o próprio tempo em que o stream fica aberto |
| 4 | Reproduzir sem VPN e sem proxy | Isolamento da camada 2. Se resolve ao remover, suspeite de corte por ociosidade no caminho |
| 5 | Reproduzir em outra conexão | Isolamento entre as camadas 1 e 3. Se o resultado é igual em várias conexões, não é só local |
| 6 | Revisar as configurações de suspensão | Se a tela apaga durante respostas longas, a conexão pode se quebrar antes de sair a frase específica de suspensão |
| 7 | Consultar status.claude.com | Confirmação da camada 3. No caso de 529, o próprio Claude Code exibe esse endereço na tela |
| 8 | Registrar com claude --debug | O log sai em ~/.claude/debug/<session-id>.txt. Anexe-o ao relatar o problema |
| 9 | Verificar se há proxy SOCKS em uso | A documentação oficial declara proxy SOCKS sem suporte. Se estiver usando, mude o caminho |
7. Ajustar temporizadores e retentativas por variáveis de ambiente
O Claude Code tem quatro temporizadores independentes para encerrar um stream que ficou silencioso. A lista da documentação oficial de configuração de rede é esta.
| Temporizador | Condição de encerramento | Tempo limite padrão |
|---|---|---|
| First-byte deadline | Nenhum cabeçalho de resposta chega após o envio | 180 s na API direta, 300 s nos demais (mais 1 s a cada 32 KB de corpo da requisição) |
| Event-level watchdog | Nenhum evento da resposta consegue ser analisado | 300 s (vale para todos os provedores) |
| Byte-level watchdog | Nenhum byte chega, nem os pings de keep-alive do SSE | 180 s na API direta, 300 s nos demais |
| Body idle timeout | Nenhum byte chega por 5 minutos | 5 minutos (para provedores fora da API direta) |
Só que o resultado desses temporizadores cai, em geral, no lado do silêncio — é outra mensagem, não a deste artigo. Ela está aqui porque é preciso conhecer os valores padrão para distinguir os dois casos, e não porque “apareceu lost, vamos aumentar o temporizador”. Em ambientes atrás de proxy com longos períodos de silêncio, mexer nesses valores altera os sintomas do lado da parada.
Do lado das retentativas, o ajuste vem por estas variáveis.
| Variável de ambiente | Padrão | Efeito |
|---|---|---|
CLAUDE_CODE_MAX_RETRIES |
10 | Número de retentativas. Desde a v2.1.186 o teto é 15. Em scripts, recomenda-se baixar o valor para falhar mais cedo |
CLAUDE_CODE_RETRY_WATCHDOG |
Não definida | Para sessões sem operador, como CI. Com 1, repete 429 e 529 indefinidamente e, desde a v2.1.199, eleva para 300 a contagem padrão dos erros temporários, quedas incluídas |
API_TIMEOUT_MS |
600000 | Tempo limite por requisição (em milissegundos, ou seja, 10 minutos). Aumente em conexões lentas ou atrás de proxy |
CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS |
Não definida | Tempo limite somente da vigilância de bytes. Fica restrito entre 10 segundos e 30 minutos |
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS |
Não definida | Define diretamente o prazo até o primeiro byte. Disponível a partir da v2.1.242 |
CLAUDE_CODE_MAX_RETRIES ajuda nas falhas do tipo “cai antes de sair a saída”, e não na interrupção no meio. O que ajuda é encurtar o turno.
8. Como distinguir das mensagens parecidas
Talvez esta seja a parte mais útil na prática. A experiência de “parou no meio” é comum a todas, mas o texto que o Claude Code exibe é diferente, e causa e tratamento também. Segue a organização, incluindo a correspondência com artigos já publicados neste site.
| Texto exibido na tela | O que está acontecendo | O que ler |
|---|---|---|
Connection lost mid-response |
A conexão se perdeu depois de parte da saída já ter aparecido | Este artigo |
Connection closed mid-response |
Nome antigo do mesmo fenômeno (anterior à v2.1.227) | O artigo sobre closed, que reúne os relatos da época do nome antigo |
The response stopped arrivingAntes: Response stalled mid-stream |
A conexão está viva, mas ficou em silêncio e o temporizador encerrou | O artigo sobre stalled (atenção ao encadeamento com loops de repetição) |
Server error mid-response |
No meio do stream, 5xx ou overloaded do lado do servidor | O artigo sobre 529 e 500 |
Your computer went to sleep mid-response |
O Claude Code detectou que o computador entrou em suspensão durante a resposta | Revisar energia e suspensão (capítulo 6 deste artigo) |
Connection lost before a response was produced |
Caiu sem sair um único caractere (sem saída parcial) | É objeto de nova tentativa. Capítulo 4 deste artigo |
Unable to connect e erros de certificado SSL |
A conexão nem chega a ser estabelecida | O artigo sobre rede e proxy |
Tags court e invoke aparecem no corpo |
Não é comunicação: a chamada de ferramenta não é executada | O artigo sobre a tag court |
A maior bifurcação é se apareceu ou não resposta na tela. Se não saiu um único caractere, a vez é de suspeitar da conexão e das configurações (proxy, certificado, firewall). Se saiu parte da resposta, isso já prova que a conexão existia, e o certo é seguir o isolamento deste artigo em vez de mexer em configuração.
O segundo desvio é entre queda e silêncio
Perder a conexão ou ficar mudo com ela aberta leva a ações opostas.
Suspeite do caminho e do reuso de conexão. Aumentar o tempo limite não adianta — não foi tempo esgotado, foi a própria conexão que deixou de existir.
É a vez dos temporizadores. Ajustar CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS e afins pode surtir efeito, e vale suspeitar de situações em que o modelo fica muito tempo em silêncio.
9. Relatos reais — o ECONNRESET que não para
O caso mais espinhoso é aquele em que a rede local está perfeitamente sadia e só o Claude Code continua caindo. Há duas issues públicas com um volume considerável de verificação. Ambas foram relatadas com o nome novo desta mensagem ou trazem o texto da versão imediatamente anterior.
O autor escreve que, depois de Connection dropped (ECONNRESET) · Retrying in 17s · attempt 6/10, aparece API Error: Connection lost mid-response.. Relata ainda que um POST de 60 KB via curl e um POST do mesmo tamanho via https.request em Node.js puro completaram normalmente, e que um SSE de longa duração vindo de outro host também não foi interrompido.
Depois de checar MTU, verificar Winsock LSP, reproduzir em configuração mínima e reproduzir em duas redes sem relação entre si, o caso segue sem solução. A Issue #86473 foi marcada como duplicada e continua aberta.
Neste caso é Connection dropped (ECONNRESET) · Retrying in 0s · attempt 4/10. O autor conta que desinstalou por completo o antivírus, eliminou filtros de VPN, proxy e IPv6 e reiniciou o Winsock, e mesmo assim reproduziu igual em três redes: Wi-Fi da empresa, Wi-Fi de casa e roteamento pelo celular.
Ele apresenta o contraste de que, no mesmo aparelho e na mesma conta, o chat do claude.ai funciona sem problema. A Issue #85979 também continua aberta (marcada como stale).
Ainda assim, há algo prático a extrair desses dois casos: “o ping passa” e “o curl passa” não são prova de que esse erro não vai ocorrer. Uma comunicação que mantém uma única conexão aberta por vários minutos em streaming está em condições diferentes de uma requisição curta. Em vez de investir tempo em inspeções da rede local, dividir o turno em partes menores costuma reduzir mais a taxa de reincidência.
10. O que está confirmado e o que não está
Para evitar mal-entendidos, vale separar o que dá para confirmar oficialmente do que não dá.
- O texto consta formalmente da referência oficial de erros e significa que a conexão se perdeu
- Antes da v2.1.227 aparecia como
Connection closed mid-response(renomeação da mesma coisa) - A saída que já tinha fluído é preservada de propósito (reenviar arriscaria execução dupla)
- O procedimento de retomada é responder
continue - Quedas antes de sair a saída têm nova tentativa automática (até 10 vezes, com backoff exponencial)
- Sessões não interativas e subagentes continuam sozinhos (a partir da v2.1.246 e da v2.1.257, respectivamente)
- HTTPS puro sadio e só a CLI caindo com ECONNRESET (relatos das #86473 e #85979)
- O contraste de a versão web ir bem no mesmo aparelho e na mesma conta (relato da #85979)
- A possibilidade de haver uma falha de reaproveitamento de conexões envolvida (explicação do suporte citada pelo autor)
- A menção a incidentes do lado do servidor em datas específicas (também via autor do relato)
- Uma explicação oficial de causa pela Anthropic (as duas issues acima não têm resposta pública)
- O motivo da renomeação. Não se encontra registro da mudança de texto no CHANGELOG
- As #86473 e #85979 seguem abertas
Em suma, sintoma, sentido e procedimento de retomada estão documentados oficialmente, mas a explicação oficial do porquê da queda ainda não saiu. Nesse cenário, o que funciona com certeza não é identificar a causa, e sim operar de modo a minimizar a perda quando cair: dividir o turno em partes menores, avançar conferindo o estado nas operações com efeito colateral e manter a versão atualizada. Esses três funcionam qualquer que seja a causa.
FAQ
Q1. Connection lost mid-response e Connection closed mid-response são erros diferentes?
São a mesma coisa. Como declara a referência oficial de erros, antes da v2.1.227 o mesmo fenômeno era exibido como Connection closed mid-response. A troca de exibição não significa que surgiu um novo tipo de falha. O material escrito com o nome antigo continua consultável tal como está.
Q2. A saída anterior é perdida?
Não. Todos os blocos que o Claude concluiu permanecem. O que se descarta é apenas o último bloco que ainda estava em andamento quando o turno terminou. O Claude Code deixa de propósito de reenviar e acrescenta esse aviso porque um reenvio correria o risco de executar a mesma chamada de ferramenta duas vezes.
Q3. O que responder para retomar de onde parou?
Responda continue. É o procedimento de retomada indicado pela referência oficial de erros, e faz o trabalho seguir do último bloco concluído. Repetir a instrução desde o começo pode duplicar operações que já foram executadas.
Q4. Aumentar o número de retentativas resolve?
Não resolve. Como mostra o capítulo 4, este é o aviso de uma situação em que o Claude Code evita repetir de propósito. CLAUDE_CODE_MAX_RETRIES (padrão 10, com teto 15 desde a v2.1.186) atua nas falhas do tipo “cai antes de sair a saída”. O que funciona é encurtar o turno.
Q5. Com -p ou em CI (execução não interativa) é igual?
O comportamento é diferente. Segundo a referência oficial, em sessões não interativas, se a resposta interrompida contiver apenas texto, sem chamadas de ferramenta, o próprio Claude Code pede a continuação, até 3 vezes seguidas. Esse aviso aparece depois de esgotadas essas continuações. Antes da v2.1.246, a primeira queda já encerrava o turno. Se você usa --output-format json, esta mensagem entra no campo result.
Q6. Também aparece em subagentes (Task).
Os subagentes também continuam automaticamente. Se a resposta interrompida for só texto, o Claude Code pede a continuação ao subagente, e só depois de esgotadas as continuações é que esse aviso vira a última mensagem. Antes da v2.1.257, o aviso saía já na primeira queda.
Q7. A culpa é da minha rede?
Pode ser, mas não necessariamente só isso. O autor da Issue #86473 mostrou que POSTs do mesmo tamanho por curl e por Node.js puro completaram os dois, e relata que só a CLI cai. Verifique primeiro se o problema se repete sem VPN e sem proxy e, depois, teste em outra conexão. Se nada mudar nos dois testes, dá para concluir que não é um problema apenas local.
Q8. Aumentar o tempo limite reduz a ocorrência?
Para esta mensagem, não há o que esperar. O veredito é que a conexão se perdeu, não que o tempo se esgotou. Aumentar os temporizadores (como CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS) surte efeito em The response stopped arriving, ou seja, no sintoma em que a conexão está viva mas fica em silêncio.
Q9. Como saber qual versão estou usando?
Com claude --version. Se a tela mostra lost, é v2.1.227 ou posterior; se mostra closed, é anterior. O comportamento de conexão mudou com as versões e, no CHANGELOG oficial, a v2.1.198 corrigiu o problema de uma queda curta de rede no meio da resposta interromper o turno. Atualizar é a primeira medida de melhor custo-benefício, mas não garante a cura — as duas issues citadas acima são relatos em versões mais novas que essa.
Q10. Ocorre com frequência na rede corporativa. Que configurações olhar?
A documentação oficial de configuração de rede cobre o essencial. São três pontos: 1) proxy SOCKS não tem suporte, então não o use; 2) as variáveis de proxy vão no bloco env de ~/.claude/settings.json, e não em um export do shell (porque o ambiente do shell não chega aos agentes em segundo plano); 3) se você usa mTLS, atenção à rotação de certificados. Para saber se a configuração foi lida, veja o log de claude --debug ou a exibição de /status.
Artigos relacionados
- API Error: Connection closed mid-response — causas e solução para respostas interrompidas no Claude Code
- Quando court entra em loop infinito no Claude Code e tudo para em Response stalled mid-stream — causas e solução
- Erros de rede, proxy e certificado TLS no Claude Code (Unable to connect) — causas e solução
- Erros de servidor 529 Overloaded e 500 no Claude Code — causas e solução
- Quando o Claude Code imprime court e tags invoke — causas e solução do erro em que a ferramenta não é executada
- Resumo dos erros mais comuns do Claude Code e como resolvê-los
Fontes primárias consultadas
- Claude Code — Error reference (documentação oficial): definição das quatro frases, renomeação da v2.1.227, retomada por
continue, bifurcação dos Automatic retries, variáveis de ambiente - Claude Code — Enterprise network configuration (documentação oficial): os quatro temporizadores de vigilância de stream e seus valores padrão, configuração de proxy, ausência de suporte a SOCKS, releitura de mTLS
- anthropics/claude-code — CHANGELOG (oficial): correção na v2.1.198 do problema de uma queda curta de rede no meio da resposta interromper o turno
- Issue #86473 — ECONNRESET / Connection lost mid-response (v2.1.229, Windows 11)
- Issue #85979 — ECONNRESET persiste na v2.1.228 (Windows 11)
- Situação dos serviços do Claude (página oficial de status)
