Erreur 400 "invalid signature in thinking block" dans Claude Code — causes et solutions

Vous travailliez dans Claude Code quand soudain cette erreur apparaît et que la session cesse complètement de répondre ?

API Error: 400 messages.3.content.40: `thinking` or
`redacted_thinking` blocks in the latest assistant message
cannot be modified. These blocks must remain as they were
in the original response.

Si la vérification de la signature d'un bloc thinking renvoyé échoue, c'est l'erreur ci-dessous qui peut s'afficher. Les deux ont la même origine : le bloc thinking n'est plus exactement celui de la réponse d'origine :

API Error: 400 messages.1.content.0:
invalid `signature` in `thinking` block

Le pire : une fois qu'elle apparaît, chaque saisie suivante déclenche la même erreur. Vous tapez, vous appuyez sur Entrée, même 400. La session entre dans un état "bloque". Il s'agit d'un bug connu, avec plusieurs tickets ouverts sur le dépôt officiel d'Anthropic (#10199, #12225, #13012, #22278, #63147, et d'autres).

Disons-le d'emblée : la cause est "la corruption des blocs d'extended thinking lors du renvoi de l'historique de conversation". Les blocs thinking portent une signature cryptographique, et l'API vérifie que les blocs thinking renvoyés sont inchangés par rapport à la réponse d'origine. Quand un bug de reconstruction de l'historique dans Claude Code fait différer un bloc de l'original, l'API rejette la requête. L'échappatoire la plus rapide consiste à "appuyer deux fois sur Esc et à faire /rewind jusqu'à un point de contrôle", ou à démarrer une nouvelle session. Cet article couvre le mécanisme, les 5 causes profondes, 3 solutions côté utilisateur, les contre-mesures pour développeurs et la prévention des recidives.

1. Ce que dit vraiment cette erreur

En clair, le message dit : "Les blocs thinking ou redacted_thinking du dernier message de l'assistant ne peuvent pas être modifiés. Ces blocs doivent rester tels qu'ils étaient dans la réponse originale."

Autrement dit, l'API vous signale : "Le 'bloc thinking' contenu dans l'historique de conversation que vous (le client) m'avez envoyé diffère de ce que j'ai renvoyé la dernière fois. Il a été modifie. Je ne vais donc pas l'accepter." L'API Claude part du principe que vous "incluez la réponse précédente dans l'historique et la renvoyez sans la changer" dans les conversations multi-tours — et le bloc thinking en particulier porte une contrainte stricte de "ne pas modifier un seul caractère". messages.3.content.40 est une indication de position : "le 41e bloc de contenu du 4e message" est l'endroit du problème.

Le point important : dans la plupart des cas, ce N'EST PAS une erreur dans votre code ou votre prompt. La cause principale est un bug dans la façon dont Claude Code reconstruit l'historique de conversation (le JSONL de session), qui corrompt les blocs thinking. Il n'y a donc aucune raison de vous tourmenter en vous demandant "est-ce que je m'en sers mal ?" — c'est un bug connu avec des contournements.

2. Contexte : l'extended thinking et le mécanisme de "signature"

Pourquoi seul le bloc thinking est-il aussi strict ? La raison tient au fonctionnement de l'extended thinking.

Quand Claude répond avec l'extended thinking activé, il génère un "bloc thinking" avant la réponse. Il s'agit du raisonnement intermédiaire de Claude — la manière interne dont "il a réfléchi", qui améliore la qualité de la réponse finale. Ce bloc se voit attribuer une signature cryptographique — une sorte de signature numérique garantissant que "ce contenu de réflexion a bien été généré par Claude et n'a pas été altéré".

Dans les conversations multi-tours et les boucles d'utilisation d'outils, tout l'échange précédent est renvoyé à l'API à chaque fois, et les blocs thinking doivent eux aussi être renvoyés. D'après la documentation officielle, la signature contient une copie chiffrée de l'intégralité de la réflexion : l'API s'en sert pour vérifier que le bloc renvoyé a bien été généré par Claude, et le serveur la déchiffre pour reconstituer la réflexion d'origine. Le texte thinking que vous voyez n'est qu'un résumé, et sur les modèles récents le réglage par défaut (display: "omitted") le laisse vide. La valeur de la signature est la même quel que soit le réglage de display, et tout texte placé dans le champ thinking d'un bloc omitted est ignoré. C'est pourquoi la documentation demande de renvoyer les blocs thinking exactement tels qu'ils ont été reçus, sans modification. Si la signature manque ou est corrompue, ou si le bloc ne correspond plus à la réponse d'origine, l'API rejette ce bloc thinking. C'est l'essence de l'erreur 400.

3. Pourquoi cela arrive — 5 causes profondes

Les scénarios concrets de non-concordance de signature se classent en cinq — synthèse des tickets officiels d'Anthropic et des retours de la communauté.

4. Trois solutions immédiates (pour les utilisateurs de Claude Code)

Quand votre session est bloquée, essayez trois méthodes dans l'ordre de rapidité de récupération.

Note sur la SOLUTION 3 : la communauté a publié un outil "Claude Code thinking blocks fix" (par exemple miteshashar/claude-code-thinking-blocks-fix sur GitHub). Il retire tous les blocs de contenu thinking du JSONL de session, eradiquant le problème de signature tout en conservant l'historique de conversation. Il vaut la peine d'être adopté si vous rencontrez souvent ce problème ou faites un usage intensif de longues sessions. Mais c'est un outil non officiel, donc à utiliser à vos propres risques — sauvegardez le JSONL avant de l'exécuter.

Le correctif permanent le plus important consiste à "maintenir Claude Code à la dernière version". Exécutez claude update ou suivez les étapes de mise à jour officielles. Le changelog de Claude Code aligne correctif sur correctif dans cette famille : entrelacement du streaming avec des agents concurrents (2.1.47), retrait préventif des signatures périmées après un changement de modèle ou de connexion (2.1.152), blocs thinking modifiés avec Opus 4.8 (2.1.156), et abandon des blocs thinking avec une seule nouvelle tentative après une erreur redacted_thinking (2.1.282). Malgré cela, #63147 se reproduirait encore en 2.1.157 selon des signalements, et reste ouvert au 4 octobre 2026. Les versions plus anciennes manquent davantage de ces correctifs.

5. Pour les développeurs : éviter le problème dans votre app (API/SDK)

Si vous construisez vous-même une app qui appelle l'API/SDK Claude (extended thinking + utilisation d'outils), vous rencontrerez la même erreur dans votre propre implémentation. La documentation officielle résume la prévention en une règle : renvoyer chaque tour de l'assistant exactement tel que l'API l'a renvoyé, blocs thinking compris, et n'ajouter de nouveaux messages qu'à la fin.

// BAD 1: rebuilding the assistant message from picked block types
const rebuilt = {
  role: 'assistant',
  content: [
    ...response.content.filter(b => b.type === 'thinking'), // drops redacted_thinking
    ...response.content.filter(b => b.type === 'tool_use'),
  ],
};

// BAD 2: deleting thinking blocks that have empty text and only a signature
// On newer models this is the normal shape (display defaults to "omitted")

// GOOD: push the assistant message from the API untouched, then append
messages.push({ role: 'assistant', content: response.content }); // thinking, redacted_thinking and signatures included
messages.push({ role: 'user', content: [toolResult] });          // new messages go at the end only

① Un bloc thinking au texte vide, avec seulement une signature, est normal. Sur les modèles les plus récents, display vaut "omitted" par défaut : le raisonnement complet est chiffré dans signature et le champ thinking arrive vide. Renvoyez-le tel quel, sans le compléter ni le supprimer (tout texte placé dans le champ thinking d'un bloc omis est ignoré).

② N'élaguez pas vous-même le thinking des tours passés. Si vous renvoyez tous les blocs, l'API garde ceux dont chaque modèle a besoin, retire le reste automatiquement et ne facture en entrée que les blocs réellement montrés à Claude. Hors utilisation d'outils, omettre le thinking des tours précédents est autorisé, mais sur les modèles les plus récents un bloc thinking ne reste valide que tant que le prompt system, les tools et les messages qui le précèdent ne changent pas : modifier un tour intermédiaire ou ne retirer que certains blocs invalide tous les blocs thinking suivants et renvoie une erreur 400 (Invalid signature in thinking block ; appliqué notamment aux comptes créés à partir du 31 août 2026). Pour alléger l'historique, confiez-le à l'édition de contexte côté serveur (effacement des blocs thinking) ou à la compaction.

③ Traitez les blocs redacted_thinking de la même façon. Un filtre qui garde ou retire seulement type === 'thinking' perd les redacted_thinking sans prévenir. Le guide de dépannage officiel cite comme causes les plus fréquentes de cette erreur le filtrage des blocs par type, qui fait perdre les redacted_thinking, et la reconstruction du message de l'assistant au lieu de le renvoyer tel quel (Thinking, Thinking troubleshooting, au 4 octobre 2026).

6. Distinguer cette erreur des erreurs similaires

Il existe plusieurs erreurs 400 liées au thinking, faciles à confondre. Distinguons les trois principales.

La cause racine commune est "ne pas gérer correctement les blocs d'extended thinking". Pour les utilisateurs de Claude Code, la plupart se résolvent avec /rewind + mise à jour vers la dernière version. Pour les apps maison, vous devez revoir la structure du message et l'implémentation de la bibliothèque. Si vous passez par un proxy (CLIProxyAPI, divers gateways), suspectez d'abord que le proxy altere le thinking.

7. Checklist de prévention des recidives

Une checklist pratique pour éviter des recidives fréquentes.

Utilisateurs de Claude Code : ① Maintenez-le à la dernière version avec claude update (la plus grande prévention). ② Réinitialisez périodiquement les sessions très longues avec /clear (réduit le risque d'entrelacement). ③ Committez fréquemment sur git pour le travail important (recuperable même en cas de blocage). ④ Envisagez un outil de réparation de JSONL si cela récidive souvent. ⑤ Signalez les reproductions sur les tickets officiels d'Anthropic (accélère les correctifs).

Développeurs API/SDK : ① Injectez les messages de l'assistant dans l'historique sans altérer la réponse de l'API (thinking, redacted_thinking et signature compris). ② Gardez un historique en ajout seul : ne modifiez pas les tours intermédiaires et ne retirez pas seulement certains blocs (laissez l'élagage à l'édition de contexte côté serveur ou à la compaction). ③ Ne supprimez pas les blocs thinking au texte vide avec signature (c'est la forme par défaut sur les modèles les plus récents). ④ Utilisez le SDK officiel le plus récent et minimisez le remodelage personnalisé des messages. ⑤ Si vous êtes derrière un proxy, vérifiez la transparence du thinking.

Conclusion

L'erreur 400 "thinking blocks ... cannot be modified" de Claude Code survient quand les blocs d'extended thinking sont corrompus lors du renvoi de l'historique et que qu'ils ne correspondent plus à la réponse d'origine. C'est un bug connu avec plusieurs tickets sur le dépôt officiel d'Anthropic, et dans la plupart des cas, ce n'est pas votre faute. Les cinq causes : bug de reprise de session / reconstruction de l'historique, entrelacement du streaming, logique de réparation qui dérape, proxys tiers, et modification de l'historique dans votre propre app.

Pour les utilisateurs de Claude Code, la récupération la plus rapide est ① appuyer sur Esc×2 / /rewind jusqu'à un point de contrôle ; en cas d'échec, ② une nouvelle session (/clear) ; pour préserver le contexte, ③ un outil de réparation de JSONL. Le correctif permanent le plus important est "mettre Claude Code à jour vers la dernière version" — le changelog aligne correctif sur correctif pour cette famille. Les développeurs API/SDK doivent renvoyer chaque tour de l'assistant tel quel, blocs thinking compris / garder un historique en ajout seul / ne pas supprimer les blocs au texte vide avec signature.

À lire aussi : Qu'est-ce que le Claude Agent SDK, guide complet du Vercel AI SDK, Qu'est-ce que Cursor, workflow de déploiement Claude Code/Cursor.

FAQ

Q. Cette erreur est-elle une erreur dans mon prompt ou mon code ?
A. Dans la plupart des cas, non. Si elle apparaît pendant l'utilisation de Claude Code, c'est presque certainement un bug connu côté Claude Code (un défaut de reconstruction de l'historique de session). Plusieurs tickets sont ouverts sur le dépôt officiel d'Anthropic et des correctifs sont en cours. Inutile de vous blâmer. Ce n'est que pour les apps maison (qui appellent directement l'API) que vous devez revoir votre implémentation.

Q. /rewind ne corrige pas le problème. Et maintenant ?
A. Démarrer une nouvelle session (/clear) est la solution la plus fiable. Vous perdez le contexte mais vous echappez à coup sûr à l'état bloque. Mettez d'abord le travail important de côté via un git commit ou des notes. Si cela récidive, mettez Claude Code à jour vers la dernière version ; si cela persiste, envisagez un outil de réparation de JSONL.

Q. Puis-je l'éviter en désactivant l'extended thinking ?
A. Techniquement oui, mais l'extended thinking améliore considérablement la précision sur les tâches complexes, donc le désactiver n'est pas recommandé. Traitez d'abord le problème avec mise à jour vers la dernière version + /rewind, et n'envisagez cela qu'en dernier recours dans des environnements particuliers (par exemple derrière un proxy) ou cela récidive encore.

Q. L'outil de réparation de JSONL est-il sûr ?
A. Il est non officiel, donc à utiliser à vos propres risques. Sauvegardez toujours le JSONL de session avant de l'utiliser. Le mécanisme est "retirer tous les blocs de contenu thinking tout en conservant l'historique de conversation", ce qui est sûr en principe — mais le correctif officiel (mise à jour vers la dernière version) reste la vraie solution.

Q. Dans ma propre app, combiner l'utilisation d'outils avec le thinking déclenche cette erreur.
A. La cause est "vous altérez le bloc thinking du dernier message de l'assistant". La requête suivante qui renvoie tool_result doit inclure les blocs thinking + tool_use précédents exactement tels que l'API les a renvoyés (avec signature). Inutile d'élaguer vous-même le thinking des tours passés : sur les modèles les plus récents, le retirer de certains tours seulement invalide les blocs thinking suivants. Un bloc au texte vide avec seulement une signature est la forme normale sur ces modèles ; renvoyez-le sans modification. Le SDK officiel le plus récent gère la majeure partie de cela automatiquement.

Erreurs Claude Code liées : référence des erreurs Claude Code, « court » et balises invoke, "Prompt is too long".

À lire aussi: La réflexion adaptative de Claude.