Sommaire
- 1. La première chose à faire — rien de ce qui est affiché n'est perdu
- 2. La définition officielle — les quatre messages de coupure en cours de réponse
- 3. En v2.1.227, « closed » a été renommé en « lost »
- 4. Pourquoi il n'y a pas de nouvelle tentative automatique
- 5. Où la connexion se rompt — les trois couches
- 6. À essayer maintenant — la check-list de diagnostic
- 7. Régler les minuteurs et les tentatives par variables d'environnement
- 8. Distinguer les messages voisins
- 9. Des signalements réels — quand ECONNRESET ne s'arrête plus
- 10. Ce qui est établi et ce qui ne l'est pas
- FAQ
Quand on confie un travail un peu long à Claude Code, la réponse peut s'interrompre brutalement sur cette ligne :
API Error: Connection lost mid-response. The response above may be incomplete.
Chercher ce libellé tel quel ne donne étrangement pas grand-chose. La raison est claire : c'est un nom relativement récent. La référence des erreurs officielle de Claude Code contient cette phrase telle quelle — « avant la v2.1.227, Connection lost mid-response s'affichait sous la forme Connection closed mid-response ». Autrement dit, le phénomène existait déjà et seul le mot affiché est passé de closed à lost. Comme l'information déjà en ligne est rédigée sous l'ancien nom, ceux qui cherchent avec le nouveau ne trouvent rien.
Cet article part de ce renommage pour mettre au clair ① le sens exact du message ② ce qu'il faut faire tout de suite ③ pourquoi il n'y a pas de nouvelle tentative automatique ④ comment isoler la couche qui a lâché ⑤ les réglages par variables d'environnement ⑥ la distinction avec les messages voisins, en s'appuyant uniquement sur la documentation officielle et sur des tickets publics. Chaque fois qu'une part de supposition subsiste, elle porte une étiquette de fiabilité.
Ce qui s'est affiché n'a pas disparu. La documentation officielle indique que répondre continue permet de reprendre à la suite du dernier bloc terminé.
Avant la v2.1.227, l'affichage était Connection closed mid-response. Les informations publiées sous l'ancien nom restent utilisables telles quelles.
Selon que la rupture se produit côté poste, sur le trajet ou côté serveur, la réponse n'est pas la même. Des signalements décrivent du HTTPS brut qui passe alors que seul Claude Code tombe.
1. La première chose à faire — rien de ce qui est affiché n'est perdu
Avant toute manipulation, mettons au clair le point le plus souvent mal compris. Même quand ce message apparaît, tout ce qui a défilé à l'écran jusque-là est conservé. Rien n'est jeté.
La référence des erreurs officielle explique ainsi la famille de messages qui se terminent par « The response above may be incomplete. » (la réponse ci-dessus est peut-être incomplète) — lorsque le streaming échoue après que Claude a terminé un bloc de texte ou un appel d'outil, renvoyer la requête risquerait d'exécuter deux fois le même appel d'outil ; Claude Code conserve donc ce qui est terminé et, au lieu de jeter le tour, y ajoute cette mention.
Il n'y a donc que trois gestes à faire.
Claude Code conserve tous les blocs terminés, mais jette le dernier bloc encore en cours au moment où le tour s'achève. Ce qui manque, ce sont le plus souvent les quelques phrases finales ou le dernier appel d'outil.
continueC'est exactement la procédure de reprise officielle. Elle fait repartir depuis le dernier bloc terminé. Ne relancez pas la consigne depuis le début — vous rejoueriez par-dessus des opérations déjà exécutées.
Si la coupure survient pendant une écriture de fichier ou l'exécution d'une commande, c'est la trace à l'écran qui fait foi sur ce qui a été exécuté. Vérifiez l'état réel avec git status ou l'équivalent avant de poursuivre.
-p, Agent SDK, sessions cloud — si la réponse coupée ne contient que du texte et aucun appel d'outil, Claude Code demande lui-même la suite à Claude, jusqu'à trois fois d'affilée. Cette mention n'apparaît qu'une fois ces relances épuisées. Les sous-agents poursuivent eux aussi automatiquement.
2. La définition officielle — les quatre messages de coupure en cours de réponse
Premier point à retenir : ce libellé est une mention que Claude Code ajoute lui-même, ce n'est pas le corps d'une réponse d'erreur renvoyée par l'API. C'est pourquoi, pour une même coupure en cours de réponse, Claude Code change la formulation selon la cause. La référence officielle en énumère quatre.
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.
L'explication officielle tient en une formule — « la connexion a été perdue ». Le flux arrivait normalement, mais la connexion qui le transportait a disparu.
Un overloaded ou un 5xx survient au milieu du flux. D'après la documentation officielle, cet affichage lui-même date de la v2.1.199 ; avant cela, la sortie partielle était jetée et le tour entier traité comme une erreur.
Claude Code a détecté que l'ordinateur s'est mis en veille pendant la réponse. Au réveil, il considère la connexion comme rompue et cesse la lecture.
La connexion reste ouverte mais les données cessent d'arriver, et le minuteur de surveillance du flux met fin à l'attente. Ce n'est pas une rupture mais un arrêt ; la cause et le remède sont différents.
Commencez par lire précisément laquelle de ces quatre cartes correspond à votre écran. L'expérience vécue paraît la même dans les quatre cas, mais Claude Code a déjà isolé la cause avant de choisir le libellé. Si vous voyez lost, le verdict est que la connexion a été perdue : le serveur n'a pas renvoyé de 5xx et il n'y a pas eu de dépassement de délai.
3. En v2.1.227, « closed » a été renommé en « lost »
C'est le cœur de cet article. Juste après avoir aligné les quatre explications, la référence des erreurs officielle place cette phrase en note.
« Avant la v2.1.227,Connection lost mid-responses'affichait sous la formeConnection closed mid-response, etThe response stopped arrivingsous la formeResponse stalled mid-stream»
— Référence des erreurs officielle de Claude Code (traduction de l'auteur)
Deux libellés ont donc été remplacés en même temps. Voici la correspondance sous forme de tableau.
| Affichage avant la v2.1.227 | Affichage actuel | Sens (officiel) |
|---|---|---|
Connection closed mid-response |
Connection lost mid-response |
La connexion a été perdue |
Response stalled mid-stream |
The response stopped arriving |
La connexion reste ouverte mais les données cessent d'arriver |
Connection closed while thinking, before producing a response |
Connection lost before a response was produced |
Coupure avant qu'un seul caractère ne sorte (donc aucune sortie partielle) |
Response stalled while thinking, before producing a response |
The response stalled before a response was produced |
Arrêt avant qu'un seul caractère ne sorte, la connexion restant ouverte |
Attention, la troisième ligne est autre chose que le message traité ici. mid-response veut dire « la coupure est survenue après qu'une partie de la sortie est apparue », before a response was produced veut dire « la coupure est survenue avant le moindre caractère » — même vague de renommage, mais sens et comportement ultérieur différents. Le chapitre suivant en traite.
Ce que change le fait de connaître ce renommage
Il y a trois effets pratiques.
En cherchant « Connection closed mid-response », les tickets GitHub et les articles d'explication se multiplient d'un coup. Le phénomène étant le même, aucune transposition n'est nécessaire.
Si l'écran affiche lost, ce Claude Code est en v2.1.227 ou plus récent. À l'inverse, closed signale une version antérieure.
Le même phénomène étant signalé sous deux noms, une recherche de tickets doit porter sur les deux libellés, faute de quoi les signalements existants passent inaperçus.
⚠️ Avant la v2.1.222, l'alerte peut être un faux positif. La référence des erreurs officielle écrit noir sur blanc que « Claude Code, avant la v2.1.222, émettait aussi cette notification lorsque la connexion se rompait ou se figeait après l'achèvement de la réponse, et signalait le tour comme une erreur alors que la réponse était complète ». Autrement dit, sur les anciennes versions, toute la sortie est bien arrivée et seul l'affichage d'erreur est en trop. Si claude --version renvoie une valeur inférieure à 2.1.222, mettez à jour avant même de commencer le diagnostic — l'erreur que vous voyez peut n'avoir aucune réalité.
4. Pourquoi il n'y a pas de nouvelle tentative automatique
Claude Code ne reste pas inactif. D'après la section « Automatic retries » de la référence officielle, les échecs passagers sont réessayés automatiquement jusqu'à dix fois, avec un recul exponentiel. Si ce message apparaît malgré tout, c'est que Claude Code a jugé qu'il ne fallait pas réessayer ici.
L'unique critère qui fait bifurquer la décision est « Claude avait-il déjà terminé quelque chose ? ».
Si la connexion tombe alors que Claude n'a terminé aucune partie de la réponse, réflexion comprise, Claude Code renvoie la requête avec le même recul et le tour se poursuit. C'est vrai même si du texte avait commencé à défiler.
Si la réflexion est terminée mais que ni le texte ni l'appel d'outil n'ont commencé, la requête n'est renvoyée que deux fois au maximum, à court intervalle ; si la coupure persiste, le tour se termine sur Connection lost before a response was produced.
Si la coupure survient après qu'un bloc de texte ou un appel d'outil a été terminé (ou entamé après la réflexion), Claude Code ne renvoie pas la requête. Parce qu'il risquerait d'exécuter deux fois le même appel d'outil.
À la place, il conserve ce qui est terminé, exécute les appels d'outil déjà complets et poursuit le tour à partir de leurs résultats. C'est alors qu'il ajoute cette mention.
Ce choix de conception paraît gênant, mais il penche du côté sûr. Avec un renvoi automatique, des opérations à effet de bord comme une modification de fichier ou l'exécution d'une commande pourraient s'exécuter deux fois à chaque coupure. C'est pourquoi la documentation officielle recommande non pas de renvoyer la requête, mais de répondre continue — c'est la seule voie qui évite de refaire un travail déjà achevé.
Ce qui s'affiche pendant les nouvelles tentatives
Pendant les tentatives, un compte à rebours Retrying in Ns · attempt x/y apparaît à côté du spinner. L'étiquette est d'abord API error, mais depuis la v2.1.198 elle bascule sur la raison précise dès la troisième tentative (ou à la dernière tentative si CLAUDE_CODE_MAX_RETRIES est inférieur à 3).
Par ailleurs, si la requête est toujours vivante mais qu'aucune donnée n'arrive pendant 20 secondes, une bannière Waiting for API response · will retry in … · check your network apparaît avant même tout échec. C'est un affichage qui signifie que rien n'a encore échoué, et le compte à rebours indique le moment où Claude Code mettra fin à la connexion figée. D'après la documentation officielle, ce seuil était de 10 secondes avant la v2.1.185, avec un libellé différent.
5. Où la connexion se rompt — les trois couches
S'entendre dire seulement que la connexion a été perdue ne suffit pas à décider quoi faire. Il y a trois grands endroits où elle peut se rompre, et chacun se vérifie autrement.
Bascule de Wi-Fi, micro-coupure du réseau mobile, mise en veille, reconnexion du client VPN.
Comment vérifier : la panne se reproduit-elle en filaire ou sur une autre liaison ? Si la veille est en cause, un libellé dédié apparaît, ce qui permet de trancher.
Proxy d'entreprise, inspection TLS, passerelle LLM, VPN. Les équipements qui jugent inactif un flux ouvert longtemps et le coupent ne sont pas rares.
Comment vérifier : la panne se reproduit-elle sans HTTPS_PROXY ? Contrôlez la ligne de proxy avec /status.
Incident côté service, ou connexion réutilisée qui était en réalité morte. Sa signature : la liaison locale est saine et pourtant les coupures s'enchaînent.
Comment vérifier : consultez status.claude.com. Si la panne se reproduit de la même façon sur plusieurs liaisons, le problème n'est pas seulement local.
Stale connection — reloaded rotated mTLS client material apparaît dans le journal de claude --debug.
6. À essayer maintenant — la check-list de diagnostic
Les entrées sont classées de haut en bas du plus rentable au moins rentable, effet important et effort faible d'abord. Après chaque essai, vérifiez si la panne se reproduit.
| # | À faire | Objectif |
|---|---|---|
| 1 | Répondre continue | Éviter d'abord d'acter la perte. Plus rapide qu'un redémarrage, et sans risque de double exécution |
| 2 | Mettre Claude Code à jour | Le comportement autour de la connexion change selon la version. La v2.1.198 a corrigé le problème des brèves coupures réseau en cours de réponse qui interrompaient le tour |
| 3 | Découper un tour en plus court | Séparer « lire beaucoup de fichiers puis rédiger un rapport » en une phase de lecture et une phase de rédaction. Réduire la durée pendant laquelle le flux reste ouvert |
| 4 | Reproduire sans VPN ni proxy | Test de la couche 2. Si le retrait règle le problème, soupçonnez une coupure pour inactivité sur le trajet |
| 5 | Reproduire sur une autre liaison | Test des couches 1 et 3. Si le résultat est identique sur plusieurs liaisons, le problème n'est pas seulement local |
| 6 | Revoir les réglages de veille | Si l'écran s'éteint au milieu d'une longue réponse, la connexion peut se rompre avant même que le libellé dédié n'apparaisse |
| 7 | Consulter status.claude.com | Contrôle de la couche 3. En cas de 529, Claude Code affiche lui-même ce nom d'hôte |
| 8 | Enregistrer une trace avec claude --debug | Le journal est écrit dans ~/.claude/debug/<session-id>.txt. Joignez-le à tout signalement |
| 9 | Vérifier que vous n'utilisez pas de proxy SOCKS | La documentation officielle indique noir sur blanc que les proxys SOCKS ne sont pas pris en charge. Si vous en utilisez un, passez par un autre trajet |
7. Régler les minuteurs et les tentatives par variables d'environnement
Claude Code dispose de quatre minuteurs indépendants pour mettre fin à un flux devenu silencieux. Voici la liste donnée par la documentation officielle de configuration réseau.
| Minuteur | Condition de fin | Délai par défaut |
|---|---|---|
| First-byte deadline | Après l'envoi, aucun en-tête de réponse n'arrive | 180 s pour l'API directe, 300 s sinon (plus 1 s par tranche de 32 Ko du corps de la requête) |
| Event-level watchdog | Aucun événement de la réponse ne peut être analysé | 300 s (actif chez tous les fournisseurs) |
| Byte-level watchdog | Aucun octet n'arrive, pings de maintien SSE compris | 180 s pour l'API directe, 300 s sinon |
| Body idle timeout | Aucun octet pendant 5 minutes | 5 minutes (pour les fournisseurs autres que l'API directe) |
Attention toutefois : quand l'un de ces minuteurs met fin à l'attente, le libellé obtenu est en principe celui du silence — pas celui traité ici. Si ce tableau figure dans cet article, c'est parce qu'il faut connaître les valeurs par défaut pour distinguer les deux, et non pour conclure que lost s'affiche et qu'il faudrait donc allonger les minuteurs. Dans un environnement où de longs silences se produisent derrière un proxy, jouer sur ces valeurs change bien les symptômes du côté arrêt.
Du côté des tentatives, les variables suivantes permettent le réglage.
| Variable d'environnement | Défaut | Effet |
|---|---|---|
CLAUDE_CODE_MAX_RETRIES |
10 | Nombre de tentatives. Depuis la v2.1.186, le plafond est 15. Dans les scripts, l'usage recommandé est de l'abaisser pour échouer plus vite |
CLAUDE_CODE_RETRY_WATCHDOG |
Non défini | Pour les sessions sans surveillance comme la CI. Réglée à 1, elle réessaie indéfiniment les 429 et les 529 et, depuis la v2.1.199, porte à 300 le nombre par défaut de tentatives sur les erreurs passagères, ruptures comprises |
API_TIMEOUT_MS |
600000 | Délai par requête (en millisecondes, soit 10 minutes). À relever sur les liaisons lentes ou derrière un proxy |
CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS |
Non défini | Délai propre à la seule surveillance des octets. Borné entre 10 secondes et 30 minutes |
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS |
Non défini | Fixe directement le délai jusqu'au premier octet. Disponible depuis la v2.1.242 |
CLAUDE_CODE_MAX_RETRIES agit sur les échecs du type « ça tombe avant que la sortie ne sorte », pas sur les coupures en cours de réponse. Ce qui agit, c'est plutôt de raccourcir chaque tour.
8. Distinguer les messages voisins
C'est peut-être la partie la plus utile en pratique pour le lecteur. L'expérience d'un arrêt en cours de route est commune, mais le libellé affiché par Claude Code diffère, et la cause comme le remède avec lui. Le tableau reprend aussi la correspondance avec les articles déjà publiés sur ce site.
| Libellé affiché | Ce qui se passe | Où lire la suite |
|---|---|---|
Connection lost mid-response |
Une partie de la sortie est apparue, puis la connexion a été perdue | Cet article |
Connection closed mid-response |
Ancien nom du même phénomène (avant la v2.1.227) | L'article sur closed, qui rassemble les signalements de l'époque de l'ancien nom |
The response stopped arrivingAncien : Response stalled mid-stream |
La connexion est vivante mais devient silencieuse, et un minuteur y met fin | L'article sur stalled (attention à l'enchaînement avec la boucle de répétition) |
Server error mid-response |
Au milieu du flux, le serveur renvoie un 5xx ou overloaded | L'article sur les 529 et 500 |
Your computer went to sleep mid-response |
Claude Code a détecté que l'ordinateur s'est mis en veille pendant la réponse | Revoir les réglages d'alimentation et de veille (chapitre 6 de cet article) |
Connection lost before a response was produced |
Coupure avant le moindre caractère (aucune sortie partielle) | Cas réessayé. Chapitre 4 de cet article |
Unable to connect ou erreur de certificat SSL |
La connexion ne s'établit tout simplement pas | L'article sur le réseau et les proxys |
Les balises court et invoke apparaissent dans le texte |
Ce n'est pas le réseau : l'appel d'outil n'est pas exécuté | L'article sur la balise court |
La bifurcation la plus importante est de savoir si une réponse est apparue à l'écran. Si pas un caractère n'est sorti, c'est du côté de la connexion et de la configuration (proxy, certificats, pare-feu) qu'il faut chercher. Si une partie est sortie, c'est la preuve que la connexion fonctionnait : mieux vaut alors suivre le diagnostic de cet article que toucher aux réglages.
La deuxième bifurcation : rupture ou silence ?
Selon que la connexion a été perdue ou qu'elle s'est tue en restant ouverte, le geste suivant est exactement inverse.
Soupçonnez le trajet et la réutilisation des connexions. Allonger les délais ne sert à rien — il ne s'agit pas d'un dépassement de temps, la connexion elle-même a disparu.
C'est là que les minuteurs entrent en jeu. Régler CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS et consorts peut avoir un effet, et il faut aussi envisager que le modèle reste longtemps muet.
9. Des signalements réels — quand ECONNRESET ne s'arrête plus
Le cas le plus pénible est celui où la liaison locale est parfaitement saine et où seul Claude Code continue de tomber. Deux signalements publics comportent un nombre appréciable de vérifications. Tous deux sont rédigés soit avec le nouveau nom traité ici, soit avec le libellé de la version qui l'a immédiatement précédé.
L'auteur écrit qu'après Connection dropped (ECONNRESET) · Retrying in 17s · attempt 6/10 apparaît API Error: Connection lost mid-response.. Il indique par ailleurs qu'un POST de 60 Ko avec curl comme un POST de même taille via https.request en Node.js pur vont tous deux jusqu'au bout, et qu'un flux SSE de longue durée depuis un autre hôte n'a pas non plus été interrompu.
Contrôle du MTU, contrôle des LSP Winsock, reproduction en configuration minimale, reproduction sur deux réseaux sans rapport : tout cela a été fait et le problème reste non résolu. L'Issue #86473 est marquée comme doublon tout en restant ouverte.
Ici, c'est Connection dropped (ECONNRESET) · Retrying in 0s · attempt 4/10. L'auteur écrit avoir épuisé la désinstallation complète de l'antivirus, les filtres VPN, le proxy et l'IPv6, jusqu'à la réinitialisation de Winsock, et avoir malgré tout reproduit la panne à l'identique sur trois réseaux (Wi-Fi de l'entreprise, Wi-Fi du domicile, partage de connexion du téléphone).
Le contraste est explicite : sur le même poste et avec le même compte, le chat de claude.ai fonctionne sans problème. L'Issue #85979 reste elle aussi ouverte (stale).
Il reste malgré tout une leçon pratique à tirer de ces deux cas : « le ping passe » et « curl passe » ne prouvent pas que cette erreur ne se produira pas. Un échange qui garde une seule connexion ouverte plusieurs minutes en streaming n'est pas dans les mêmes conditions qu'une requête courte. Plutôt que d'investir du temps dans l'examen du réseau local, découper les tours fait baisser plus sûrement le taux de reproduction.
10. Ce qui est établi et ce qui ne l'est pas
Pour éviter les malentendus, voici séparément ce qui est vérifiable officiellement et ce qui ne l'est pas.
- Ce libellé figure officiellement dans la référence des erreurs, et son sens est « la connexion a été perdue »
- Avant la v2.1.227, l'affichage était
Connection closed mid-response(renommage de la même chose) - La sortie déjà transmise est conservée à dessein (un renvoi risquerait une double exécution)
- La procédure de reprise consiste à répondre
continue - Une rupture avant toute sortie est réessayée automatiquement (jusqu'à dix fois, avec recul exponentiel)
- Les sessions non interactives et les sous-agents poursuivent d'eux-mêmes (depuis la v2.1.246 et la v2.1.257 respectivement)
- Le HTTPS brut est sain et seule la CLI tombe sur ECONNRESET (signalements #86473 et #85979)
- Le contraste avec la version navigateur qui tient sur le même poste et le même compte (signalement #85979)
- L'implication possible d'un défaut lié à la réutilisation des connexions (explication du support citée par l'auteur du ticket)
- La mention d'un incident côté serveur à des dates précises (également rapportée par l'auteur du ticket)
- Une explication officielle de la cause par Anthropic (aucune réponse publique sur les deux tickets ci-dessus)
- La raison du renommage. Aucune trace du changement de libellé dans le CHANGELOG
- Les tickets #86473 et #85979 restent tous deux ouverts
En résumé, le symptôme, le sens et la procédure de reprise sont documentés officiellement, mais aucune explication officielle n'a encore été publiée sur la raison des coupures. Dans cette situation, ce qui fonctionne à coup sûr n'est pas l'identification de la cause mais une pratique qui minimise la perte quand ça coupe : découper les tours, avancer en vérifiant l'état après chaque opération à effet de bord, garder une version récente. Ces trois gestes agissent quelle que soit la cause.
FAQ
Q1. « Connection lost mid-response » et « Connection closed mid-response » sont-elles deux erreurs différentes ?
C'est la même chose. Comme l'écrit noir sur blanc la référence des erreurs officielle, avant la v2.1.227 le même phénomène s'affichait sous la forme Connection closed mid-response. Un changement d'affichage ne signifie pas qu'un nouveau type de panne est apparu. Les informations rédigées sous l'ancien nom restent consultables telles quelles.
Q2. La sortie déjà produite disparaît-elle ?
Non. Tous les blocs que Claude a terminés sont conservés. Seul est jeté le dernier bloc encore en cours au moment où le tour s'achève. Si Claude Code choisit d'ajouter cette mention plutôt que de renvoyer la requête, c'est parce qu'un renvoi risquerait d'exécuter deux fois le même appel d'outil.
Q3. Que faut-il répondre pour reprendre là où ça s'est arrêté ?
Répondez continue. C'est la procédure de reprise indiquée par la référence des erreurs officielle : elle fait repartir depuis le dernier bloc terminé. Relancer la consigne depuis le début risque de dupliquer des opérations déjà exécutées.
Q4. Augmenter le nombre de tentatives règle-t-il le problème ?
Non. Comme l'explique le chapitre 4, c'est la mention d'un moment où Claude Code évite délibérément de réessayer. CLAUDE_CODE_MAX_RETRIES (10 par défaut, plafond 15 depuis la v2.1.186) agit sur les échecs du type « ça tombe avant que la sortie ne sorte ». Ce qui agit ici, c'est plutôt de raccourcir chaque tour.
Q5. Est-ce identique avec -p ou en CI (exécution non interactive) ?
Le comportement diffère. D'après la référence officielle, dans les sessions non interactives, si la réponse coupée ne contient que du texte et aucun appel d'outil, Claude Code demande lui-même la suite, jusqu'à trois fois d'affilée. Cette mention n'apparaît qu'une fois ces relances épuisées. Avant la v2.1.246, le tour se terminait dès la première rupture. Avec --output-format json, ce message se retrouve dans le champ result.
Q6. Cela apparaît aussi dans les sous-agents (Task).
Les sous-agents poursuivent eux aussi automatiquement. Si la réponse coupée ne contient que du texte, Claude Code demande la suite au sous-agent, et cette mention ne devient le dernier message qu'une fois les relances épuisées. Avant la v2.1.257, la mention apparaissait dès la première rupture.
Q7. Est-ce mon réseau qui est en cause ?
C'est possible, mais ce n'est pas forcément la seule explication. L'auteur de l'Issue #86473 montre qu'un POST de même taille passe entièrement avec curl comme avec Node.js pur, et signale que seule la CLI tombe. Vérifiez d'abord si la panne se reproduit sans VPN ni proxy, puis essayez sur une autre liaison. Si rien ne change dans les deux cas, le problème n'est pas seulement local.
Q8. Allonger les délais fait-il diminuer le phénomène ?
Pour ce message, il ne faut pas s'y attendre. Le verdict n'est pas un dépassement de temps mais la perte de la connexion elle-même. Allonger les minuteurs (comme CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS) agit sur The response stopped arriving, c'est-à-dire sur le symptôme où la connexion est vivante mais devient silencieuse.
Q9. Comment savoir quelle version j'utilise ?
Avec claude --version. Si l'écran affiche lost, vous êtes en v2.1.227 ou plus récent ; s'il affiche closed, vous êtes sur une version antérieure. Le comportement autour de la connexion évolue d'une version à l'autre : le CHANGELOG officiel indique qu'en v2.1.198 le problème des brèves coupures réseau en cours de réponse qui interrompaient le tour a été corrigé. La mise à jour est le geste le plus rentable à essayer en premier, mais elle ne garantit pas la guérison — les deux tickets cités plus haut portent tous deux sur des versions plus récentes que celle-là.
Q10. Cela arrive souvent sur le réseau d'entreprise. Quels réglages regarder ?
La documentation officielle de configuration réseau couvre l'essentiel, en trois points. ① Les proxys SOCKS ne sont pas pris en charge, donc ne les utilisez pas. ② Placez les variables de proxy dans le bloc env de ~/.claude/settings.json plutôt que dans un export du shell, car l'environnement du shell n'atteint pas les agents en arrière-plan. ③ Si vous utilisez mTLS, surveillez la rotation des certificats. Pour savoir si la configuration a bien été lue, regardez le journal de claude --debug ou l'affichage de /status.
Articles liés
- API Error: Connection closed mid-response dans Claude Code : causes et solutions
- Claude Code répète « court » puis « Response stalled mid-stream » : causes et solutions
- Erreurs réseau et proxy de Claude Code : Unable to connect to API et certificats TLS
- Claude Code : erreur 529 Overloaded et 500 — que faire
- Claude Code : « court » et les balises invoke qui fuient — quand l'appel d'outil ne s'exécute pas
- Erreurs courantes de Claude Code et leurs correctifs — la référence complète
Sources primaires consultées
- Claude Code — Error reference (documentation officielle) : la définition des quatre libellés, le renommage de la v2.1.227, la reprise par
continue, l'arbre des Automatic retries, les variables d'environnement - Claude Code — Enterprise network configuration (documentation officielle) : les quatre minuteurs de surveillance du flux et leurs valeurs par défaut, la configuration du proxy, l'absence de prise en charge de SOCKS, la relecture mTLS
- anthropics/claude-code — CHANGELOG (officiel) : la correction, en v2.1.198, du problème des brèves coupures réseau en cours de réponse qui interrompaient le tour
- Issue #86473 — ECONNRESET et Connection lost mid-response (v2.1.229, Windows 11)
- Issue #85979 — ECONNRESET persiste en v2.1.228 (Windows 11)
- État de service de Claude (page de statut officielle)
