Sommaire
- 1. Ce que dit vraiment ce message — la définition officielle
- 2. La première chose à faire — rien n'est perdu
- 3. Pourquoi ça coupe — les trois couches où la connexion se ferme
- 4. Ce qu'ont montré les captures réseau : une fermeture côté serveur
- 5. Vérifiez votre version — la chronologie des correctifs
- 6. Les conditions qui augmentent le risque
- 7. Régler le problème maintenant — check-list
- 8. Pour les développeurs — prévenir au niveau API/SDK
- 9. Distinguer des erreurs voisines
- 10. Statut officiel et ce qui reste non confirmé
- FAQ
Vous travaillez dans Claude Code et, au milieu d'une réponse, tout s'arrête sur cette ligne :
API Error: Connection closed mid-response. The response above may be incomplete.
Cela peut survenir pendant la rédaction d'un long rapport, pendant la lecture de plusieurs fichiers, ou juste après le démarrage d'une nouvelle session. Le moment varie et il n'existe aucun moyen fiable de reproduire le phénomène. Ce n'est pas un problème de rédaction de votre prompt : c'est un événement de la couche transport — la connexion qui transportait la réponse en streaming s'est fermée alors que la réponse arrivait encore.
Et un fait pèse plus lourd que toutes les hypothèses. La plupart des signalements publics de cette erreur proviennent de versions antérieures au changement de gestion des connexions interrompues dans Claude Code. En parcourant le changelog officiel, on trouve cinq correctifs distincts liés à la connexion et aux nouvelles tentatives à partir de la 2.1.179. Cet article s'appuie uniquement sur la référence des erreurs officielle, le changelog officiel et des tickets étayés par des captures réseau, et traite (1) le sens exact du message, (2) quoi faire tout de suite, (3) où la connexion se ferme réellement, (4) ce qui a changé entre les versions, (5) comment se prémunir en tant que développeur.
Tout ce qui a déjà été transmis est intact. La manière documentée de reprendre est de répondre continue.
La 2.1.198 a empêché les brèves coupures réseau de faire tomber le tour ; la 2.1.214 a empêché les nouvelles tentatives de réutiliser une connexion morte.
Votre machine, le chemin (proxy/VPN) ou le côté serveur : chacun appelle une réponse différente. Des fermetures initiées par le serveur ont été signalées.
1. Ce que dit vraiment ce message — la définition officielle
D'abord : ce texte est une note écrite par Claude Code lui-même, et non une réponse d'erreur renvoyée par l'API. La référence officielle des erreurs de Claude Code explique ainsi toute la famille de messages se terminant par « The response above may be incomplete. » : lorsqu'une réponse en streaming échoue après que Claude a déjà produit une sortie visible, renvoyer la requête risquerait d'exécuter deux fois les mêmes appels d'outils ; Claude Code conserve donc ce qui a été transmis et ajoute cette note au lieu d'abandonner le tour.
La fin de la phrase est alors le nom de la cause. La référence en liste trois variantes.
L'explication officielle tient en une ligne : la connexion a été rompue. Le flux fonctionnait, mais la connexion qui le portait s'est fermée.
Officiellement : le flux a cessé d'envoyer des données. La connexion est vivante mais devient silencieuse. Pas une rupture : un arrêt.
Une erreur de surcharge ou 5xx au milieu du flux. Selon la documentation, cette variante exige la v2.1.199 ou une version ultérieure ; avant cela, la sortie partielle était jetée et tout le tour signalé comme une erreur.
Les trois en une ligne. Connection closed, c'est le lien coupé ; Response stalled, c'est le silence ; Server error, c'est le serveur qui tombe. Tout ressemble à « ça s'est arrêté en cours de route », mais chaque cas se produit à un endroit différent du transport.
La référence précise un autre comportement qu'il vaut la peine de connaître. Si le même échec survient avant toute sortie visible, Claude Code relance la requête au lieu de conclure le tour. Autrement dit, si vous lisez ce message, c'est que de la sortie était déjà apparue — renvoyer risquerait donc de dupliquer des effets de bord, et Claude Code a délibérément évité la relance automatique. Voir l'erreur ne veut pas dire que rien n'a été tenté.
2. La première chose à faire — rien n'est perdu
Avant de renvoyer la même consigne dans la précipitation, procédez dans cet ordre.
Comme le dit la documentation, rien n'a été perdu. Ce qui manque se limite le plus souvent aux dernières phrases ou au dernier appel d'outil.
continueL'étape de reprise nommée dans la référence officielle. Faites reprendre Claude là où il s'est arrêté plutôt que de tout recommencer.
Si la coupure est survenue pendant des modifications de fichiers ou l'exécution de commandes, une partie a peut-être déjà été exécutée. Regardez l'état réel avec git status avant de poursuivre.
Si l'erreur revient plusieurs fois dans une session, vérifiez la version avant toute chose. Ce domaine a été corrigé à plusieurs reprises.
Ne négligez pas l'étape 3. Quand la documentation écrit que renvoyer « risquerait d'exécuter deux fois les mêmes appels d'outils », le revers de la médaille est que certains outils ont peut-être déjà été exécutés au moment de la coupure. Si cela s'est produit au milieu d'écritures de fichiers, d'un commit ou d'un déploiement, regarder d'abord l'état réel est le chemin de retour le plus court.
3. Pourquoi ça coupe — les trois couches où la connexion se ferme
« La connexion a été rompue » ne permet pas d'agir en soi ; il faut donc séparer les endroits d'où la fermeture peut provenir. Les signalements se répartissent en trois couches.
Une micro-coupure Wi-Fi, un basculement de cellule en mobile, une sortie de veille. Le changelog officiel contient même un correctif pour « les requêtes en streaming qui échouent après le réveil de la machine » (2.1.186) : cette couche est bien réelle.
Ce qui aide : un lien filaire ou stable ; ne pas laisser la machine se mettre en veille pendant un long travail.
La documentation officielle des erreurs de l'API Claude indique que certains réseaux coupent les connexions inactives après un délai variable, et recommande de configurer un keep-alive TCP. Les proxys d'entreprise et les VPN y sont particulièrement enclins.
Ce qui aide : contourner le proxy ou le VPN un moment et voir si le problème se reproduit.
Il existe des preuves au niveau des paquets montrant que la connexion est fermée côté serveur alors que le flux est en cours (section suivante). Aucun réglage local ne l'empêche.
Ce qui aide : le comportement de relance du client — c'est pour cela que la mise à jour fonctionne.
De fait, l'auteur du ticket GitHub #69415 ([BUG] API Error: Connection closed mid-response ==> frequent enough to make Claude Code unusable for any task, ouvert le 18 juin 2026 et toujours ouvert au moment de la rédaction) décrit Windows 11 avec WSL2, une connexion directe sans pare-feu d'entreprise ni proxy, sur Claude Code 2.1.181. Autrement dit, il affirme que cela se produit même une fois les couches 1 et 2 écartées. Le ticket porte les étiquettes area:networking, platform:vscode et platform:wsl.
La même personne écrit que, sur la même machine et le même réseau, d'autres assistants IA (GitHub Copilot, Cursor et d'autres) mènent la même tâche à son terme. Il s'agit toutefois d'une comparaison faite par un utilisateur, non d'une détermination de cause par Anthropic — la distinction mérite d'être maintenue.
Un autre signalement décrit des conditions nettement différentes. Le ticket #69336 (occurs immediately in new context window, ouvert le 18 juin 2026 et toujours ouvert, Claude Code 2.1.173, Debian 13, un Claude Agent SDK auto-hébergé) indique que la fréquence augmente après l'exécution du résumé de contexte (compact). Il porte area:agent-sdk, area:api et platform:linux, et démarrer une conversation entièrement neuve y est décrit comme un contournement temporaire. Le ticket #69517 (dans Claude Cowork, 19 juin 2026, macOS, 2.1.183) a été fermé comme doublon.
4. Ce qu'ont montré les captures réseau : une fermeture côté serveur
L'enquête de première main la plus poussée sur cette catégorie d'erreur est le ticket #67766 (ouvert le 12 juin 2026, toujours ouvert). Son auteur a capturé les paquets dans son environnement et recoupé dix incidents.
Source : les captures réseau et transcriptions publiées par l'auteur du ticket GitHub #67766. Ce sont des mesures d'un seul utilisateur, pas des résultats vérifiés par Anthropic.
Le détail techniquement décisif est que les fermetures étaient sélectives. Selon le rapport, les autres connexions vers la même destination sont restées vivantes pendant l'événement, et celle qui a été fermée était la connexion appartenant au processus qui exécutait la requête. Les connexions de deux autres processus claude tournant en parallèle sont restées intactes. Une chute du lien les aurait toutes emportées ; ce ne fut pas le cas.
L'auteur a aussi observé que, dans quatre des dix incidents, des vagues de fermetures frappaient plusieurs connexions du pool à la fois, et que trois se sont déclenchées à la seconde :54 de minutes voisines (01:19:54, 01:20:54 et 01:22:54 UTC) — qu'il interprète comme l'indice d'un traitement cadencé à 60 secondes.
🟡 Quel degré de confiance accorder à cette section ?
Le message affiché dans le ticket #67766 est « API Error: The socket connection was closed unexpectedly », une formulation différente de celle de cet article. On ne peut donc pas affirmer qu'il s'agit du même défaut. Cela dit, c'est aujourd'hui la seule preuve publique au niveau des paquets concernant le même type de phénomène — une connexion qui se ferme alors qu'un flux est en cours — ce qui en fait une hypothèse de travail utile. Précisons aussi qu'Anthropic n'a publié aucune explication sur ce signalement à ce jour.
5. Vérifiez votre version — la chronologie des correctifs
C'est la partie la plus utile en pratique. En parcourant le changelog officiel de Claude Code, on constate que la gestion des coupures de connexion en cours de flux a été améliorée à plusieurs reprises. Chacune des entrées ci-dessous figure réellement dans le changelog.
Les réponses partielles sont désormais conservées lorsque la connexion tombe en cours de flux. Auparavant, une erreur brute s'affichait et l'indicateur pouvait rester bloqué sur « running tool ».
L'indication de blocage est devenue « Waiting for API response · will retry in … » et se déclenche désormais après 20 secondes de silence au lieu de 10 : les petites variations ne provoquent plus d'avertissement.
Correction des brèves coupures réseau en cours de réponse qui interrompaient le tour. Les erreurs transitoires comme ECONNRESET font maintenant l'objet d'une nouvelle tentative avec backoff au lieu d'échouer.
Correction du rejet des réponses en streaming lorsqu'une erreur de surcharge ou de serveur survient en cours de flux. La partie déjà reçue est désormais conservée avec une note de réponse incomplète — d'où provient la variante Server error mid-response.
Le pool de connexions keep-alive est désormais désactivé après une erreur de connexion périmée, de sorte que les relances ouvrent un nouveau socket. Cela répond directement au schéma décrit par le ticket #67766 : une connexion réutilisée que l'on ferme.
Confrontez maintenant cette chronologie aux versions des signalements cités plus haut.
| Signalement | Version à l'époque | Correctifs pas encore appliqués |
|---|---|---|
| #69336 | 2.1.173 | Tous : 2.1.179 / 198 / 199 / 214 |
| #69415 | 2.1.181 | 2.1.198 / 199 / 214 (l'amélioration des relances et le correctif du pool) |
| #69517 | 2.1.183 | 2.1.198 / 199 / 214 |
Les trois sont antérieurs à la 2.1.198, la version qui absorbe les coupures transitoires par des relances. La première chose à vérifier est donc votre propre version.
claude --versionSi elle est inférieure à 2.1.198, mettre à jour va plus vite que diagnostiquer. La dernière entrée du changelog au moment de la rédaction est la 2.1.220, qui inclut tous les correctifs ci-dessus.
Cela dit, on ne peut pas garantir que la mise à jour fasse disparaître le problème. Le changelog ne contient aucune entrée nommant « Connection closed » elle-même ; tout ce qui précède relève d'améliorations de la gestion de connexion voisine. Voyez la mise à jour comme le premier geste au meilleur rapport coût/bénéfice, pas comme un remède démontré.
6. Les conditions qui augmentent le risque
Ces facteurs reviennent d'un signalement à l'autre.
Lire plusieurs gros fichiers et produire un rapport structuré — tout ce qui garde le flux ouvert longtemps (#69415).
La fréquence augmenterait après l'exécution du résumé de contexte (#69336). Après un résumé, les requêtes ont tendance à grossir.
Dans les mesures du #67766, les connexions fermées transportaient des corps de requête de 1 à 2,5 Mo. Pour mémoire, la limite officielle de l'API Messages est de 32 Mo.
Proxys d'entreprise, VPN, liaisons longue distance. C'est la couche que décrit la documentation officielle en évoquant les réseaux qui coupent les connexions inactives.
Le changelog 2.1.186 corrige des requêtes en streaming qui échouaient après le réveil de la machine. Ne laissez pas la machine s'endormir pendant un long travail.
Dans le #67766, 87 incidents sur 171 sont survenus moins de cinq secondes après l'appel précédent — un schéma que les coupures d'inactivité seules n'expliquent pas.
7. Régler le problème maintenant — check-list
Descendez la liste : le moins coûteux d'abord.
| N° | Quoi faire | Pourquoi |
|---|---|---|
| 1 | Répondre continue | L'étape de reprise documentée. Réutilise ce qui est déjà arrivé plutôt que de repartir de zéro. |
| 2 | Lancer claude --version et mettre à jour si c'est ancien | Vous obtenez l'amélioration des relances de la 2.1.198 et le correctif du pool de la 2.1.214. À faire en premier. |
| 3 | Vérifier les effets de bord (git status et compagnie) | Voir si des outils se sont exécutés partiellement avant la coupure. Évite les doubles exécutions. |
| 4 | Découper la tâche | Des réponses plus courtes, c'est moins de temps d'exposition. Séparez « lis tous les fichiers et écris le rapport » en étapes. |
| 5 | Contourner le proxy ou le VPN un moment et retester | Isole la couche 2. Si le problème cesse, le chemin est en cause. |
| 6 | Désactiver veille et économie d'énergie ; passer en filaire | Isole la couche 1 — surtout sur un portable qui enchaîne de longues tâches. |
| 7 | Essayer dans une session entièrement neuve | Le contournement temporaire signalé dans le #69336. Parfois efficace quand l'erreur explose juste après un résumé. |
| 8 | Si ça se reproduit, signaler avec les détails | Comme le conseille la documentation officielle de l'API, joignez le request_id (l'identifiant commençant par req_) pour accélérer l'analyse. |
Ce qu'il ne faut pas faire. Désactiver la vérification TLS (NODE_TLS_REJECT_UNAUTHORIZED=0 et consorts) sous prétexte que « la connexion tombe » traite un symptôme totalement différent et sacrifie la sécurité de tout votre trafic. Les erreurs de certificat sont une autre erreur, avec un autre remède.
8. Pour les développeurs — prévenir au niveau API/SDK
Si vous subissez la même catégorie de coupure via le Claude Agent SDK ou votre propre intégration à l'API, la documentation officielle des erreurs de l'API Claude fournit des repères de conception concrets.
La documentation recommande l'API Messages en streaming ou l'API Message Batches pour les requêtes longues, surtout au-delà de 10 minutes. Un max_tokens élevé sans streaming est la forme la plus exposée à la coupure.
La documentation indique qu'un keep-alive TCP réduit l'impact des délais d'inactivité si vous écrivez une intégration directe. Les SDK officiels le font déjà. À vérifier si vous avez écrit votre propre client HTTP.
Les SDK officiels relancent les échecs transitoires — erreurs de connexion, limites de débit, 5xx — deux fois par défaut, avec un backoff exponentiel et en respectant l'en-tête retry-after. Une option du client permet de modifier ou de désactiver ce comportement.
Le piège que la documentation signale explicitement : avec SSE, une erreur peut survenir après que l'API a renvoyé 200, donc elle ne suit pas le chemin standard de gestion des erreurs HTTP. Traitez à part les événements d'erreur en cours de flux.
Claude Code lui-même a pris cette direction en 2.1.179 et 2.1.199. Conserver les blocs reçus et demander la suite coûte moins cher — en jetons comme en effets de bord — que de tout jeter et renvoyer.
En 2.1.214, Claude Code a changé le pool keep-alive pour le désactiver après une erreur de connexion périmée, afin que les relances ouvrent un nouveau socket. Il vaut la peine de vérifier si votre relance ne reprend pas la même connexion morte.
Pour les charges de travail où vous préférez ne pas présupposer une connexion ininterrompue — le traitement par lots en est l'exemple évident —, la voie officiellement recommandée est l'API Message Batches, avec récupération des résultats par interrogation. Cela supprime structurellement le risque réseau au lieu de l'atténuer.
9. Distinguer des erreurs voisines
Les erreurs de transport de Claude Code se ressemblent beaucoup. Le plus rapide est de les trier selon la distance parcourue par la requête.
| Message | Où ça s'est arrêté | Réponse principale |
|---|---|---|
| Connection closed mid-response (cet article) | Connecté et flux démarré, puis coupé | continue / mise à jour / isolement du chemin |
| Response stalled mid-stream | Connexion vivante mais silencieuse | Traité à part (attention à l'enchaînement avec la boucle de répétition) |
| Server error mid-response | Une erreur 5xx ou de surcharge en cours de flux | Attendre puis réessayer. Voir l'article sur les 529/500 |
| Unable to connect / SSL certificate verification failed | Jamais connecté | Proxy, CA d'entreprise, pare-feu. Voir l'article sur les erreurs de connexion |
| Prompt is too long | Refusé avant l'envoi (le réseau va bien) | Réduire le contexte. Voir l'article dédié |
La grande bifurcation, c'est simplement de savoir si une réponse est apparue à l'écran. Si pas un seul caractère n'est passé, suspectez la connexion elle-même : configuration et chemin. Si de la sortie est apparue puis s'est arrêtée, c'est la preuve que la connexion fonctionnait ; cessez donc de retoucher les réglages et suivez plutôt la démarche d'isolement de cet article.
10. Statut officiel et ce qui reste non confirmé
Pour éviter toute confusion, voici ce qui peut être confirmé officiellement et ce qui ne le peut pas.
- Le message est formellement documenté dans la référence officielle des erreurs et signifie « la connexion a été rompue »
- La sortie déjà transmise est conservée — c'est voulu
- L'étape de reprise consiste à répondre
continue - Les échecs survenus avant toute sortie visible sont relancés automatiquement
- Des correctifs de gestion de connexion sont arrivés en 2.1.179 / 198 / 199 / 214
- Des serveurs envoyant un FIN en cours de flux (mesuré dans le #67766 — mais sous un autre message)
- L'implication d'un balayage à 60 secondes (déduction de l'auteur du signalement)
- Des pics juste après un compact (#69336)
- D'autres assistants IA qui ne tombent pas dans les mêmes conditions (comparaison de l'auteur du #69415)
- Une explication officielle de la cause par Anthropic (aucune réponse publique sur #69415, #69336 ni #67766)
- Une entrée de correctif nommant « Connection closed » (cette chaîne n'apparaît pas dans le changelog)
- #69415, #69336 et #67766 sont tous encore ouverts
En résumé : le symptôme et la conduite à tenir sont officiellement documentés, mais aucune explication officielle de la cause n'a été publiée. Dans ce contexte, les habitudes de travail l'emportent sur la chasse à la cause racine : gardez des tours courts, vérifiez l'état au fil des opérations à effets de bord, et restez sur une version récente.
FAQ
Q1. Quand « Connection closed mid-response » apparaît, la sortie déjà produite est-elle perdue ?
Non. Comme l'explicite la référence officielle des erreurs, tout ce qui a été transmis est conservé. Claude Code ajoute délibérément cette note au lieu de renvoyer la requête, car un renvoi pourrait exécuter deux fois les mêmes appels d'outils. Ce qui manque se limite le plus souvent aux dernières phrases ou au dernier appel d'outil.
Q2. Que faut-il répondre pour reprendre là où ça s'est arrêté ?
Répondez continue. C'est l'étape de reprise nommée dans la référence officielle des erreurs. Redonner la consigne initiale risque de dupliquer des opérations déjà exécutées.
Q3. Les jetons sont-ils gaspillés ?
Ce qui a été généré jusqu'à la coupure a bien été consommé. L'auteur du ticket #69336 note d'ailleurs que les jetons consommés ne sont pas remboursés. C'est précisément pour cela que passer par continue plutôt que de tout recommencer compte autant pour le coût que pour le temps.
Q4. Est-ce la même chose que « Response stalled mid-stream » ?
Non. Selon les définitions officielles, Connection closed signifie « la connexion a été rompue » et Response stalled signifie « le flux a cessé d'envoyer des données » : coupure contre silence. À l'écran cela se ressemble, mais la variante stalled a été signalée en combinaison avec une boucle de répétition du modèle, et le remède diffère. Voir l'article sur Response stalled mid-stream.
Q5. Est-ce mon réseau qui est en cause ?
C'est possible, mais pas nécessairement. L'auteur du ticket #69415 l'a observé sur une connexion directe, sans proxy ni pare-feu, et les captures réseau du ticket #67766 indiquent que la fermeture a été initiée côté serveur. Contournez d'abord tout proxy ou VPN et voyez si le problème persiste ; si rien ne change, ce n'est pas purement local.
Q6. Mettre Claude Code à jour va-t-il résoudre le problème ?
C'est le geste au meilleur rendement à essayer en premier. Le changelog officiel montre que la 2.1.198 a corrigé « les brèves coupures réseau en cours de réponse qui interrompaient le tour », et que la 2.1.214 a modifié le pool keep-alive pour le désactiver après une erreur de connexion périmée, afin que les relances ouvrent un nouveau socket. Le gros des signalements (2.1.173 à 2.1.183) est antérieur à tout cela. Mais comme aucune entrée du changelog ne nomme « Connection closed » en tant que telle, la mise à jour est une amélioration probable, pas un remède garanti.
Q7. Cela arrive sans arrêt sur les tâches longues. Existe-t-il un contournement ?
Découper la tâche pour raccourcir chaque réponse est l'option la plus fiable. Les traitements en bloc du type « lis tous les gros fichiers et rédige le rapport » exposent le flux très longtemps ; séparer la lecture de la rédaction réduit cette fenêtre et diminue la probabilité de tomber sur une coupure. Le ticket #69336 rapporte aussi qu'ouvrir une nouvelle conversation a aidé temporairement.
Q8. En tant que développeur, comment l'éviter dans mon application ?
Les repères de la documentation officielle de l'API Claude sont clairs : (1) toujours streamer les réponses longues, et envisager l'API Batches au-delà de 10 minutes ; (2) configurer un keep-alive TCP (les SDK officiels le font déjà) ; (3) avec SSE, des erreurs peuvent arriver après un 200, donc traitez à part les événements d'erreur en cours de flux ; (4) en cas de coupure, conservez ce que vous avez reçu et demandez la suite. Joignez le request_id lorsque vous contactez le support.
Q9. J'obtiens la même erreur dans Claude Cowork et l'Agent SDK.
Le même message y a été signalé. Le ticket #69517 le rapporte dans Claude Cowork (fermé comme doublon) et le #69336 via un Claude Agent SDK auto-hébergé. C'est un comportement de la couche qui gère les réponses en streaming ; l'approche reste donc la même : reprendre plutôt que redémarrer, rester sur une version récente et bien concevoir ses relances.
Articles liés
- Claude Code répète « court » puis « Response stalled mid-stream » : causes et solutions
- Erreurs réseau/proxy de Claude Code : Unable to connect to API et certificats TLS
- Claude Code : erreur 529 Overloaded / 500 — que faire
- Claude Code : « Prompt is too long » — corriger l'erreur de fenêtre de contexte
- Erreurs courantes de Claude Code et leurs correctifs — la référence complète
