已知问题与排错

本文档根据社区报告和官方通告，追踪影响 Claude Code 用户的已验证严重问题。

最后更新：2026 年 4 月 23 日来源：GitHub Issues + Anthropic 官方通告

---

🚨 当前活跃严重问题

0. 提示缓存 Bug——静默费用膨胀（2026 年 3 月至今）

严重程度：🔴 高 - 成本影响状态：⚠️ 部分修复（截至 v2.1.88，Bug 3 和 Bug 2 仍活跃）Issue：#40524首次报告：2026 年 3 月受影响版本：v2.1.69+（Bug 2 & 3），v2.1.36+ 独立二进制文件（Bug 1）

问题描述

三个独立的 Bug 破坏了 Anthropic 基于前缀的提示缓存，导致产生 cache_creation 费用（全额 Token（词元）成本）而非 cache_read（折扣价）。实测的费用影响取决于使用模式：

• 单独 Bug 3（归因头）：每次会话启动和每次子智能体调用时，约 1.2 万 Token（词元）的系统提示费用膨胀 2-5 倍
• Bug 2 激活时（恢复 + 10 个以上 Skills（技能模块））：每次恢复重建 8.7-11.8 万 Token（词元）；拥有 3-4 次恢复的会话实测缓存命中率为 4.3-34.6%（健康状态应为 95-99%），最差的会话每轮成本达到正常的 10-20 倍
• 叠加效果：应用变通方法后，缓存命中率从 48% 提升至 99.98%（社区实测，CC#40524）

依据：通过社区逆向工程（CC#40524）、泄露的 npm sourcemap 源码分析以及独立会话 JSONL 分析（ArkNill，2026 年 4 月）确认。Anthropic 在 v2.1.88 中发布了部分修复（工具 Schema 字节）。Bug 2 和 Bug 3 仍未修复。

Bug 2——--resume / --continue 时完整缓存重建（v2.1.69+）——高影响

根本原因：会话 JSONL 写入器在写入磁盘前剥离了 deferred_tools_delta 附件记录。--resume 时，这些记录已消失——因此延迟工具层没有之前的公告历史，从头重新公告所有工具。这改变了恢复对话中每条消息的位置，完全破坏了消息级别的缓存前缀。

具体证据（来自社区会话 JSONL 分析，拥有 14 个 Skills（技能模块）的会话）：

条目	cache_read	cache_creation	事件
102	84,164	174	正常轮次
103	0	87,176	恢复——完整重建
105	87,176	561	已恢复
166	115,989	221	正常轮次
167	0	118,523	恢复——完整重建

每次恢复 = 8.7-11.8 万 Token（词元）以 cache_creation 而非 cache_read 重建。每会话 3-4 次恢复 = 30-40 万个可避免的费用 Token（词元）。影响随 Skills（技能模块）/延迟工具数量线性增长：拥有 10 个以上 Skills（技能模块）的用户（框架配置中很常见）在每次恢复时都会看到 0% 的缓存命中率。

变通方法：在修复发布前避免使用 --resume 和 --continue。开启新会话。降级选项：npm install -g @anthropic-ai/claude-code@2.1.68（回归前的最后一个版本）。Anthropic 正在内部追踪此问题（在源代码遥测中标记为 inc-4747）。

工程修复：在写入会话 JSONL 时保留 deferred_tools_delta 和 mcp_instructions_delta 记录，这样恢复时就能正确计算增量，而不是重新公告所有内容。

Bug 3——归因头（低至中等影响，v2.1.69+）

根本原因：Claude Code 在每次 API 请求时将一个计费头作为系统提示的第一个块注入。该头包含一个从你第一条用户消息的字符中派生的 3 字符哈希，使其在每个会话、每个子智能体和每个附加查询中都是唯一的。由于 Anthropic 的缓存基于前缀，这个唯一的第一块在每次会话启动和子智能体调用时都会对约 1.2 万 Token（词元）的系统提示造成冷未命中。

细节（来自 jmarianski，原始逆向分析师）：每次会话系统提示的冷未命中在实践中"影响边际"，因为系统提示相对于总会话上下文而言较小。对于重度用户，恢复 Bug（Bug 2）具有更大的可测量成本。

实测：应用变通方法后，缓存命中率从 48% 提升至 99.98%——但这反映了与其他缓存因素的综合效果；单独 Bug 3 的影响可能更小。

变通方法（立即应用，风险低）：

// ~/.claude/settings.json
{
  "env": {
    "CLAUDE_CODE_ATTRIBUTION_HEADER": "false"
  }
}

接受的值："false"、"0"、"no"、"off"。无需重启。

Bug 1——哨兵字符串替换（独立二进制 v2.1.36+，边缘情况）

根本原因：Bun 的原生 HTTP 栈在序列化后替换请求体中的 cch=00000 占位符。如果此确切字符串出现在你的消息内容中（例如，来自讨论此 Bug 的 CLAUDE.md），它可能在错误的位置被替换。

变通方法：不要在 CLAUDE.md 或配置文件中字面粘贴 cch=00000。注意：这只影响独立二进制文件，不影响 npm/npx 安装。

审计工具

运行 /check-cache-bugs（从 examples/commands 目录安装）在约 20 秒内审计你的设置是否存在所有三个 Bug。

最佳实践：在新会话开始时运行，或通过 claude -p "$(cat .claude/commands/check-cache-bugs.md)" 以单次模式运行，以避免用 cch= 字符串污染当前会话上下文（潜在的 Bug 1 触发器）。

监控缓存健康状况

要验证你的会话是否健康，使用官方的 ANTHROPIC_BASE_URL 环境变量通过本地透明代理路由，并从 API 响应中记录 cache_creation_input_tokens / cache_read_input_tokens：

// ~/.claude/settings.json
{
  "env": {
    "ANTHROPIC_BASE_URL": "http://localhost:8080"
  }
}

在 8080 端口运行一个读取但不修改请求/响应的透传代理，解析每个响应中的 usage 对象。健康会话显示缓存命中率 > 80%；受影响会话显示 < 40%。

或者，直接检查 ~/.claude/projects/ 中的会话 JSONL 文件——查找每轮的 cache_creation_input_tokens 和 cache_read_input_tokens。

用于监控的社区工具：

• cc-diag — 基于 mitmproxy 的 Claude Code 流量分析
• claude-code-router — 带日志记录的透明代理

社区补丁（同时应用 Bug 1 和 Bug 2 修复）：

• cc-cache-fix — 社区开发的补丁 + 测试工具包

官方响应

v2.1.88 中发布了部分修复（工具 Schema 字节）。Bug 2 和 Bug 3 已确认仍然活跃。

追踪：Issue #40524（自 2026 年 3 月起开放）

相关 Issue：#40652（cch= 计费哈希）· #41663（缓存 Token（词元）消耗）· #41607（重复压缩子智能体）· #41767（v2.1.89 自动压缩循环）· #41750（上下文管理每轮触发）

---

1. GitHub Issue 在错误仓库中自动创建（2025 年 12 月至今）

严重程度：🔴 严重 - 安全/隐私风险状态：⚠️ 活跃（截至 2026 年 1 月 28 日）Issue：#13797首次报告：2025 年 12 月 12 日受影响版本：v2.0.65+

问题描述

Claude Code 系统性地在公开的 anthropics/claude-code 仓库中创建 GitHub Issue，而非用户的私有仓库，即使在本地 git 仓库目录中工作时也如此。

影响

高 - 隐私/安全：至少 17+ 起确认案例显示用户意外在公开仓库中暴露了敏感信息：

• 数据库 Schema
• API 凭证和配置详情
• 基础设施架构
• 私有项目路线图
• 安全配置

症状

• Issue 以意外的 --repo anthropics/claude-code 标志创建
• 私有项目详情出现在公开的 anthropics/claude-code Issue 中
• 在公开仓库中创建 Issue 前无确认提示
• 在本地 git 仓库中要求 Claude "创建 Issue" 时发生

意外创建示例

近期确认案例（2026 年 1 月）：

• #20792："Deleted - created in wrong repo"（已删除 - 在错误仓库中创建）
• #16483、#16476："Claude OPENS ISSUES ON THE WRONG REPO"（Claude 在错误仓库中创建 Issue）
• #17899："Claude Code suddenly decided to create issue in claude code repo"（Claude Code 突然决定在 claude code 仓库中创建 Issue）
• #16464："[Mistaken Post] Please delete"（[错误发布] 请删除）

完整列表：[搜索 "wrong repo" 或 "delete this"](https://github.com/anthropics/claude-code/issues?q=is:issue "wrong repo" OR "delete this")

根本原因（假设）

Claude Code 可能混淆了：

• 关于 Claude Code 本身的合法反馈 → anthropics/claude-code（正确）
• 用户项目 Issue → 当前仓库（应为默认）

该工具似乎将 anthropics/claude-code 硬编码或过度优先为默认目标。

变通方法

🛡️ 通过 Claude Code 创建任何 GitHub Issue 之前：

1. 始终验证目标仓库：

2. 明确指定仓库：

3. 执行前审查命令：

   • 查找 --repo anthropics/claude-code 标志
   • 如果存在且不正确，中止并指定正确的仓库

4. 在 Claude 设置中对所有 gh 命令使用手动审批

5. 在 Bug 修复之前，切勿在 Issue 创建提示中包含敏感信息

如果你受到影响

如果你意外创建了暴露敏感信息的 Issue：

1. 立即联系 GitHub 支持请求删除 Issue（不只是关闭）
2. 轮换任何已暴露的凭证（API 密钥、密码、Token（词元））
3. 如涉及安全敏感内容，通过 安全邮件 向 Anthropic 报告
4. 检查数据泄露：监控已暴露信息的使用情况

官方响应

截至 2026 年 1 月 28 日：Issue 仍然开放，未宣布官方修复。

追踪：Issue #13797（自 2025 年 12 月 12 日起开放）

---

2. Token（词元）消耗过高（2026 年 1 月至今）

严重程度：🟠 高 - 成本影响状态：⚠️ 已报告（Anthropic 正在调查）Issue：#16856首次报告：2026 年 1 月 8 日受影响版本：v2.1.1+（已报告），可能影响更早版本

问题描述

多位用户报告 Token（词元）消耗速度比以往快 4 倍以上，导致：

• 速率限制比正常情况更快触达
• 相同工作流消耗的 Token（词元）显著增多
• 意外的费用增加

症状

来自 Issue #16856：

"从今天早上更新到 CC 2.1.1 开始——使用量简直荒谬。我在同一个项目上工作了几个月，相同的工作流，相同的时间。但今天触达 5 小时限制的速度快了 4 倍以上！"

常见报告：

• 周限额在 1-2 天内耗尽（正常为 5-7 天）
• 会话在 2-3 条消息后就达到 90% 的上下文
• 相同操作下 Token（词元）消耗达到正常的 4-20 倍

背景

节假日使用奖励到期：2025 年 12 月 25-31 日，Anthropic 作为节日礼物将使用限额提高了一倍。当限额于 2026 年 1 月 1 日恢复正常后，用户产生了"容量减少"的感知。

然而，报告在此时间节点之后仍在持续，表明可能存在潜在问题。

Anthropic 响应

来自 The Register（2026 年 1 月 5 日）：

"Anthropic 表示'认真对待所有此类报告，但尚未发现与 Token（词元）使用相关的任何缺陷'，并表示已排除其推理栈中的 Bug。"

状态：截至 2026 年 1 月 28 日，Anthropic 尚未将其正式确认为 Bug。

相关 Issue

发现 20+ 份报告（2025 年 12 月 - 2026 年 1 月）：

• #17687："Unexpectedly high token consumption rate since January 2026"（2026 年 1 月以来意外的高 Token（词元）消耗率）
• #16073："[Critical] Claude Code Quality Degradation - Ignoring Instructions, Excessive Token Usage"（[严重] Claude Code 质量退化 - 忽略指令、过度 Token（词元）使用）
• #17252："Excessive token consumption rate in session usage tracking"（会话使用追踪中的过高 Token（词元）消耗率）
• #13536："Excessive token usage on new session initialization"（新会话初始化时的过度 Token（词元）使用）

[完整搜索](https://github.com/anthropics/claude-code/issues?q=is:issue excessive token created:2025-12-01..2026-01-28)

变通方法

在 Anthropic 调查期间：

1. 主动监控 Token（词元）使用情况：定期检查已使用的 Token（词元）与容量的比例

2. 使用更短的会话：

   • 在接近 50-60% 上下文时重启会话
   • 将复杂任务分解为多个会话

3. 禁用自动压缩（可能有帮助）：

4. 减少 MCP 工具（如果不需要）：

   • 检查 ~/.claude.json（字段 "mcpServers"）
   • 禁用未使用的服务器

5. 使用子智能体处理隔离任务：

   • 子智能体拥有独立的上下文窗口
   • 对复杂操作使用任务工具

6. 追踪你的使用模式：

   • 比较版本升级前后的情况
   • 记录异常峰值

调查提示

如果遇到过度消耗：

1. 记录你的 Claude Code 版本：claude --version
2. 比较版本：如果可用，使用较早的稳定版本测试
3. 记录规律：哪些操作触发了高使用量？
4. 附带数据报告：在 Issue 报告中包含版本、操作类型、Token（词元）计数

---

✅ 已解决的历史问题

三重框架事故：思考力度、思考 Token（词元）和冗长度（2026 年 3 月 - 4 月）

严重程度：🔴 高状态：✅ 已解决（截至 2026 年 4 月 20 日，三个问题均已解决）时间线：2026 年 3 月 4 日 – 4 月 20 日

问题描述

三个独立的框架和系统提示词变更在六周时间内降低了 Claude Code 的输出质量。没有一个是模型级别的退化；全都发生在 Claude Code 框架层。直接使用 Anthropic API（不经过 Claude Code 框架）不受影响。

事故 1：默认思考力度从高降为中（3 月 4 日，4 月 7 日回滚）

触发因素：高思考力度模式下的长延迟使某些会话的 UI 看起来像卡死了。变更：Anthropic 将 Sonnet 4.6 和 Opus 4.6 的默认推理思考力度从 high 改为 medium。影响：未手动设置 /effort high 的用户静默地获得了中等质量的推理。产品内指示器仍显示"高"，掩盖了超过一个月的退化。受影响版本：Sonnet 4.6、Opus 4.6。解决方案：4 月 7 日回滚。新默认值：Opus 4.7 为 xhigh，所有其他模型为 high。改进的 UI 迭代（思考旋转动画、更清晰的 /effort 体验）随之发布。

事故 2：空闲后每轮清除思考 Token（词元）（3 月 26 日，4 月 10 日修复）

触发因素：Anthropic 发布了一项变更，当会话空闲超过一小时时一次性清除思考 Token（词元）（以减少恢复时的延迟和缓存成本）。Bug：代码缺陷导致清除操作在会话剩余时间内的每一轮后都触发，而不只是在恢复时触发一次。影响：会话变得健忘和重复，Claude 在恢复的对话过程中逐渐丢失上下文。受影响版本：Sonnet 4.6、Opus 4.6。解决方案：2026 年 4 月 10 日修复（v2.1.101）。根据 Boris Cherny（CC 团队）的说明，根本原因是：大型空闲会话导致完整缓存未命中（90 万+ Token（词元）），在恢复时为 Pro 用户带来了显著的 Token（词元）成本峰值。

事故 3：冗长度系统提示词指令（4 月 16 日，4 月 20 日回滚）

触发因素：Anthropic 添加了一条系统提示词指令以降低响应冗长度。影响：与当时其他活跃的提示词变更叠加后，编程质量明显下降。受影响版本：Sonnet 4.6、Opus 4.6、Opus 4.7。解决方案：4 月 20 日回滚。四天的暴露时间，是三起事故中解决最快的。

社区影响

• Reddit、HN、X/Twitter 上广泛的质量退化报告（2026 年 3-4 月）
• Pro 和 Max 订阅者取消订阅
• Anthropic 员工（包括 Boris Cherny）最初在评论区回应，但未承认系统性问题
• 披露当天 HN 讨论串达到 250+ 条评论

Anthropic 响应

官方更新：关于近期 Claude Code 质量报告的更新（2026 年 4 月 23 日）

帖子中的关键承诺：

• 重置所有订阅者的使用限额（4 月 23 日）
• 更多内部员工将使用与公众完全相同的构建版本（而非功能测试构建）
• "未来展望"部分承诺改进评估和发布实践

Boris Cherny 在 HN 评论中的关键引述：

"我们同意，将在未来几周内加大对精致度、质量和可靠性的投入。"

解决方案：三个问题均于 2026 年 4 月 7-20 日间解决。

---

模型质量退化（2025 年 8-9 月）

严重程度：🔴 严重状态：✅ 已解决（2025 年 9 月中旬）时间线：2025 年 8 月 25 日 - 9 月初

问题描述

用户报告 Claude Code 产生：

• 比之前版本更差的输出
• 意外的语法错误
• 意外的字符插入（英文响应中出现泰文/中文）
• 基础任务失败
• 不正确的代码编辑

根本原因

Anthropic 确认了三个基础设施 Bug（非模型退化）：

1. 流量路由错误：约 30% 的 Claude Code 请求被路由到错误的服务器类型 → 降级响应
2. 输出损坏：8 月 25 日部署的错误配置导致 Token（词元）生成错误
3. XLA:TPU 编译错误：性能优化触发了潜在的编译器 Bug，影响 Token（词元）选择

社区影响

• 大规模取消订阅运动（2025 年 8-9 月）
• 社区理论：为降低成本而故意降低模型质量（量化）
• Reddit 情绪急剧下降

Anthropic 响应

官方事故复盘：三个近期问题的事后分析（2025 年 9 月 17 日）

关键引述：

"我们从不因需求、时间或服务器负载而降低模型质量。用户报告的问题仅仅是由基础设施 Bug 造成的。"

解决方案：所有 Bug 均于 2025 年 9 月中旬修复。

---

🔄 大语言模型日常性能差异

类型：预期行为（非 Bug）严重程度：🟡 低 - 认知层面状态：固有于大语言模型推理，不针对特定版本

这是什么

即使使用完全相同的提示词和干净的上下文窗口，Claude 的输出质量也可能在不同会话间出现明显差异。这与上下文窗口退化（随着上下文填满在会话内发生）不同。这里说的是不同新鲜会话之间的差异。

用户有时会报告响应更短、建议更保守，或在前一天正常工作的任务上出现意外拒绝。这可能感觉像模型降级，但实际上并非如此。

根本原因

概率推理：温度高于 0 意味着每次推理运行都是非确定性的。对同一提示词的两次运行将产生不同的 Token（词元）序列。这是语言模型工作方式的基础。

混合专家路由差异：Claude 使用混合专家（MoE）架构。在每次前向传递时，路由机制选择激活哪些专家权重。不同的运行激活不同的组合，即使对语义相同的输入也会产生不同的输出。

基础设施差异：在生产环境中，请求会命中具有不同负载水平、硬件代次和热状态的不同服务器。这些因素影响推理过程中浮点运算的数值精度，产生微妙但真实的输出差异。

上下文敏感性：即使使用 /clear，会话之间的微小差异也会积累。系统提示词、工具列表和会话初始化都会略微影响模型的初始输出。

可观察信号

信号	你看到的	这意味着什么
响应长度	比平时更短、更简洁	路由命中了更保守的路径
拒绝	通常能工作的边缘情况被拒绝	此次运行的安全校准不同
代码风格	比预期更冗长或更简洁	激活的专家组合不同
创造力	建议更保守、更缺乏创意	不是能力损失，而是采样结果
冗长度	比平时更多警告和免责声明	Token（词元）概率的正常差异

这不是什么

• 不是模型降级：Anthropic 有意进行版本管理并记录变更。日常差异发生在相同模型版本内。
• 不是需要报告的 Bug：此行为是预期的，并记录在大语言模型文献中。它是概率推理固有的。
• 不是永久性的：下一个会话的行为可能会不同。一次"糟糕"的运行并不意味着持久的变化。
• 不是上下文窗口退化：那是会话内由 Token（词元）积累引起的现象。这是新鲜开始时的会话间差异。

2025 年 8-9 月事故（参见上方已解决问题）是例外：Anthropic 确认了导致系统性退化的真实基础设施 Bug。真正的系统性退化很少见，Anthropic 会对其进行调查。正常的会话间差异是另一回事。

缓解策略

限制提示词范围：更具体的提示词减少了输出空间，使差异不那么明显。"编写一个做 X、Y、Z、返回类型 T、处理边缘情况 E 的函数"比"给我写个处理 X 的东西"产生更一致的输出。

重要工作前使用新鲜上下文：在高风险任务前运行 /clear。之前探索性工作积累的会话噪声可能会在同一会话中影响后续输出。

重新表述并重试：如果输出与预期相比感觉不对，用不同的措辞尝试同一请求。第二种表述通常会通过不同的专家路径路由，产生更好的结果。

与已知良好提示词对比：如果你有来自之前会话的产生过优秀输出的提示词，将其作为参考。如果今天版本的该提示词持续产生明显更差的输出，那值得更深入的调查（如果可重现，可能需要在 GitHub 上提交 Issue）。

按任务类型校准预期：确定性任务（正则表达式、简单转换、定义明确的算法）比创造性或需要判断的任务表现出更少的差异。对前者使用 Claude Code 具有高可靠性；对后者，将审查步骤纳入你的工作流。

---

📊 Issue 统计（截至 2026 年 1 月 28 日）

指标	数量	来源
开放 Issue	5,702	GitHub API
标记为"无效"的 Issue	527	GitHub Issues 搜索
已确认的"错误仓库" Issue	17+	2026 年 1 月手动搜索
Token（词元）消耗报告（12 月-1 月）	20+	Issue 搜索
活跃版本	80+	GitHub Releases

---

🔍 如何追踪 Issue

检查当前严重 Issue

# 获赞最多的 Issue（社区优先级）
gh issue list --repo anthropics/claude-code --state open --sort reactions-+1 --limit 20

# 近期严重 Bug
gh search issues --repo anthropics/claude-code "bug" "critical" --sort created --order desc --limit 10

监控特定主题

• Token（词元）消耗：[搜索](https://github.com/anthropics/claude-code/issues?q=is:issue excessive token)
• 错误仓库创建：搜索
• 模型质量：[搜索](https://github.com/anthropics/claude-code/issues?q=is:issue quality degradation)

官方渠道

• GitHub Issues：https://github.com/anthropics/claude-code/issues
• Anthropic 状态：https://status.anthropic.com/
• 工程博客：https://www.anthropic.com/engineering
• Discord：https://discord.gg/anthropic（仅限受邀，请查看官网）

---

📝 为本文档做贡献

本文档仅追踪已验证的高影响 Issue。纳入标准：

• 已验证：GitHub 中存在多份报告或 Anthropic 官方承认
• 高影响：影响安全、隐私、成本或核心功能
• 可操作：提供了变通方法或官方响应

如需建议更新：在 claude-code-ultimate-guide 中提交 Issue，并附上：

• GitHub Issue 链接
• 影响证据（多份报告、官方响应）
• 如有可用，提供建议的变通方法

---

免责声明：本文档由社区维护，与 Anthropic 无关。信息按现状提供。在做出决策之前，请始终通过官方渠道核实当前状态。

---

来源：飞书 · AI Spark 知识库 ｜ 原文（最新版）：https://lcnniolukk80.feishu.cn/wiki/G4vHwFJvDiH3c4kXf8NcpvgHnts ｜ 归档：2026-06-04