Sommaire

Vous travailliez dans Claude Code quand soudain cette erreur apparait et que la session cesse completement de repondre ?

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.

Le pire : une fois qu'elle apparait, chaque saisie suivante declenche la meme erreur. Vous tapez, vous appuyez sur Entree, meme 400. La session entre dans un etat "bloque". Il s'agit d'un bug connu, avec plusieurs tickets ouverts sur le depot officiel d'Anthropic (#10199, #12225, #13012, #22278, #63147, et d'autres).

Disons-le d'emblee : 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 valide la signature octet par octet par rapport au contenu. Quand Claude Code reconstruit l'historique avec un bug — par exemple en vidant le texte du thinking tout en conservant la signature — la signature ne correspond plus et l'API rejette la requete. L'echappatoire la plus rapide consiste a "appuyer deux fois sur Esc et a faire /rewind jusqu'a un point de controle", ou a demarrer une nouvelle session. Cet article couvre le mecanisme, les 5 causes profondes, 3 solutions cote utilisateur, les contre-mesures pour developpeurs et la prevention des recidives.

CLAUDE CODE · ERREUR 400

Vue d'ensemble de l'erreur de bloc thinking

— Si la "signature" ne correspond pas, l'API rejette toute la conversation

SYMPTOME
Session bloquee
Chaque saisie repete le meme 400
CAUSE
Signature non concordante
Texte vide + signature residuelle
ECHAPPATOIRE LA PLUS RAPIDE
Esc×2 → /rewind
Revenir en arriere avant la corruption

Un bug connu avec plusieurs tickets sur le depot officiel d'Anthropic.
L'essentiel : la regle stricte de l'API selon laquelle "les blocs thinking doivent rester exactement tels que dans la reponse originale".

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 etre modifies. Ces blocs doivent rester tels qu'ils etaient dans la reponse originale."

Autrement dit, l'API vous signale : "Le 'bloc thinking' contenu dans l'historique de conversation que vous (le client) m'avez envoye differe de ce que j'ai renvoye la derniere fois. Il a ete modifie. Je ne vais donc pas l'accepter." L'API Claude part du principe que vous "incluez la reponse precedente 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 caractere". messages.3.content.40 est une indication de position : "le 41e bloc de contenu du 4e message" est l'endroit du probleme.

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 facon 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 mecanisme de "signature"

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

Quand Claude repond avec l'extended thinking active, il genere un "bloc thinking" avant la reponse. Il s'agit du raisonnement intermediaire de Claude — la maniere interne dont "il a reflechi", qui ameliore la qualite de la reponse finale. Ce bloc se voit attribuer une signature cryptographique — une sorte de signature numerique garantissant que "ce contenu de reflexion a bien ete genere par Claude et n'a pas ete altere".

Dans les conversations multi-tours et les boucles d'utilisation d'outils, tout l'echange precedent est renvoye a l'API a chaque fois. Les blocs thinking doivent eux aussi etre renvoyes, mais la signature est calculee sur "l'integralite du texte thinking original" — de sorte que si le texte change ne serait-ce que d'un caractere, la validation de la signature echoue. Pour des raisons de securite, l'API rejette les blocs thinking dont la signature ne correspond pas. C'est l'essence de l'erreur 400.

Pourquoi la signature existe

Empecher la modification des blocs thinking bloque le prompt injection et l'usurpation de la reflexion. C'est un mecanisme de securite qui protege le fait que "Claude a reellement pense cela" — cette severite a une raison.

3. Pourquoi cela arrive — 5 causes profondes

Les scenarios concrets de non-concordance de signature se classent en cinq — synthese des tickets officiels d'Anthropic et des retours de la communaute.

5 CAUSES PROFONDES

Cinq causes profondes de la non-concordance de signature

CAUSE 1 · Bug de reprise de session (la plus courante)
Claude Code vide le texte du thinking en "" mais conserve la signature. A la reprise, il envoie "texte vide + signature originale", ce qui echoue a la validation. Le classique Issue #63147.
CAUSE 2 · Entrelacement du streaming
Dans les longues sessions, des reponses API paralleles ou rapprochees s'entrelacent dans le JSONL. Des fragments de differents messages se melangent et l'ordre des blocs se casse.
CAUSE 3 · Logique de reparation qui derape
Le processus interne de reparation de l'historique de Claude Code reordonne ou altere les blocs thinking. Une reparation bien intentionnee finit par casser la signature.
CAUSE 4 · Proxy/SDK tiers
Les proxys relais (CLIProxyAPI, etc.) re-serialisent les messages et alterent le thinking. La cause principale des erreurs "Invalid signature".
CAUSE 5 · Modification de l'historique dans votre propre app
Dans les apps qui appellent vous-meme l'API/SDK, supprimer, resumer ou reformater les blocs thinking en plein milieu d'une boucle d'utilisation d'outils avant de les renvoyer. L'erreur d'implementation maison la plus frequente.

Le fil conducteur : si un bloc thinking differe de l'original ne serait-ce que d'un octet, vous obtenez toujours un 400.
Les causes 1 a 4 sont des bugs de Claude Code / du proxy ; la cause 5 est un probleme d'implementation maison.

4. Trois solutions immediates (pour les utilisateurs de Claude Code)

Quand votre session est bloquee, essayez trois methodes dans l'ordre de rapidite de recuperation.

3 SOLUTIONS

Trois solutions par rapidite de recuperation

SOLUTION 1 · /rewind (priorite absolue)
Appuyez deux fois sur Esc, ou executez /rewind. Revenez au point de controle precedant le tour corrompu. Le meilleur choix — il recupere en preservant le contexte.
SOLUTION 2 · Nouvelle session
/clear ou demarrez une nouvelle session. La plus fiable, mais perd le contexte. Notez/committez d'abord le travail important.
SOLUTION 3 · Reparation du JSONL
Retirez tous les blocs thinking du JSONL de session. Un outil communautaire (ci-dessous) supprime uniquement le thinking tout en conservant l'historique de conversation. Une manoeuvre avancee qui preserve le contexte.

Essayez d'abord la SOLUTION 1 (Esc×2 / rewind). Si elle echoue, SOLUTION 2. Si vous devez garder le contexte, SOLUTION 3.
Et mettez toujours Claude Code a jour vers la derniere version (Anthropic corrige cela progressivement).

Note sur la SOLUTION 3 : la communaute a publie 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 probleme de signature tout en conservant l'historique de conversation. Il vaut la peine d'etre adopte si vous rencontrez souvent ce probleme ou faites un usage intensif de longues sessions. Mais c'est un outil non officiel, donc a utiliser a vos propres risques — sauvegardez le JSONL avant de l'executer.

Le correctif permanent le plus important consiste a "maintenir Claude Code a la derniere version". Executez claude update ou suivez les etapes de mise a jour officielles. Anthropic deploie progressivement un "garde-fou defensif qui detecte les blocs thinking au texte vide avec signature et les retire avant l'envoi" pour cette serie de bugs (#10199, #12225, #63147, etc.). Les versions plus anciennes rencontrent le probleme plus souvent.

5. Pour les developpeurs : eviter le probleme dans votre app (API/SDK)

Si vous construisez vous-meme une app qui appelle l'API/SDK Claude (extended thinking + utilisation d'outils), vous rencontrerez la meme erreur dans votre propre implementation. Trois principes l'evitent.

// BAD: deleting/altering thinking blocks before sending back
const history = previousMessages.map(m => ({
  ...m,
  content: m.content.filter(b => b.type !== 'thinking') // mismatches signature
}));

// GOOD pattern 1: keep thinking blocks "exactly as-is"
// Push the assistant message from the API into history untouched
messages.push(assistantMessageFromApi); // keep the signature intact

// GOOD pattern 2: "fully drop" thinking from past turns
// Don't send empty text + signature; omit the block entirely
const clean = previousMessages.map(m => {
  if (m.role !== 'assistant') return m;
  return {
    ...m,
    content: m.content.filter(b =>
      b.type !== 'thinking' && b.type !== 'redacted_thinking'
    ),
  };
});
// NOTE: do NOT drop them from the "latest" assistant message (during tool use)

Les trois principes : ① Preservez integralement le texte thinking signe et faites-le transiter aller-retour intact. ② Si vous ne renvoyez pas le thinking des tours passes, retirez le bloc entier (texte vide avec signature est le pire des cas). ③ Ajoutez un garde-fou defensif au moment de la construction de la requete, qui detecte les blocs thinking "au texte vide mais avec signature" et les retire.

La regle d'or pour les boucles d'utilisation d'outils

Dans les boucles extended thinking + utilisation d'outils (tool_use → tool_result), n'alterez jamais le bloc thinking du "dernier" message de l'assistant. La requete suivante qui renvoie tool_result doit inclure le thinking + tool_use precedents exactement tels quels. Si vous utilisez le Claude Agent SDK ou le Vercel AI SDK, verifiez que la bibliotheque gere cela correctement.

6. Distinguer cette erreur des erreurs similaires

Il existe plusieurs erreurs 400 liees au thinking, faciles a confondre. Distinguons les trois principales.

Message d'erreurSignificationSolution principale
thinking blocks ... cannot be modifiedLe sujet de cet article. Non-concordance entre signature et contenu/rewind, nouvelle session, mise a jour vers la derniere version
Invalid signature in thinking blockLa signature elle-meme est invalide (souvent une alteration par le proxy)Revoir la config du proxy, se connecter directement a l'API
The final block in an assistant message cannot be thinkingLe message de l'assistant se termine par du thinking (il faut du text ou un tool_use a la fin)Corriger la structure du message, mettre a jour le SDK

La cause racine commune est "ne pas gerer correctement les blocs d'extended thinking". Pour les utilisateurs de Claude Code, la plupart se resolvent avec /rewind + mise a jour vers la derniere version. Pour les apps maison, vous devez revoir la structure du message et l'implementation de la bibliotheque. Si vous passez par un proxy (CLIProxyAPI, divers gateways), suspectez d'abord que le proxy altere le thinking.

7. Checklist de prevention des recidives

Une checklist pratique pour eviter des recidives frequentes.

Utilisateurs de Claude Code : ① Maintenez-le a la derniere version avec claude update (la plus grande prevention). ② Reinitialisez periodiquement les sessions tres longues avec /clear (reduit le risque d'entrelacement). ③ Committez frequemment sur git pour le travail important (recuperable meme en cas de blocage). ④ Envisagez un outil de reparation de JSONL si cela recidive souvent. ⑤ Signalez les reproductions sur les tickets officiels d'Anthropic (accelere les correctifs).

Developpeurs API/SDK : ① Injectez les messages de l'assistant dans l'historique sans alterer la reponse de l'API. ② Si vous abandonnez le thinking passe, retirez le bloc entier (pas de texte vide avec signature). ③ Ajoutez un garde-fou defensif a la construction de la requete (detecter texte vide avec signature → retirer). ④ Utilisez le SDK officiel le plus recent et minimisez le remodelage personnalise des messages. ⑤ Si vous etes derriere un proxy, verifiez 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 la signature cryptographique ne correspond plus au contenu. C'est un bug connu avec plusieurs tickets sur le depot officiel d'Anthropic, et dans la plupart des cas, ce n'est pas votre faute. Les cinq causes : bug de reprise de session (la plus courante), entrelacement du streaming, logique de reparation qui derape, proxys tiers, et modification de l'historique dans votre propre app.

Pour les utilisateurs de Claude Code, la recuperation la plus rapide est ① appuyer sur Esc×2 / /rewind jusqu'a un point de controle ; en cas d'echec, ② une nouvelle session (/clear) ; pour preserver le contexte, ③ un outil de reparation de JSONL. Le correctif permanent le plus important est "mettre Claude Code a jour vers la derniere version" — Anthropic deploie progressivement un garde-fou defensif. Les developpeurs API/SDK doivent suivre les trois principes : faire transiter les blocs thinking tels quels / les retirer completement si on les abandonne / ajouter un garde-fou defensif.

A lire aussi : Qu'est-ce que le Claude Agent SDK, guide complet du Vercel AI SDK, Qu'est-ce que Cursor, workflow de deploiement 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 apparait pendant l'utilisation de Claude Code, c'est presque certainement un bug connu cote Claude Code (un defaut de reconstruction de l'historique de session). Plusieurs tickets sont ouverts sur le depot officiel d'Anthropic et des correctifs sont en cours. Inutile de vous blamer. Ce n'est que pour les apps maison (qui appellent directement l'API) que vous devez revoir votre implementation.

Q. /rewind ne corrige pas le probleme. Et maintenant ?
A. Demarrer une nouvelle session (/clear) est la solution la plus fiable. Vous perdez le contexte mais vous echappez a coup sur a l'etat bloque. Mettez d'abord le travail important de cote via un git commit ou des notes. Si cela recidive, mettez Claude Code a jour vers la derniere version ; si cela persiste, envisagez un outil de reparation de JSONL.

Q. Puis-je l'eviter en desactivant l'extended thinking ?
A. Techniquement oui, mais l'extended thinking ameliore considerablement la precision sur les taches complexes, donc le desactiver n'est pas recommande. Traitez d'abord le probleme avec mise a jour vers la derniere version + /rewind, et n'envisagez cela qu'en dernier recours dans des environnements particuliers (par exemple derriere un proxy) ou cela recidive encore.

Q. L'outil de reparation de JSONL est-il sur ?
A. Il est non officiel, donc a utiliser a vos propres risques. Sauvegardez toujours le JSONL de session avant de l'utiliser. Le mecanisme est "retirer tous les blocs de contenu thinking tout en conservant l'historique de conversation", ce qui est sur en principe — mais le correctif officiel (mise a jour vers la derniere version) reste la vraie solution.

Q. Dans ma propre app, combiner l'utilisation d'outils avec le thinking declenche cette erreur.
A. La cause est "vous alterez le bloc thinking du dernier message de l'assistant". La requete suivante qui renvoie tool_result doit inclure les blocs thinking + tool_use precedents exactement tels que l'API les a renvoyes (avec signature). Si vous abandonnez le thinking des tours passes, retirez le bloc entier (pas de texte vide avec signature). Le SDK officiel le plus recent gere la majeure partie de cela automatiquement.