Sommaire
- 1. Ce qui se passe réellement — le token « court » et les balises invoke
- 2. Contexte : un agent « génère » aussi ses appels d'outils
- 3. Pourquoi cela arrive — deux causes racines et leurs déclencheurs
- 4. Trois idées reçues courantes, rectifiées
- 5. Le corriger maintenant (pour les utilisateurs de Claude Code)
- 6. Pour les développeurs : le prévenir via l'API/SDK
- 7. Le distinguer des erreurs similaires
- 8. Statut officiel
- 9. Liste de vérification pour la prévention
- Conclusion
- FAQ
Si vous avez mené de longues sessions dans Claude Code, vous avez peut-être vu une chaîne de caractères étrange surgir soudainement à l'écran :
court
<invoke name="Bash">
<parameter name="command">ssh host 'cp file file.bak ; sed -i ...'</parameter>
<parameter name="description">…description de la commande…</parameter>
</invoke>
Your tool call was malformed and could not be parsed. Please retry.Un appel d'outil (une commande) qui était censé s'exécuter en coulisses fuit dans le chat sous forme de texte brut — et ne s'exécute jamais. En tête se trouve un mot dénué de sens, court (ou call). Il est naturel de s'inquiéter : « ma machine est-elle cassée ? » ou « ai-je mal configuré quelque chose ? » Mais la réponse courte est : ce n'est ni votre environnement, ni votre commande.
Il s'agit d'un dysfonctionnement côté modèle dans lequel Claude (en particulier la famille Opus 4.8 / 4.7) corrompt les « balises de contrôle » d'un appel d'outil au moment même où il les génère. Le dépôt officiel d'Anthropic contient de nombreuses issues ouvertes à ce sujet (#64108, #64150, #64690, #65705, #66153, #67295, #68354, et d'autres). Cet article expose le mécanisme, les causes, les idées reçues courantes, les correctifs pour utilisateurs et développeurs, la façon de le distinguer d'erreurs similaires, et le statut officiel — en s'appuyant sur la documentation d'Anthropic et les issues réelles. Le geste le plus important, à retenir d'emblée : quand court apparaît, ne vous acharnez pas dans cette session — sortez tôt vers une session fraîche (/clear). La raison est expliquée plus bas.
Ce que sont vraiment « court » et les balises invoke qui fuient
— une balise de contrôle est générée corrompue, elle fuit donc à l'écran au lieu de s'exécuter
Un appel corrompu ne peut pas être interprété, donc il n'est jamais exécuté (fail-closed) — aucun risque qu'une mauvaise commande s'exécute.
Les vrais problèmes sont un tour gaspillé, et une « réaction en chaîne » si on le laisse sans surveillance.
1. Ce qui se passe réellement — le token « court » et les balises invoke
Les <invoke name="Bash"> et <parameter name="command"> que vous voyez sont du « balisage d'appel d'outil » que vous n'êtes jamais censé voir. Quand Claude exécute une commande ou édite un fichier, il génère ces balises structurées de style XML sous forme de tokens, et Claude Code (le harnais) les interprète puis exécute réellement la commande. Normalement le harnais absorbe les balises, elles n'atteignent jamais l'écran, et vous ne voyez que le résultat de l'outil.
Cette fois, en revanche, le « token de contrôle d'ouverture » de l'appel d'outil a été généré corrompu, avec le mot sans rapport court ou call qui s'est glissé en tête. Le harnais ne réagit qu'à une syntaxe stricte, il décide donc que « ceci n'est pas un appel d'outil, juste du texte » et le diffuse tel quel à l'écran. La commande ne s'exécute pas, et vous obtenez « Your tool call was malformed and could not be parsed. » Dans certains cas il n'y a aucun message d'erreur et cela se fige simplement en silence (dans l'issue #65705 la réponse est revenue avec stop_reason=end_turn sans rien à exécuter, si bien que la conversation est restée bloquée).
Le mot court lui-même n'a aucune signification. Mais ce n'est pas non plus un mot totalement aléatoire et isolé — à travers plusieurs rapports indépendants, la fuite apparaît sous la forme court / call avec une régularité troublante. L'issue #64690 l'analyse comme « un token adjacent dans le vocabulaire sélectionné à la place de la balise correcte. » Autrement dit, court se comprend mieux comme une signature qui vous aide à reconnaître ce bug.
2. Contexte : un agent « génère » aussi ses appels d'outils
Pourquoi une « balise de contrôle » peut-elle se casser tout court ? La clé est que pour un agent IA, un appel d'outil n'est en fin de compte que de la génération de texte.
Quand vous utilisez des outils avec l'API Claude, le format que vous voyez en tant que développeur est du JSON (un bloc tool_use). En interne, cependant, le modèle suit un prompt système caché qu'Anthropic injecte automatiquement et génère les balises englobantes <function_calls>, <invoke> et <parameter> sous forme de flux de tokens. La couche API les interprète ensuite et les convertit en un bloc tool_use JSON propre (conformément à la documentation officielle sur l'usage des outils). Chaque « appel d'outil » dans MCP et les agents IA repose sur ce mécanisme.
Ce qui compte ici, c'est que le parseur du harnais est « fail-closed » (il penche du côté sûr). Si une balise diffère de la forme attendue ne serait-ce que d'un token, le harnais ne devine pas et ne l'exécute pas — il la rejette immédiatement comme malformée. C'est la bonne conception de harnais : « corriger utilement » une commande ambiguë puis l'exécuter serait bien plus dangereux. Tout ce phénomène est donc un cas de « cassé → rejeté → non exécuté » — autrement dit, il a échoué en toute sécurité.
En une phrase
Un appel d'outil est « du texte avec des balises spéciales » que le modèle génère. Quand le token d'ouverture de ces balises se casse pendant la génération, le harnais ne peut pas le reconnaître, il fuit donc dans la prose et ne s'exécute pas. Le rejet en soi est un mécanisme de sécurité correct ; le bug réside purement dans la génération côté modèle.
3. Pourquoi cela arrive — deux causes racines et leurs déclencheurs
En consolidant les issues réelles, la cause se scinde en « (1) corruption au moment de la génération » et la « (2) réaction en chaîne par auto-empoisonnement » qui la rend pénible.
Comment cela casse, puis « s'enchaîne »
· Plusieurs appels d'outils dans un seul message / un appel d'outil placé juste après de la prose (#66153)
· L'état juste après l'exécution de
/compact (#67295 : se reproduit au premier appel après compact)· Bash en arrière-plan (run_in_background) ou 3 serveurs MCP connectés ou plus (#64690)
· Des arguments d'outil longs de la taille d'un paragraphe (#49747 : une variante distincte où du XML déborde dans le JSON)
À retenir : la casse en soi est une rare fluctuation d'échantillonnage. La partie vraiment pénible est l'enchaînement de (2) —
c'est pourquoi « s'acharner avec des réessais dans la même session » peut être le pire choix.
4. Trois idées reçues courantes, rectifiées
L'information sur ce phénomène s'embrouille facilement. Pour réagir correctement, voici trois idées reçues courantes remises au clair.
| Croyance répandue | Réalité |
|---|---|
| « L'outil s'est emballé / a dysfonctionné » | Le contraire. L'appel cassé a été rejeté sans s'exécuter (fail-closed). Aucun risque qu'une mauvaise commande s'exécute ; tout ce qui s'est passé est un « tour gaspillé + une fuite visuelle. » Il a échoué en toute sécurité. |
| « Réessaie, ça se répare tout seul si tu le laisses » | À moitié vrai seulement. Un cas léger se rétablit après un réessai, mais une fois que le bloc cassé siège dans l'historique, le modèle l'imite et s'enchaîne. #65705 a connu 14 échecs d'affilée sur plus de 5 heures ; #66153 en a vu plus de 30 dans une seule session. S'acharner dans la même session se retourne contre vous. |
« court signifie quelque chose / est une commande » | Cela ne signifie rien — juste un débris d'un token de contrôle corrompu. Mais court/call reviennent comme un marqueur, ils sont donc utiles comme signe de diagnostic. |
La deuxième est la plus importante. Les rapports d'incident disent souvent « ça s'est rétabli au réessai, donc aucun problème » — mais cela ne vaut que pour le cas « léger » avant que l'enchaînement ne commence. L'essence de ce bug est qu'une fois entré en mode chaîne, aucune quantité de réessais dans cette session ne le corrigera.
5. Le corriger maintenant (pour les utilisateurs de Claude Code)
La réponse dépend de « êtes-vous encore en cas léger, ou l'enchaînement a-t-il commencé ? » Par ordre de priorité :
Ordre de priorité
court apparaît, /clear ou démarrez une nouvelle session tôt. Couper l'historique empoisonné est le plus fiable. Avant de bouger, sauvegardez l'état avec git commit ou une note de passation./compact a été rapporté comme se reproduisant juste après — ce n'est pas un correctif fiable.
La règle : « deux ratés, abandonnez la session et repartez à neuf. »
Plus vous vous acharnez dans un historique empoisonné, plus la plaie se creuse. Maintenez la CLI à jour (mais notez : aucun correctif n'a encore été livré — la mise à jour est de l'hygiène, pas un remède miracle).
Astuce : si vous sauvegardez systématiquement l'état dans git ou une note de passation .md, passer à une nouvelle session à n'importe quel moment ne vous coûte rien. Plus vous menez de longues sessions autonomes, plus cette habitude paie (et elle se rattache directement à la gestion de votre fenêtre de contexte).
6. Pour les développeurs : le prévenir via l'API/SDK
Si vous construisez votre propre agent sur l'API / le SDK Claude, vous pouvez ajouter les défenses suivantes dans votre harnais. La logique de détection proposée dans l'issue #65705 est pratique.
// Inspecter le tour assistant reçu avant de l'exécuter
const text = assistantText(resp);
const looksLeaked =
/<invoke\s+name=/.test(text) ||
/function_calls/.test(text) ||
/\bcourt\s*<invoke/.test(text);
// 1) Balisage ci-dessus présent mais AUCUN bloc tool_use structuré → appel cassé
if (looksLeaked && !hasToolUseBlock(resp)) {
// 2) Ne pas l'afficher ; le journaliser. Ne PAS garder le bloc cassé dans l'historique (prévient l'auto-empoisonnement)
// 3) Inciter à « l'émettre comme tool_use structuré, pas comme texte » et réessayer automatiquement
return retryWithNudge(messages);
}
// Rejeter un tool_use incomplet causé par une troncature
if (resp.stop_reason === 'max_tokens' && lastBlock(resp)?.type === 'tool_use') {
return retryWith({ max_tokens: higher }); // ne pas exécuter
}Quatre principes. (1) Toujours vérifier stop_reason (un end_turn sans qu'aucun outil ne s'exécute réellement = détectez le blocage silencieux). (2) Avant d'exécuter, vérifiez que le texte ne contient pas <invoke name= ni function_calls ; si c'est le cas, réessayez au lieu d'exécuter. (3) Ne gardez pas le bloc cassé dans l'historique de conversation (le garder fait que la génération suivante l'imite — auto-empoisonnement / #62344). (4) Gardez les arguments d'outil courts et découpez les longues sorties (évitez la variante à charge utile longue de #49747). Même en utilisant un harnais officiel comme le Claude Agent SDK, il vaut la peine de comprendre comment se comportent les boucles de longue durée.
7. Le distinguer des erreurs similaires
Il existe plusieurs erreurs du type « l'outil ne s'exécute pas », et elles appellent des correctifs différents. Distinguez ces quatre cas pour ne pas les confondre.
| Symptôme | Ce que c'est vraiment | Correctif principal |
|---|---|---|
| court / call + balises invoke brutes affichées, non exécutées | Le sujet de cet article. Corruption de génération du token de contrôle + enchaînement par auto-empoisonnement | Préférez une session fraîche (/clear) ; ne vous acharnez pas après deux ratés |
| 400 « thinking blocks cannot be modified » bloque la session | Une incohérence de signature dans le raisonnement étendu (un bug différent). Une erreur API irrécupérable | Voir l'article dédié (Échap×2 / rewind) |
| La réponse est coupée en plein flux (pas de XML corrompu) | Une troncature normale due à l'atteinte de max_tokens. Pas une erreur | Augmentez max_tokens et relancez |
| Le XML n'est pas structuré sur Bedrock, LangChain, etc. | Un client tiers qui échoue à interpréter le format d'Anthropic (langchain-aws #521). Ne se reproduit pas sur l'API officielle / Claude Code | Réexaminez la bibliothèque d'intégration / la couche d'hébergement |
L'axe de distinction est simple. Si vous voyez un « court / call corrompu + du XML brut », c'est ce bug. Une erreur de signature 400 est l'erreur de bloc de raisonnement. Une coupure nette n'est que la limite de sortie. Uniquement sur Bedrock ou via LangChain pointe vers la couche d'intégration. Pour d'autres erreurs courantes de Claude Code, voir le récapitulatif des erreurs.
8. Statut officiel
En juin 2026, il n'existe aucun correctif officiel confirmé (entrée de changelog) déclarant ce phénomène résolu. En retraçant les notes de version jusqu'au dernier Claude Code (la lignée 2.1.183), il n'y a aucune entrée traitant la corruption de sérialisation des appels d'outils, et beaucoup des issues liées restent ouvertes, ou classées « duplicate / stale ». Ainsi, chaque correctif de cet article est un contournement en attendant un correctif officiel, et vous ne pouvez pas affirmer que « la mise à jour vers la dernière version le corrige » (la mise à jour est recommandée, mais ce n'est pas un remède garanti).
Cela dit, la conception fail-closed du harnais, « rejeter un appel cassé plutôt que de l'exécuter à l'aveugle », est en soi correcte. Ce qui doit être corrigé, c'est la stabilité de génération du modèle — et non assouplir le parseur pour « le réparer et l'exécuter quand même », ce qui inviterait le risque sérieux d'exécuter la mauvaise commande. La meilleure chose que nous, utilisateurs, puissions faire est d'opérer pour éviter l'enchaînement, et de signaler les reproductions aux issues officielles avec votre environnement et vos logs (plus de signalements relèvent la priorité et accélèrent le correctif).
9. Liste de vérification pour la prévention
Utilisateurs de Claude Code : (1) Quand court/call apparaît, réessayez au maximum deux fois ; si cela persiste, /clear / nouvelle session immédiatement. (2) Évitez les sessions très longues / sur plusieurs jours ; sauvegardez le travail dans git/notes aux points de rupture. (3) Ne tassez pas plusieurs appels d'outils dans un seul message. (4) Rappelez-vous que /compact n'est pas une panacée (il peut se reproduire juste après). (5) Maintenez la CLI à jour, et signalez les reproductions aux issues officielles.
Développeurs API/SDK : (1) Vérifiez toujours stop_reason. (2) Détectez <invoke name= / function_calls qui fuient dans le texte et réessayez. (3) Ne gardez pas les appels cassés dans l'historique (prévenez l'auto-empoisonnement). (4) Gardez les arguments d'outil courts ; découpez les longues sorties. (5) N'exécutez jamais un tool_use incomplet issu d'une coupure max_tokens — réessayez à la place.
Conclusion
Dans Claude Code, « court / call + une balise <invoke> brute affichée, sans que l'outil ne s'exécute » est un dysfonctionnement côté modèle dans lequel Claude (la famille Opus 4.8 / 4.7) génère le token de contrôle d'un appel d'outil sous une forme corrompue. Le harnais le rejette en fail-closed, donc il n'y a aucun risque qu'une mauvaise commande s'exécute (il a échoué en toute sécurité). La partie vraiment pénible est qu'une fois que le bloc cassé reste dans l'historique, le modèle l'imite et « s'enchaîne ». Ainsi, « réessayer le corrige » ne vaut que tant que c'est léger, et la règle devient « deux ratés, sortez vers une session fraîche ».
La cause est à deux niveaux : (1) corruption de génération du token de contrôle + (2) enchaînement par auto-empoisonnement. Les déclencheurs incluent les sessions longues / sur plusieurs jours, un contexte lourd, l'état post-/compact, plusieurs outils simultanés, 3 serveurs MCP ou plus, et de longs arguments d'outil. Comme aucun correctif officiel n'a été livré en juin 2026, chaque remède est un contournement. Les utilisateurs devraient « préférer une session fraîche + sauvegarder l'état souvent » ; les développeurs devraient « vérifier stop_reason, réessayer à la détection d'une fuite, ne jamais garder d'historique cassé, et raccourcir les arguments. » Lire l'erreur 400 de bloc de raisonnement, le récapitulatif des erreurs de Claude Code et MCP en parallèle vous rendra bien plus résilient face aux problèmes d'appels d'outils.
FAQ
Q. Le « court » ou la balise invoke à mon écran sont-ils causés par une erreur dans ma commande ou mes réglages ?
A. Non — presque certainement pas. C'est un dysfonctionnement côté modèle connu où Claude génère les balises d'appel d'outil sous une forme corrompue, avec plusieurs issues ouvertes dans le dépôt officiel d'Anthropic (#64108, #65705, #66153, et d'autres). Ce n'est pas une erreur de votre environnement, de votre commande ou de vos réglages. Considérez court/call comme une « signature » du bug.
Q. Une mauvaise commande pourrait-elle s'exécuter et endommager mon serveur ou mes fichiers lorsque cela arrive ?
A. Non. Un appel d'outil cassé est jugé « malformé » et rejeté sans s'exécuter (conception fail-closed). Tout ce qui se passe est que le tour est gaspillé et que le texte de contrôle devient visible ; il n'y a aucun effet sur vos données ou l'état de votre serveur. C'est conçu pour échouer en toute sécurité.
Q. J'ai entendu dire « réessaie et ça se répare tout seul ». Est-ce vrai ?
A. Uniquement quand c'est léger. Lors d'une première occurrence isolée, une incitation à « continuer » fait souvent qu'il ré-émet correctement. Mais une fois que le bloc cassé reste dans l'historique de conversation, le modèle l'utilise comme modèle et répète la même corruption (auto-empoisonnement). À ce stade, réessayer dans la même session se retourne contre vous. S'il échoue deux fois de suite, arrêtez de vous acharner et passez à une session fraîche (/clear).
Q. /compact va-t-il le corriger ?
A. Pas de façon fiable. Compacter le contexte aide parfois, mais dans l'issue #67295 cela s'est reproduit au tout premier appel d'outil juste après /compact. Le geste le plus fiable n'est pas /compact mais une session fraîche (/clear) qui réinitialise entièrement l'historique. Sauvegardez votre état de travail dans git ou des notes avant de bouger.
Q. Mettre Claude Code à jour vers la dernière version va-t-il le corriger ?
A. Vous ne pouvez pas dire que cela le « corrige ». En juin 2026, il n'existe aucune entrée de changelog officielle confirmant un correctif, et beaucoup des issues liées restent ouvertes ou en duplicate. La mise à jour est recommandée comme hygiène, mais ce n'est pas un remède miracle. Pour l'instant, la meilleure approche est d'opérer pour éviter l'enchaînement (deux ratés → session fraîche) et de signaler les reproductions aux issues officielles.
