Claude Code 源码泄露深度解析：假工具投毒、潜伏模式与原生客户端认证

萧萧秦风瘦飞马

716人浏览 · 2026-04-01 09:13:55

萧萧秦风瘦飞马 · 2026-04-01 09:13:55 发布

Claude Code 源码泄露深度解析：假工具投毒、潜伏模式与原生客户端认证

摘要

Anthropic 意外在 npm 包中附带了 .map 文件，导致 Claude Code CLI 完整源码泄露
源码揭示了反蒸馏机制：通过注入假工具定义污染竞争对手的训练数据
潜伏模式（undercover.ts）会让 AI 在开源项目中主动隐藏自身身份，无法被强制关闭
原生客户端认证在 Bun/Zig 层实现 HTTP 请求签名，是 OpenCode 法律纠纷的技术根源
用正则表达式检测用户情绪是一个工程上务实但讽刺的设计选择

背景与问题定义

2025 年，Anthropic 在发布 Claude Code npm 包时意外附带了 .map 文件，其中包含完整可读的 CLI 源码。这是 Anthropic 一周内的第二次意外信息泄露（第一次是模型规范文档泄露）。

这次泄露的时间节点敏感：就在十天前，Anthropic 向第三方工具 OpenCode 发出法律威胁，原因是后者使用 Claude Code 内部 API 以订阅价格访问 Opus 模型，绕过了按 token 计费的正常路径。

源码泄露使外界得以验证：Anthropic 在技术层面究竟做了什么来防止这类"搭便车"行为，以及这些措施的真实效果如何。

核心发现与技术要点

1. 反蒸馏机制：假工具投毒（Anti-Distillation）

是什么

claude.ts（第 301-313 行）中定义了编译时标志 ANTI_DISTILLATION_CC。当该标志启用时，API 请求会附带 anti_distillation: ['fake_tools'] 字段，通知服务端在系统提示中静默注入虚假工具定义。

触发条件需同时满足四项：

编译时标志 ANTI_DISTILLATION_CC 为真
入口点为 cli
使用第一方 API provider
GrowthBook 功能开关 tengu_anti_distill_fake_tool_injection 返回 true

另有第二套机制（betas.ts 第 279-298 行）：服务端对 assistant 的文本进行摘要压缩，并附加密码学签名返回。录制 API 流量的人只能拿到摘要，而非完整推理链。

为什么重要

这是针对"模型蒸馏攻击"的工程防御——竞争对手录制 API 流量来训练自己的模型。假工具会污染训练数据，使蒸馏出的模型学到错误的工具调用模式。

实际绕过难度

不高。几条路径可以规避：

用 MITM 代理在请求到达 API 前剥离 anti_distillation 字段
设置环境变量 CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1
使用第三方 API provider 或 SDK 入口（而非 CLI），条件检查根本不会触发

摘要压缩机制更窄，仅对 USER_TYPE === 'ant' 的内部用户生效，外部用户完全不受影响。

结论：技术防护的实际意义有限，真正的威慑仍在法律层面。

2. 潜伏模式：AI 主动隐藏自身身份（Undercover Mode）

是什么

undercover.ts（约 90 行）实现了一个"潜伏模式"：当 Claude Code 在非 Anthropic 内部仓库中使用时，会指示模型不得提及：

内部代号（如 “Capybara”、“Tengu”）
内部 Slack 频道名
内部仓库名
字符串 “Claude Code” 本身

关键设计：可以通过 CLAUDE_CODE_UNDERCOVER=1 强制开启，但没有强制关闭的方式。源码注释明确写道：

“There is NO force-OFF. This guards against model codename leaks.”

在外部构建版本中，整个函数被编译器死代码消除，变为空操作。

为什么重要

隐藏内部代号是合理的运营安全需求。但"不得提及 Claude Code 本身"意味着：Anthropic 员工用 Claude Code 生成的 commit、PR、代码注释，在开源项目中将没有任何 AI 参与的痕迹。

这触及 AI 透明度的边界问题：这不是"不主动声明"，而是主动规避被识别。

3. 用正则检测用户情绪（Frustration Detection via Regex）

是什么

userPromptKeywords.ts 中包含一个正则表达式，用于检测用户挫败情绪：

/\b(wtf|wth|ffs|omfg|shit(ty|tiest)?|dumbass|horrible|awful|
piss(ed|ing)? off|piece of (shit|crap|junk)|what the (fuck|hell)|
fucking? (broken|useless|terrible|awful|horrible)|fuck you|
screw (this|you)|so frustrating|this sucks|damn it)\b/

为什么重要

一家 LLM 公司用正则做情感分析，乍看讽刺，但工程逻辑清晰：

正则匹配延迟 < 1ms，LLM 推理调用需要数百毫秒
无需额外 API 成本
覆盖的词汇集合有限且可枚举，正则完全够用

这是"用合适工具解决合适问题"的典型案例，而非技术退步。触发后的具体行为（信息不足，源码未完整披露后续逻辑）。

4. 原生客户端认证：Bun/Zig 层的 HTTP 签名

是什么

system.ts（第 59-95 行）揭示了一套客户端认证机制：

API 请求头中预置占位符 cch=00000（五个零）
请求离开进程前，Bun 的原生 HTTP 栈（用 Zig 编写）将五个零原地替换为计算出的哈希值
服务端验证该哈希，确认请求来自真实的 Claude Code 二进制，而非仿冒客户端

占位符与哈希值等长，替换时不改变 Content-Length 头，无需重新分配缓冲区。整个计算发生在 JavaScript 运行时之下，JS 层的任何代码（包括用户脚本）都无法感知或篡改。

为什么重要

这是 OpenCode 法律纠纷的技术根源。Anthropic 不只是用条款禁止第三方工具，而是在传输层做了密码学绑定。OpenCode 社区在收到法律通知后不得不转向 session 拼接等变通方案，正是因为这套机制使直接 API 复用变得困难。

局限性：整个机制受编译时标志 NATIVE_CLIENT_ATTESTATION 控制（素材在此处截断，信息不足，无法确认完整绕过难度）。

工程视角解读

对产品与安全策略的影响

反蒸馏机制的技术强度不足以对抗有能力的攻击者，其价值更多在于提高"随手蒸馏"的门槛，而非阻止专业竞争对手
原生客户端认证将 API 访问控制下沉到二进制层，是比 token 校验更强的绑定方式，但同时也意味着任何第三方集成都面临更高的合规成本
潜伏模式在 AI 透明度日益受到监管关注的背景下，存在一定的合规风险

可执行的改进方向

反蒸馏机制应结合服务端行为分析：纯客户端标志容易被绕过，结合请求频率、工具调用模式的异常检测会更有效
潜伏模式应提供审计接口：允许仓库维护者查询某次贡献是否由 AI 辅助生成，而非完全屏蔽信息
情绪检测正则应配合遥测数据持续更新：当前词表是静态的，用户表达挫败情绪的方式会随时间演变
客户端认证密钥轮换机制（信息不足，建议关注）：若哈希算法或密钥被逆向，需要有快速失效和更新的能力

风险与边界

已确认事实

.map 文件确实被意外打包进 npm 发布版本
四项技术机制（反蒸馏、潜伏模式、情绪正则、客户端认证）均有源码佐证
反蒸馏机制存在多条已知绕过路径
潜伏模式在代码层面无法被强制关闭

信息不足项

NATIVE_CLIENT_ATTESTATION 标志的完整绕过难度（素材截断）
情绪检测触发后的具体下游行为
假工具注入的具体内容和数量
服务端哈希验证失败时的降级策略

可能误用场景

开发者可能基于此源码构建绕过认证的第三方客户端，需注意相关法律风险
潜伏模式的存在可能被用于论证"AI 生成内容无需标注"，这是对该机制的误读——它是运营安全设计，不应被解读为行业规范

实践清单（Checklist）

如果你在构建基于 Claude API 的工具：检查是否依赖了 Claude Code 的内部 API 端点，这类依赖在法律和技术层面均存在风险
如果你关注 AI 透明度合规：在团队 AI 使用规范中明确要求标注 AI 辅助贡献，不能依赖工具本身的自我声明
如果你在做 LLM 应用的情感/意图检测：评估正则 + LLM 的分层方案——高频简单信号用正则，复杂语义用模型，兼顾成本与准确率
如果你在维护开源项目：了解贡献者可能使用的 AI 工具是否有类似潜伏模式，考虑在 CONTRIBUTING.md 中要求明确声明
如果你在做安全研究：关注 NATIVE_CLIENT_ATTESTATION 机制的完整实现，这类"传输层 DRM"在其他 AI 产品中可能有类似实现

参考

原始标题：The Claude Code Source Leak: fake tools, frustration regexes, undercover mode
HN 讨论：https://news.ycombinator.com/item?id=47586778
首发发现者：Chaofan Shou