Índice
- 1. Lo primero que hay que hacer: la salida en pantalla no se ha perdido
- 2. La definición oficial: los cuatro mensajes de corte a media respuesta
- 3. En v2.1.227 se renombró de «closed» a «lost»
- 4. Por qué no se reintenta de forma automática
- 5. ¿Dónde se está cortando? Las tres capas
- 6. Qué probar ahora: lista de comprobación
- 7. Ajustar temporizadores y reintentos con variables de entorno
- 8. Cómo distinguirlo de los mensajes parecidos
- 9. Informes reales: el caso del ECONNRESET que no para
- 10. Lo que está confirmado y lo que no
- Preguntas frecuentes
Cuando le encargas a Claude Code un trabajo algo largo, a veces se detiene de golpe en mitad de la respuesta con este mensaje.
API Error: Connection lost mid-response. The response above may be incomplete.
Si buscas ese texto tal cual, aparece muy poca información. El motivo está claro: es un nombre relativamente nuevo. La referencia oficial de errores de Claude Code lo dice con estas mismas palabras: «antes de v2.1.227, Connection lost mid-response se mostraba como Connection closed mid-response». Es decir, el fenómeno existía desde antes y lo único que cambió fue la palabra que aparece en pantalla: closed pasó a ser lost. Como todo lo que ya se había escrito en la red usa el nombre antiguo, quien busca por el nombre nuevo se queda sin encontrar nada.
Este artículo parte de ese cambio de nombre y ordena, apoyándose solo en la documentación oficial y en las incidencias públicas, seis cosas: 1) el significado exacto del mensaje, 2) qué hacer ahora mismo delante de la pantalla, 3) por qué no se reintenta de forma automática, 4) cómo aislar la capa donde se corta, 5) los ajustes mediante variables de entorno y 6) la diferencia con otros mensajes muy parecidos. Allí donde entra algo de conjetura, lo etiqueto con su nivel de certeza.
Lo que ya salió por pantalla no se ha borrado. Si respondes continue, la documentación oficial indica que retoma desde el último bloque completado.
Antes de v2.1.227 se mostraba como Connection closed mid-response. La información escrita con el nombre antiguo te sirve igual.
La solución cambia según si el corte ocurre en tu equipo, en el camino o del lado del servidor. Hay informes en los que el HTTPS puro pasa y solo Claude Code se cae.
1. Lo primero que hay que hacer: la salida en pantalla no se ha perdido
Antes de ponerse a arreglar nada, conviene despejar el malentendido más frecuente. Aunque salga este mensaje, todo el contenido que ya había aparecido en pantalla se conserva. No se tira.
La referencia oficial de errores explica así el grupo de mensajes que terminan en «The response above may be incomplete.»: si el streaming falla después de que Claude haya completado un bloque de texto o una llamada de herramienta, reenviar la petición podría ejecutar dos veces esa misma llamada, así que Claude Code conserva lo ya completado y añade esta nota en lugar de descartar el turno.
Por lo tanto, solo hay tres cosas que hacer.
Claude Code conserva todos los bloques completados, pero descarta el último bloque que estuviera a medias cuando termina el turno. Lo que falta suele ser una o dos frases finales, o la última llamada de herramienta.
continueEs el procedimiento de recuperación oficial. Hace que siga desde el último bloque completado. No repitas la instrucción desde cero: acabarías ejecutando otra vez operaciones que ya se hicieron.
Si el corte llegó en mitad de una escritura de archivo o de un comando, lo que manda para saber hasta dónde se ejecutó es el registro en pantalla. Mira el estado real con git status antes de seguir.
-p, el Agent SDK o las sesiones en la nube, si la respuesta cortada es solo texto y no incluye llamadas de herramienta, Claude Code le pide a Claude que siga por su cuenta, hasta tres veces seguidas como máximo. Esta nota aparece únicamente cuando esas continuaciones ya se han agotado. Los subagentes continúan solos de la misma forma.
2. La definición oficial: los cuatro mensajes de corte a media respuesta
Lo primero que conviene entender es que este texto es una nota que añade el propio Claude Code, no el cuerpo de una respuesta de error devuelta por la API. Por eso, aunque la experiencia sea siempre «se cortó a la mitad», Claude Code cambia la última parte del texto según la causa. La referencia oficial enumera estos cuatro casos.
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.
La explicación oficial cabe en una frase: la conexión se perdió. El flujo llegaba bien, pero la conexión que lo transportaba desapareció.
Un overloaded o un 5xx aparecido en mitad del flujo. Según la documentación oficial, este texto existe a partir de v2.1.199; antes se descartaba la salida parcial y se marcaba todo el turno como error.
Cuando Claude Code detecta que el ordenador se suspendió durante la respuesta. Al volver da la conexión por rota y deja de leer.
Cuando la conexión sigue abierta pero dejan de llegar datos y el temporizador de vigilancia del flujo corta. No es una desconexión sino una parada, y tanto la causa como la solución son otras.
Lo primero es leer con precisión cuál de los cuatro te ha tocado. La experiencia de «se cortó a la mitad» parece idéntica en todos, pero Claude Code ya ha discriminado la causa antes de elegir el texto. Si pone lost, su veredicto es que la conexión se perdió, no que el servidor devolviera un 5xx ni que se agotara un tiempo de espera.
3. En v2.1.227 se renombró de «closed» a «lost»
Aquí está el centro de este artículo. La referencia oficial de errores coloca, justo después de esas cuatro explicaciones, esta advertencia.
«Antes de v2.1.227,Connection lost mid-responsese mostraba comoConnection closed mid-response, yThe response stopped arrivingse mostraba comoResponse stalled mid-stream».
— Referencia oficial de errores de Claude Code, traducción propia
O sea que se cambiaron dos textos a la vez. Puesta en tabla, la correspondencia queda así.
| Texto anterior a v2.1.227 | Texto actual | Significado oficial |
|---|---|---|
Connection closed mid-response |
Connection lost mid-response |
La conexión se perdió |
Response stalled mid-stream |
The response stopped arriving |
La conexión sigue abierta pero dejaron de llegar datos |
Connection closed while thinking, before producing a response |
Connection lost before a response was produced |
Se cortó antes de que saliera ni un carácter, sin salida parcial |
Response stalled while thinking, before producing a response |
The response stalled before a response was produced |
Se paró con la conexión abierta antes de salir ni un carácter |
Ojo con la tercera fila: no es el mensaje de este artículo. mid-response significa «se cortó después de que hubiera salido parte de la respuesta» y before a response was produced significa «se cortó sin que saliera ni un carácter». Entran en el mismo cambio de nombre, pero tienen otro significado y otro comportamiento posterior. Lo veremos en detalle en el capítulo siguiente.
Qué cambia cuando conoces este renombrado
En la práctica tiene tres efectos.
Si buscas «Connection closed mid-response», aparecen de golpe muchas más incidencias de GitHub y muchos más artículos. Es el mismo fenómeno, no hay que reinterpretar nada.
Si en pantalla pone lost, sabes que ese Claude Code es v2.1.227 o posterior. Si pone closed, es anterior.
Como el mismo fenómeno está reportado con dos nombres, si no buscas con los dos textos se te escapan informes que ya existían.
⚠️ Antes de v2.1.222 el aviso podía ser directamente falso. La referencia oficial de errores deja escrito que «las versiones de Claude Code anteriores a v2.1.222 emitían esta notificación también cuando la conexión se perdía o se estancaba después de completarse la respuesta, y reportaban como error un turno que estaba completo». Es decir, en las versiones antiguas puede aparecer el error aunque toda la salida haya llegado. Si claude --version te devuelve algo menor que 2.1.222, actualiza antes de empezar a diagnosticar: puede que el error que ves no exista.
4. Por qué no se reintenta de forma automática
No es que Claude Code no haga nada. Según el apartado «Automatic retries» de la referencia oficial, los fallos transitorios se reintentan solos hasta diez veces con retroceso exponencial. Que aun así aparezca este mensaje significa que Claude Code ha decidido que aquí no debe reintentar.
Lo único que decide la bifurcación es si Claude ya había completado algo.
Si la conexión cae sin que Claude haya completado ninguna parte de la respuesta, ni siquiera el razonamiento, Claude Code reenvía la petición con el mismo retroceso y el turno continúa. Da igual que el texto ya hubiera empezado a fluir.
Si el razonamiento ya terminó pero no ha empezado ni el texto ni ninguna llamada de herramienta, reenvía hasta dos veces con intervalos cortos y, si sigue cayendo, cierra el turno con Connection lost before a response was produced.
Si el corte llega después de haber completado un bloque de texto o una llamada de herramienta, o de haberla iniciado tras el razonamiento, Claude Code no reenvía la petición. El motivo es que podría ejecutar dos veces la misma llamada de herramienta.
En su lugar conserva lo completado, ejecuta las llamadas de herramienta ya completas y sigue el turno a partir de ese resultado. Y entonces añade esta nota.
El diseño parece incómodo, pero en realidad se inclina al lado seguro. Si reenviara solo, las operaciones con efectos secundarios como reescribir un archivo o ejecutar un comando correrían dos veces con cada corte. Por eso la documentación oficial recomienda responder continue en lugar de reenviar: es la única vía que no obliga a repetir el trabajo ya hecho.
Qué se ve en pantalla durante los reintentos
Mientras corre un reintento, junto al indicador de progreso aparece la cuenta atrás Retrying in Ns · attempt x/y. La etiqueta empieza siendo API error, pero a partir de v2.1.198 cambia al motivo concreto desde el tercer intento; si CLAUDE_CODE_MAX_RETRIES es menor que tres, cambia en el último intento.
Además, si la petición sigue viva pero pasan veinte segundos sin datos, aparece el aviso Waiting for API response · will retry in … · check your network en una fase en la que todavía no ha fallado nada. Es un indicador de que aún no ha fallado, y la cuenta atrás marca el momento en que Claude Code cortará la conexión estancada. Según la documentación oficial, ese umbral eran diez segundos antes de v2.1.185, con otro texto.
5. ¿Dónde se está cortando? Las tres capas
Que te digan solo «la conexión se perdió» no basta para decidir qué hacer. Los sitios donde puede cortarse son básicamente tres, y cada uno se comprueba de una forma distinta.
Cambios de red wifi, microcortes de la línea móvil, suspensión del equipo, reconexiones del cliente VPN.
Cómo comprobarlo: mira si se reproduce por cable o en otra línea. Si la causa es la suspensión, aparece un texto específico para ello y ahí ya lo tienes aislado.
Proxy corporativo, inspección TLS, pasarelas de LLM, VPN. No es raro que un equipo intermedio considere inactivo un flujo que lleva mucho rato abierto y lo corte.
Cómo comprobarlo: mira si se reproduce quitando HTTPS_PROXY. Revisa la línea de proxy con /status.
Una incidencia del servicio, o una conexión reutilizada que en realidad estaba muerta. Se reconoce porque la línea local está sana y aun así sigue cayendo.
Cómo comprobarlo: consulta status.claude.com. Si se reproduce igual en varias líneas, el problema no es solo tuyo.
claude --debug aparece Stale connection — reloaded rotated mTLS client material.
6. Qué probar ahora: lista de comprobación
Está ordenada de arriba abajo por mayor efecto y menor esfuerzo. Comprueba si se reproduce después de cada intento.
| # | Qué hacer | Para qué |
|---|---|---|
| 1 | Responder continue | Lo primero es no dar por perdido el trabajo. Es más rápido que repetir y no arriesga una doble ejecución |
| 2 | Actualizar Claude Code a la última versión | El comportamiento de la conexión cambia entre versiones. En v2.1.198 se corrigió que un corte de red breve a media respuesta interrumpiera el turno |
| 3 | Partir el turno en trozos más cortos | Separa «leer muchos archivos y escribir un informe» en lectura y redacción. Reduce el tiempo que el flujo pasa abierto |
| 4 | Reproducirlo sin VPN ni proxy | Aísla la capa 2. Si al quitarlos se arregla, sospecha de un corte por inactividad en el camino |
| 5 | Reproducirlo en otra línea | Aísla las capas 1 y 3. Si pasa igual en varias líneas, el problema no es solo tuyo |
| 6 | Revisar los ajustes de suspensión | Si la pantalla se apaga en mitad de respuestas largas, puede que la conexión se rompa antes de que salga el texto específico de suspensión |
| 7 | Consultar status.claude.com | Comprobación de la capa 3. Ante un 529, el propio Claude Code muestra ese nombre de host en pantalla |
| 8 | Registrar la sesión con claude --debug | El registro sale en ~/.claude/debug/<session-id>.txt. Adjúntalo cuando reportes el problema |
| 9 | Comprobar si estás usando un proxy SOCKS | La documentación oficial deja escrito que los proxy SOCKS no están soportados. Si lo usas, cambia de camino |
7. Ajustar temporizadores y reintentos con variables de entorno
Claude Code tiene cuatro temporizadores independientes para cortar un flujo que se ha quedado en silencio. La lista que recoge la documentación oficial de configuración de red es esta.
| Temporizador | Cuándo corta | Tiempo de espera por defecto |
|---|---|---|
| First-byte deadline | Tras enviar, no llega ninguna cabecera de respuesta | 180 s con la API directa y 300 s en el resto, más 1 s por cada 32 KB de cuerpo de la petición |
| Event-level watchdog | No se puede parsear ningún evento de la respuesta | 300 s, activo con todos los proveedores |
| Byte-level watchdog | No llega ni un byte, ni siquiera los ping de keep-alive de SSE | 180 s con la API directa y 300 s en el resto |
| Body idle timeout | Pasan cinco minutos sin recibir bytes | 5 minutos, pensado para proveedores distintos de la API directa |
Ahora bien, lo que estos temporizadores producen al cortar es, en principio, el texto del lado «silencio», que no es el mensaje de este artículo. Los incluyo porque hace falta conocer los valores por defecto para distinguir los dos casos, no porque «salga lost, así que alarguemos el temporizador». Si trabajas tras un proxy y sufres silencios largos, tocar estos valores sí cambia los síntomas del lado de la parada.
Del lado de los reintentos, se ajustan con estas variables.
| Variable de entorno | Por defecto | Efecto |
|---|---|---|
CLAUDE_CODE_MAX_RETRIES |
10 | Número de reintentos. Desde v2.1.186 el máximo es 15. En los scripts se recomienda bajarlo para fallar antes |
CLAUDE_CODE_RETRY_WATCHDOG |
Sin definir | Para sesiones desatendidas como CI. Con 1 reintenta los 429 y 529 de forma indefinida y, desde v2.1.199, sube a 300 el número por defecto para los errores transitorios, cortes incluidos |
API_TIMEOUT_MS |
600000 | Tiempo de espera por petición, en milisegundos, o sea diez minutos. Súbelo en líneas lentas o tras un proxy |
CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS |
Sin definir | Tiempo de espera solo para la vigilancia de bytes. Se acota entre 10 segundos y 30 minutos |
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS |
Sin definir | Fija directamente el plazo hasta el primer byte. Disponible desde v2.1.242 |
CLAUDE_CODE_MAX_RETRIES sirve para el otro tipo de fallo, el que cae antes de que salga la respuesta, y no hace nada por lo que se cortó a la mitad. Lo que sí sirve es acortar cada turno.
8. Cómo distinguirlo de los mensajes parecidos
Puede que esta sea la parte más útil para quien lee. Aunque la experiencia de «se paró a la mitad» sea común, el texto que muestra Claude Code cambia, y con él la causa y la solución. Lo ordeno incluyendo la correspondencia con los artículos que ya hay en este sitio.
| Texto que aparece en pantalla | Qué está pasando | Dónde leer |
|---|---|---|
Connection lost mid-response |
Se perdió la conexión tras salir parte de la respuesta | Este artículo |
Connection closed mid-response |
Nombre antiguo del mismo fenómeno, anterior a v2.1.227 | El artículo sobre closed, que recoge los informes de la época del nombre antiguo |
The response stopped arrivingAntes: Response stalled mid-stream |
La conexión sigue viva pero se queda en silencio y el temporizador corta | El artículo sobre stalled, atento al encadenamiento con el bucle de repeticiones |
Server error mid-response |
Un 5xx u overloaded del servidor a mitad del flujo | El artículo sobre el 529 y el 500 |
Your computer went to sleep mid-response |
Claude Code detectó que el equipo se suspendió durante la respuesta | Revisa los ajustes de energía y suspensión, en el capítulo 6 de este artículo |
Connection lost before a response was produced |
Se cortó sin que saliera ni un carácter, sin salida parcial | Entra en los reintentos. Ver el capítulo 4 de este artículo |
Unable to connect o errores de certificado SSL |
Directamente no se llega a conectar | El artículo sobre red y proxy |
Aparecen etiquetas court o invoke en el cuerpo |
No es la comunicación: la llamada de herramienta no se ejecuta | El artículo sobre la etiqueta court |
La bifurcación más importante es si llegó a aparecer respuesta en pantalla. Si no salió ni un carácter, toca sospechar de la conexión y de la configuración: proxy, certificados, cortafuegos. Si salió parte, eso demuestra que la conexión funcionaba, así que es más correcto pasar al diagnóstico de este artículo que ponerse a tocar ajustes.
La segunda bifurcación: ¿corte o silencio?
Que la conexión se haya perdido o que siga abierta callada lleva a movimientos opuestos.
Sospecha del camino y de la reutilización de conexiones. Alargar los tiempos de espera no sirve de nada: no se agotó el tiempo, es que la conexión ha desaparecido.
Aquí sí entran los temporizadores. Ajustar CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS y compañía tiene margen de efecto, y también cabe sospechar que el modelo esté callado mucho rato.
9. Informes reales: el caso del ECONNRESET que no para
Lo más molesto es el patrón en el que la línea local está perfectamente sana y solo Claude Code sigue cayéndose. Hay dos informes públicos con un trabajo de verificación bastante amplio. Ambos están reportados con el nombre nuevo de este artículo o incluyen el texto de la versión inmediatamente anterior.
Quien reporta escribe que, tras Connection dropped (ECONNRESET) · Retrying in 17s · attempt 6/10, aparece API Error: Connection lost mid-response.. Y añade que tanto un POST de 60 KB con curl como un POST del mismo tamaño con https.request de Node.js puro terminan correctamente, y que un SSE largo desde otro host tampoco se interrumpió.
Comprobó la MTU, revisó los LSP de Winsock, lo reprodujo con una configuración mínima y lo reprodujo en dos redes sin relación entre sí, y aun así sigue sin resolverse. La incidencia #86473 está marcada como duplicada pero continúa abierta.
Aquí es Connection dropped (ECONNRESET) · Retrying in 0s · attempt 4/10. Quien reporta desinstaló por completo el antivirus y descartó los filtros de VPN, el proxy, IPv6 y Winsock reiniciándolo, y escribe que lo reprodujo igual en tres redes: wifi de la oficina, wifi de casa y datos compartidos del móvil.
Muestra el contraste de que, con el mismo equipo y la misma cuenta, el chat de claude.ai funciona sin problemas. La incidencia #85979 también sigue abierta, marcada como inactiva.
Aun así, de estos dos casos se saca algo práctico: que el ping pase o que curl funcione no demuestra que este error no vaya a ocurrir. Una comunicación que mantiene una sola conexión abierta durante minutos con streaming tiene condiciones distintas a las de una petición corta. En lugar de invertir tiempo en inspeccionar tu red, resulta más fácil bajar la tasa de reproducción partiendo los turnos.
10. Lo que está confirmado y lo que no
Para evitar malentendidos, separo lo que se puede verificar oficialmente de lo que no.
- Este texto figura formalmente en la referencia oficial de errores y significa que la conexión se perdió
- Antes de v2.1.227 se mostraba como
Connection closed mid-response, es el mismo caso renombrado - La salida que ya había fluido se conserva a propósito, porque reenviar podría duplicar una ejecución
- El procedimiento de recuperación es responder
continue - Los cortes anteriores a que salga la respuesta se reintentan solos, hasta diez veces con retroceso exponencial
- Las sesiones no interactivas y los subagentes continúan por su cuenta, desde v2.1.246 y v2.1.257 respectivamente
- Que el HTTPS puro esté sano y solo la CLI caiga con ECONNRESET, según los informes #86473 y #85979
- El contraste de que en el mismo equipo y con la misma cuenta la versión web va bien, según el informe #85979
- La posible implicación de un fallo en la reutilización de conexiones, según la explicación del soporte que cita quien reporta
- La mención a una incidencia del servidor en unas fechas concretas, también a través de quien reporta
- Una explicación oficial de la causa por parte de Anthropic, no hay respuesta pública en ninguna de las dos incidencias
- El motivo del renombrado. No consta el cambio de texto en el CHANGELOG
- La #86473 y la #85979 siguen ambas abiertas
En resumen: el síntoma, el significado y el procedimiento de recuperación están documentados oficialmente, pero todavía no hay explicación oficial de por qué se corta. En esta situación, lo que funciona con seguridad no es identificar la causa sino trabajar de forma que un corte cueste lo mínimo: partir los turnos, avanzar comprobando el estado en las operaciones con efectos secundarios y mantener la versión al día. Estas tres cosas sirven sea cual sea la causa.
Preguntas frecuentes
1. ¿«Connection lost mid-response» y «Connection closed mid-response» son errores distintos?
Son el mismo. Tal como deja escrito la referencia oficial de errores, antes de v2.1.227 el mismo fenómeno se mostraba como Connection closed mid-response. Que haya cambiado el texto no significa que haya aparecido un tipo nuevo de fallo. La información escrita con el nombre antiguo se puede seguir consultando tal cual.
2. ¿Se pierde la salida anterior?
No se pierde. Todos los bloques que Claude completó se conservan. Lo único que se descarta es el último bloque que estuviera a medias cuando terminó el turno. Si Claude Code añade esta nota en lugar de reenviar es porque reenviar podría ejecutar dos veces la misma llamada de herramienta.
3. ¿Qué hay que responder para retomar desde donde se quedó?
Responde continue. Es el procedimiento de recuperación que indica la referencia oficial de errores, y hace que siga desde el último bloque completado. Si repites la instrucción desde cero, corres el riesgo de duplicar operaciones ya ejecutadas.
4. ¿Se arregla subiendo el número de reintentos?
No se arregla. Como vimos en el capítulo 4, esta es la nota de un momento en el que Claude Code evita reintentar a propósito. CLAUDE_CODE_MAX_RETRIES, cuyo valor por defecto es 10 y cuyo máximo es 15 desde v2.1.186, sirve para el fallo del otro tipo, el que cae antes de que salga la respuesta. Lo que sirve aquí es acortar cada turno.
5. ¿Pasa lo mismo con -p y en CI, es decir, en ejecución no interactiva?
El comportamiento es distinto. Según la referencia oficial, en las sesiones no interactivas, si la respuesta cortada es solo texto y no incluye llamadas de herramienta, Claude Code se pide a sí mismo continuar, hasta tres veces seguidas. Esta nota aparece cuando esas continuaciones se agotan. Antes de v2.1.246 el turno terminaba con el primer corte. Si usas --output-format json, este mensaje va dentro del campo result.
6. También aparece en los subagentes, con la herramienta Task.
Los subagentes continúan solos igualmente. Si la respuesta cortada es solo texto, Claude Code le pide al subagente que siga y esta nota solo pasa a ser el último mensaje cuando se agotan las continuaciones. Antes de v2.1.257 la nota salía con el primer corte.
7. ¿Es culpa de mi red?
Es posible, pero no tiene por qué ser lo único. Quien reporta la incidencia #86473 demuestra que un POST del mismo tamaño termina bien tanto con curl como con Node.js puro, y aun así solo la CLI se cae. Prueba primero a reproducirlo sin VPN ni proxy y después en otra línea. Si en ninguno de los dos casos cambia nada, puedes concluir que el problema no es solo tuyo.
8. ¿Se reduce si alargo el tiempo de espera?
Con este mensaje no cabe esperarlo, porque el veredicto es que la conexión se perdió, no que se agotara el tiempo. Alargar los temporizadores, como CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS, sirve para The response stopped arriving, es decir, para el síntoma en el que la conexión sigue viva pero se queda en silencio.
9. ¿Cómo compruebo qué versión estoy usando?
Con claude --version. Si en pantalla pone lost, es v2.1.227 o posterior; si pone closed, es anterior. El comportamiento de la conexión ha cambiado según la versión: en el CHANGELOG oficial, v2.1.198 corrige «que un corte de red breve a media respuesta interrumpiera el turno». Actualizar es la primera jugada que más compensa, pero no garantiza la cura: las dos incidencias citadas arriba están reportadas sobre versiones posteriores a esa.
10. Me pasa muy a menudo en la red corporativa. ¿Qué ajustes debo mirar?
La documentación oficial de configuración de red cubre lo esencial en tres puntos. Primero, los proxy SOCKS no están soportados, así que no los uses. Segundo, las variables de proxy no van en un export del shell sino en el bloque env de ~/.claude/settings.json, porque los agentes en segundo plano no reciben el entorno del shell. Y tercero, si usas mTLS, vigila la rotación de certificados. Para saber si la configuración se ha leído, mira el registro de claude --debug o lo que muestre /status.
Artículos relacionados
- API Error: Connection closed mid-response en Claude Code: causas y solución
- Claude Code: «court» en bucle infinito y «Response stalled mid-stream», causas y solución
- Errores de red y proxy en Claude Code: Unable to connect to API y certificados TLS
- Claude Code: error 529 Overloaded y 500, qué significan y cómo resolverlos
- Claude Code: el error de «court» y las etiquetas invoke filtradas
- Errores comunes de Claude Code y cómo solucionarlos, la referencia completa
Fuentes primarias consultadas
- Claude Code, Error reference, documentación oficial: la definición de los cuatro textos, el renombrado de v2.1.227, la recuperación con
continue, la bifurcación de Automatic retries y las variables de entorno - Claude Code, Enterprise network configuration, documentación oficial: los cuatro temporizadores de vigilancia del flujo y sus valores por defecto, la configuración de proxy, la falta de soporte de SOCKS y la relectura de mTLS
- anthropics/claude-code, CHANGELOG oficial: la corrección en v2.1.198 de «un corte de red breve a media respuesta interrumpía el turno»
- Incidencia #86473, ECONNRESET y Connection lost mid-response, v2.1.229 y Windows 11
- Incidencia #85979, el ECONNRESET continúa en v2.1.228, Windows 11
- Estado del servicio de Claude, página oficial de estado
