目录

你是否曾在 Claude Code 中工作时,突然冒出这个错误,然后整个会话彻底失去响应?

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.

如果回传的 thinking 块的 signature 验证失败，也可能显示下面这个错误。两者原因相同：thinking 块已不是原始响应中的样子：

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

最难受的地方在于:一旦出现,之后无论输入什么都会触发同样的错误。你打字、按下回车,还是同样的 400。会话进入“卡死”状态。这是一个 已知缺陷,在 Anthropic 官方仓库上有多个未关闭的 issue(#10199、#12225、#13012、#22278、#63147 等)。

先说结论:原因是“在重新发送对话历史时,extended thinking 块被破坏了。”thinking 块带有加密 signature,API 会检查发回的 thinking 块是否与原始响应完全一致。当 Claude Code 重建历史时的缺陷让某个块与原始响应不一致时,API 就会拒绝。最快的脱身办法是“按两次 Esc 并 /rewind 回退到检查点,”或者开启新会话。本文讲解机制、5 个根本原因、3 种面向用户的修复、面向开发者的对策,以及防止再次发生的方法。

CLAUDE CODE · 400 ERROR

thinking 块错误的全貌

— 若 signature 不匹配,API 会拒绝整段对话

症状
会话卡死
每次输入都重复同样的 400
原因
signature 不匹配
发回的 thinking 与原始响应不一致
最快脱身
Esc×2 → /rewind
回退到破坏之前

Anthropic 官方仓库上有多个 issue 的已知缺陷。
本质:API 的严格规则——“thinking 块必须与原始响应中完全一致。”

1. 这个错误到底在说什么

用大白话讲,这条消息的意思是:“最新一条助手消息中的 thinking 或 redacted_thinking 块不能被修改。这些块必须保持原始响应中的样子。”

也就是说,API 在告诉你:“你(客户端)发给我的对话历史里的 thinking 块,和我上次返回的不一样。它被改动过了。所以我不接受。”Claude API 假定在多轮对话中你会“把上一次的响应包含进历史并原样发回”——而 thinking 块尤其带有严格的“一个字符都不能改”约束。messages.3.content.40 是位置信息:“第 4 条消息的第 41 个内容块”就是出问题的地方。

关键点:大多数情况下这并不是你的代码或提示词的错误。主因是 Claude Code 重建对话历史(会话 JSONL)的方式存在缺陷,从而破坏了 thinking 块。所以不必纠结“是不是我用错了?”——这是有应对办法的已知缺陷。

2. 背景:extended thinking 与 signature 机制

为什么唯独 thinking 块这么严格?原因就在于 extended thinking 的工作方式。

当 Claude 在启用 extended thinking 的情况下回答时,它会在答案之前生成一个 “thinking 块”。这是 Claude 的中间推理——提升最终答案质量的内部“思考过程”。这个块会被赋予一个加密 signature——类似一种数字签名,保证“这段 thinking 内容确实由 Claude 生成,且未被改动。”

在多轮对话和 tool use 循环中，整段之前的交互每次都会发回 API，thinking 块也必须一并发送。根据官方文档，signature 里装着加密后的完整思考内容：API 用它来确认发回的 thinking 块确实由 Claude 生成，服务器端则解密它来还原原始的思考。你能看到的 thinking 文本只是摘要，在较新的模型上，默认设置（display: "omitted"）下它干脆是空的。无论 display 设成什么，signature 的值都一样；往 omitted 块的 thinking 字段里填文字，也会被忽略。所以官方要求把 thinking 块原样发回、不做任何改动。如果 signature 缺失或损坏，或者这个块已经和原始响应对不上，API 就会拒绝这个 thinking 块。这就是这个 400 错误的本质。

signature 为何存在

禁止修改 thinking 块可以阻止 prompt injection 与思考伪造。它是一种安全机制,保护“Claude 确实是这样思考的”这一事实——严格是有原因的。

3. 为什么会发生——5 个根本原因

signature 不匹配的具体场景可归为五类——综合自 Anthropic 官方 issue 与社区报告。

5 ROOT CAUSES

signature 不匹配的五个根本原因

原因 1 · 会话恢复 / 历史重建缺陷
恢复会话或重建历史时,发回的 thinking 块与原始响应不再一致。Issue #63147 的报告者推测原因是“空文本 + signature”的保存形式,但这在新模型上是正常形式(第 5 节),帖子里也有人提出异议。Anthropic 尚未公布官方原因。
原因 2 · 流式交错
在长会话中,并行或快速连续的 API 响应在 JSONL 中交错。不同消息的分片混在一起,块顺序被打乱。
原因 3 · 修复逻辑失控
Claude Code 内部的历史修复流程重排或改动了 thinking 块。本意良好的修复最终破坏了 signature。
原因 4 · 第三方代理/SDK
中继代理(CLIProxyAPI 等)重新序列化消息并改动 thinking。是 “Invalid signature” 错误的主因。
原因 5 · 在自己的应用中改动历史
在自己调用 API/SDK 的应用中,在 tool use 循环中途删除、摘要或重新格式化 thinking 块后再发回。这是最常见的自建实现错误。

共同点:只要 thinking 块与原始内容哪怕相差一个字节,就一定会得到 400。
原因 1–4 是 Claude Code / 代理的缺陷;原因 5 是自建实现的问题。

4. 立刻可用的三种修复(面向 Claude Code 用户)

当会话卡死时,按恢复速度顺序尝试三种方法。

3 FIXES

按恢复速度排列的三种修复

修复 1 · /rewind(首选)
按两次 Esc,或运行 /rewind。回退到出错那一轮之前的检查点。最佳之选——在保留上下文的同时恢复。
修复 2 · 新会话
/clear 或开启全新会话。最可靠,但会丢失上下文。先把重要工作记录下来或提交。
修复 3 · JSONL 修复
从会话 JSONL 中剥离全部 thinking 块。社区工具(见下)只移除 thinking 而保留对话历史。保留上下文的进阶做法。

先试 修复 1(Esc×2 / rewind)。不行就用修复 2。若必须保留上下文,用修复 3。
并且始终把 Claude Code 更新到最新版(Anthropic 正在逐步修复)。

关于修复 3:社区已发布一款 “Claude Code thinking blocks fix” 工具(例如 GitHub 上的 miteshashar/claude-code-thinking-blocks-fix)。它会从会话 JSONL 中移除所有 thinking 内容块,在保留对话历史的同时根除 signature 问题。如果你经常遇到这个问题或大量使用长会话,值得采用。但它是非官方工具,请自担风险——运行前请备份 JSONL。

最重要的永久性修复是“让 Claude Code 保持最新版。”运行 claude update 或按官方更新步骤操作。Claude Code 的 changelog 里,这一类问题的修复接连出现:并发代理导致的流式交错(2.1.47)、切换模型或登录后预先剥离残留的旧 signature(2.1.152)、使用 Opus 4.8 时 thinking 块被改动(2.1.156)、出现 redacted_thinking 错误时丢弃 thinking 块并重试一次(2.1.282)等。不过,有报告称 #63147 在 2.1.157 上仍可复现,截至 2026 年 10 月 4 日仍未关闭(open)。版本越旧,缺少的修复越多。

5. 面向开发者:在自己的应用中预防(API/SDK)

如果你自己构建调用 Claude API/SDK 的应用（extended thinking + tool use），也会在自己的实现里遇到同样的错误。官方文档把预防归结为一条规则：把 API 返回的每条助手消息连同 thinking 块原样发回，新消息只追加在末尾。

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

① 正文为空、只有 signature 的 thinking 块是正常的。在较新的模型上，display 默认为 "omitted"：完整的思考加密存放在 signature 里，thinking 字段返回为空。原样发回即可，不要补写也不要删除（在 omitted 块的 thinking 字段里填写的文字会被忽略）。

② 不要自己裁剪过去轮次的 thinking。把所有块都发回，API 会按模型保留所需的块、自动移除其余部分，输入也只按实际展示给 Claude 的块计费。在 tool use 之外，省略过去轮次的 thinking 是允许的；但在较新的模型上，thinking 块只在它之前的 system 提示、tools 和消息都未改变时才有效——修改中间的某一轮或只删掉部分块，会让之后所有 thinking 块失效并返回 400（Invalid signature in thinking block；例如适用于 2026 年 8 月 31 日及以后创建的账户）。想精简历史，就交给服务端的 context editing（清除 thinking 块）或 compaction。

③ redacted_thinking 块也同样处理。只保留或只排除 type === 'thinking' 的过滤器，会悄悄丢掉 redacted_thinking。官方故障排查指南指出，这个错误最常见的原因是按类型过滤内容块而丢掉 redacted_thinking，以及重建助手消息而不是原样回传（Thinking、Thinking troubleshooting，截至 2026 年 10 月 4 日）。

tool use 循环的铁律

在 extended thinking + tool use 循环中(tool_use → tool_result),绝不要改动“最新”那条助手消息的 thinking 块。返回 tool_result 的下一个请求必须原样包含前面的 thinking + tool_use。如果你使用 Claude Agent SDK 或 Vercel AI SDK,请确认该库正确处理了这一点。

6. 与相似错误的区分

有几种与 thinking 相关的 400 错误,容易混淆。区分主要的三种。

错误消息含义主要修复
thinking blocks ... cannot be modified本文主题。signature 与内容不匹配/rewind、新会话、更新到最新版
Invalid signature in thinking blocksignature 验证失败：thinking 块在原始响应之后被改动或损坏（重建历史时，或中途的代理改写了内容）/rewind、新会话、更新到最新版；经由代理时也检查代理配置
The final block in an assistant message cannot be thinking助手消息以 thinking 结尾(结尾需要 text 或 tool_use)修正消息结构,更新 SDK

共同的根本原因是“没有正确处理 extended thinking 块。”对 Claude Code 用户来说,大多数情况通过 /rewind + 更新到最新版即可解决。对自建应用来说,需要检查消息结构与库的实现。如果经过代理(CLIProxyAPI、各类网关),首先怀疑代理改动了 thinking。

7. 防止再次发生的检查清单

一份防止频繁复发的实用清单。

Claude Code 用户:① 用 claude update 保持最新版(最重要的预防)。② 定期用 /clear 重置很长的会话(降低交错风险)。③ 重要工作频繁提交到 git(即便卡死也可恢复)。④ 若频繁复发,考虑 JSONL 修复工具。⑤ 把复现情况报告到 Anthropic 官方 issue(加快修复)。

API/SDK 开发者：① 把助手消息不加改动地放入历史（连同 thinking、redacted_thinking 和 signature）。② 历史只追加：不修改中间轮次，也不只删部分块（裁剪交给服务端的 context editing 或 compaction）。③ 不要删除正文为空但带 signature 的 thinking 块（这是较新模型的默认形式）。④ 使用最新官方 SDK，尽量减少自定义的消息重塑。⑤ 若处于代理之后，验证 thinking 的透传。

总结

Claude Code 的 “thinking blocks ... cannot be modified” 400 错误发生在重新发送历史时 extended thinking 块被破坏、与原始响应不再一致之时。这是 Anthropic 官方仓库上有多个 issue 的已知缺陷,大多数情况下不是你的错。五个原因:会话恢复 / 历史重建缺陷、流式交错、修复逻辑失控、第三方代理,以及在自己的应用中改动历史。

对 Claude Code 用户而言,最快的恢复是① 按 Esc×2 / /rewind 回退到检查点;若不行,② 新会话(/clear);要保留上下文,③ JSONL 修复工具。最重要的永久性修复是“把 Claude Code 更新到最新版”——changelog 里这一类问题的修复接连出现。API/SDK 开发者应做到把助手消息连同 thinking 块原样发回 / 历史只追加 / 不删除正文为空但带 signature 的块。

相关阅读:什么是 Claude Agent SDK、Vercel AI SDK 完全指南、什么是 Cursor、Claude Code/Cursor 部署工作流。

FAQ

Q. 这个错误是我的提示词或代码出了问题吗?
A. 大多数情况下不是。如果它出现在使用 Claude Code 时,几乎肯定是 Claude Code 侧的已知缺陷(会话历史重建的缺陷)。Anthropic 官方仓库上有多个 issue 处于开放状态,修复正在进行。无需自责。只有自建应用(直接调用 API)才需要检查自己的实现。

Q. /rewind 解决不了,接下来怎么办?
A. 开启新会话(/clear)最可靠。你会丢失上下文,但一定能脱离卡死状态。先用 git commit 或记录保存好重要工作。若复发,把 Claude Code 更新到最新版;若仍然出现,考虑 JSONL 修复工具。

Q. 关掉 extended thinking 能避免它吗?
A. 技术上可以,但 extended thinking 能显著提升复杂任务的准确度,因此不建议关掉。先用更新到最新版 + /rewind 应对,只在特殊环境(例如代理之后)仍反复出现时,才把它作为最后手段考虑。

Q. JSONL 修复工具安全吗?
A. 它是非官方的,请自担风险。使用前务必备份会话 JSONL。其机制是“在保留对话历史的同时移除所有 thinking 内容块”,原理上是安全的——但官方修复(更新到最新版)仍是真正的解决之道。

Q. 在我自己的应用里,把 tool use 与 thinking 结合会触发这个错误。
A. 原因是“你改动了最新那条助手消息的 thinking 块。”返回 tool_result 的下一个请求必须原样包含 API 返回的前面的 thinking + tool_use 块(连同 signature)。过去轮次的 thinking 无需自己裁剪；在较新的模型上，只从部分轮次删除会让之后的 thinking 块失效。正文为空、只有 signature 的块是这些模型的正常形式，请原样发回。最新官方 SDK 会自动处理其中大部分。

相关的 Claude Code 错误：Claude Code 错误大全、“court”+invoke 标签泄露、“Prompt is too long”。

相关文章: Claude 自适应思考解析.