Erro 400 "thinking blocks cannot be modified" no Claude Code — causas e soluções

Você estava trabalhando no Claude Code e de repente este erro aparece e a sessão para de responder por completo?

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.

A parte ruim: uma vez que aparece, cada entrada seguinte dispara o mesmo erro. Você digita, pressiona Enter e volta o mesmo 400. A sessão entra em um estado "travado". É um bug conhecido, com vários issues abertos no repositório oficial da Anthropic (#10199, #12225, #13012, #22278, #63147 e outros).

De antemão: a causa é "os blocos de extended thinking ficarem corrompidos quando o histórico da conversa é reenviado". Os blocos de thinking carregam uma signature criptográfica, e a API valida a signature contra o conteúdo byte a byte. Quando o Claude Code reconstrói o histórico com um bug — por exemplo, esvaziando o texto de thinking mas mantendo a signature — a signature deixa de coincidir e a API o rejeita. A saída mais rápida é "pressionar Esc duas vezes e voltar a um checkpoint com /rewind", ou iniciar uma nova sessão. Este artigo cobre o mecanismo, as 5 causas-raiz, 3 soluções para o usuário, contramedidas para desenvolvedores e a prevenção da recorrência.

1. O que esse erro está realmente dizendo

Em termos simples, a mensagem diz: "Os blocos de thinking ou redacted_thinking da última mensagem do assistente não podem ser modificados. Esses blocos devem permanecer como estavam na resposta original."

Ou seja, a API está dizendo: "O 'bloco de thinking' dentro do histórico de conversa que você (o cliente) me enviou difere do que eu retornei da última vez. Ele foi modificado. Então não vou aceitá-lo." A API do Claude pressupõe que, em conversas multi-turno, você "inclui a resposta anterior no histórico e a reenvia sem alterações" — e o bloco de thinking, em particular, carrega uma restrição rígida de "não mudar um único caractere". messages.3.content.40 é informação de posição: "o 41º bloco de conteúdo da 4ª mensagem" é onde está o problema.

O ponto importante: na maioria dos casos isto NÃO é um erro do seu código nem do seu prompt. A causa principal é um bug em como o Claude Code reconstrói o histórico de conversa (o JSONL da sessão), corrompendo os blocos de thinking. Então não precisa se atormentar com "será que estou usando errado?" — é um bug conhecido com soluções de contorno.

2. Contexto: extended thinking e o mecanismo de "signature"

Por que só o bloco de thinking é tão rígido? A razão está em como o extended thinking funciona.

Quando o Claude responde com extended thinking ativado, ele gera um "bloco de thinking" antes da resposta. É o raciocínio intermediário do Claude — o "como ele pensou" interno que eleva a qualidade da resposta final. A esse bloco é atribuída uma signature criptográfica — algo como uma assinatura digital que garante "este conteúdo de thinking foi genuinamente gerado pelo Claude e não foi alterado."

Em conversas multi-turno e loops de tool-use, toda a troca anterior é reenviada à API a cada vez. Os blocos de thinking também precisam ser enviados, mas a signature é calculada sobre "o texto de thinking original completo" — então, se o texto mudar mesmo em um caractere, a validação da signature falha. Por segurança, a API rejeita os blocos de thinking cuja signature não coincide. Essa é a essência do erro 400.

3. Por que acontece — 5 causas-raiz

Os cenários concretos em que a signature não coincide se agrupam em cinco — sintetizados a partir dos issues oficiais da Anthropic e de relatos da comunidade.

4. Três soluções imediatas (para usuários do Claude Code)

Quando sua sessão estiver travada, tente três métodos em ordem de velocidade de recuperação.

Nota sobre a SOLUÇÃO 3: a comunidade publicou uma ferramenta "Claude Code thinking blocks fix" (por exemplo, miteshashar/claude-code-thinking-blocks-fix no GitHub). Ela remove todos os blocos de conteúdo de thinking do JSONL da sessão, erradicando o problema da signature e mantendo o histórico de conversa. Vale a pena adotá-la se você sofre com isso com frequência ou usa muito sessões longas. Mas é uma ferramenta não oficial, então use por sua conta e risco — faça um backup do JSONL antes de executá-la.

A solução permanente mais importante é "manter o Claude Code na última versão". Execute claude update ou siga os passos oficiais de atualização. A Anthropic está implantando de forma progressiva uma "proteção defensiva que detecta os blocos de thinking com texto vazio mais signature e os remove antes do envio" para essa série de bugs (#10199, #12225, #63147, etc.). As versões antigas sofrem com isso com mais frequência.

5. Para desenvolvedores: previna no seu próprio app (API/SDK)

Se você constrói um app que conecta você mesmo à API/SDK do Claude (extended thinking + tool use), vai esbarrar no mesmo erro na sua própria implementação. Três princípios o previnem.

// 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)

Os três princípios: ① Preserve por completo o texto de thinking assinado e faça o round-trip intacto. ② Se não for enviar o thinking de turnos passados, remova o bloco inteiro (texto vazio mais signature é o pior caso). ③ Adicione uma proteção defensiva na montagem da requisição que detecte os blocos de thinking com "texto vazio mas com signature" e os remova.

6. Como distinguir de erros parecidos

Há vários erros 400 relacionados a thinking, fáceis de confundir. Distinga os três principais.

A causa-raiz compartilhada é "não tratar corretamente os blocos de extended thinking". Para os usuários do Claude Code, a maioria se resolve com /rewind + atualização para a última versão. Para apps artesanais, é preciso revisar a estrutura das mensagens e a implementação da biblioteca. Se você passa por um proxy (CLIProxyAPI, vários gateways), suspeite primeiro de que o proxy está alterando o thinking.

7. Checklist para evitar a recorrência

Um checklist prático para evitar que se repita com frequência.

Usuários do Claude Code: ① Mantenha-o na última versão com claude update (a maior medida preventiva). ② Reinicie periodicamente as sessões muito longas com /clear (reduz o risco de entrelaçamento). ③ Faça commit no git com frequência no trabalho importante (recuperável mesmo que trave). ④ Considere uma ferramenta de reparo de JSONL se se repetir muito. ⑤ Relate as reproduções nos issues oficiais da Anthropic (acelera as correções).

Desenvolvedores de API/SDK: ① Insira as mensagens do assistente no histórico sem alterar a resposta da API. ② Se descartar thinking passado, remova o bloco inteiro (nada de texto vazio mais signature). ③ Adicione uma proteção defensiva na montagem da requisição (detectar texto vazio mais signature → remover). ④ Use o último SDK oficial e minimize o remodelamento personalizado de mensagens. ⑤ Se estiver atrás de um proxy, verifique a transparência do thinking.

Resumo

O erro 400 "thinking blocks ... cannot be modified" do Claude Code acontece quando os blocos de extended thinking ficam corrompidos no reenvio do histórico e a signature criptográfica deixa de coincidir com o conteúdo. É um bug conhecido com vários issues no repo oficial da Anthropic, e na maioria dos casos não é culpa sua. As cinco causas: bug ao retomar a sessão (a mais comum), entrelaçamento de streaming, lógica de reparo fora de controle, proxies de terceiros e modificação do histórico no seu próprio app.

Para os usuários do Claude Code, a recuperação mais rápida é ① pressionar Esc×2 / /rewind até um checkpoint; se falhar, ② uma nova sessão (/clear); para preservar o contexto, ③ uma ferramenta de reparo de JSONL. A solução permanente mais importante é "atualizar o Claude Code para a última versão" — a Anthropic está implantando de forma progressiva uma proteção defensiva. Os desenvolvedores de API/SDK devem seguir os três princípios: fazer round-trip dos blocos de thinking como estão / removê-los por completo se forem descartá-los / adicionar uma proteção defensiva.

Relacionado: O que é o Claude Agent SDK, guia completo do Vercel AI SDK, O que é o Cursor, fluxo de deploy com Claude Code/Cursor.

FAQ

Q. Esse erro é um erro do meu prompt ou do meu código?
A. Na maioria dos casos, não. Se ele aparece durante o uso do Claude Code, é quase com certeza um bug conhecido do lado do Claude Code (um defeito ao reconstruir o histórico da sessão). Há vários issues abertos no repo oficial da Anthropic e as correções estão em andamento. Não precisa se culpar. Só em apps artesanais (que conectam direto à API) é preciso revisar a implementação.

Q. O /rewind não resolve. E agora?
A. Iniciar uma nova sessão (/clear) é o mais confiável. Você perde o contexto, mas sai do estado travado com certeza. Guarde primeiro o trabalho importante via git commit ou notas. Se se repetir, atualize o Claude Code para a última versão; se continuar acontecendo, considere uma ferramenta de reparo de JSONL.

Q. Posso evitá-lo desativando o extended thinking?
A. Tecnicamente sim, mas o extended thinking melhora bastante a precisão em tarefas complexas, então desativá-lo não é recomendável. Primeiro contorne com atualização para a última versão + /rewind, e considere isso apenas como último recurso em ambientes especiais (por exemplo, atrás de um proxy) onde ainda se repita.

Q. A ferramenta de reparo de JSONL é segura?
A. É não oficial, então use por sua conta e risco. Faça sempre um backup do JSONL da sessão antes de usá-la. O mecanismo é "remover todos os blocos de conteúdo de thinking mantendo o histórico de conversa", o que é seguro em princípio — mas a correção oficial (atualizar para a última versão) continua sendo a solução real.

Q. No meu próprio app, combinar tool use com thinking dispara esse erro.
A. A causa é "você está alterando o bloco de thinking da última mensagem do assistente". A próxima requisição que retorna tool_result deve incluir os blocos de thinking + tool_use precedentes exatamente como a API os retornou (com a signature). Se descartar o thinking de turnos passados, remova o bloco inteiro (nada de texto vazio mais signature). O último SDK oficial cuida da maior parte disso automaticamente.