Claude Code源码泄漏：npm里藏了什么

2026年3月31日，研究员 Chaofan Shou 在 X 上发帖称，他在 npm 注册表里翻到了 Claude Code 的完整源代码。不是片段，不是符号表，而是随包发布的 sourcemap 里直接带出的源码。

这件事之所以让人侧目，不只是因为“泄漏”两个字够扎眼，而是因为被翻出来的是 Anthropic 自家的 AI 编程 CLI。对一个主打开发者工作流的产品来说，源码和实现细节本来就最值钱，结果它们却以一种很低级的方式出现在公开包里。

如果你平时也用过 npm 包的 sourcemap，大概知道这类文件本来是给调试用的。问题在于，很多团队只把它当“前端调试工具”，却忘了它也可能把压缩后的代码、注释、目录结构，甚至一整套实现逻辑原样吐出来。

这次到底泄了什么

按 Chaofan Shou 的说法，泄露内容来自 Claude Code 发布到 npm 的包内 sourcemap。也就是说，外部用户不需要特殊权限，也不需要入侵，只要下载公开包，就可能把原本不该公开的源码还原出来。

这类问题的危险点在于，它不是单纯的“代码看光了”。一旦源码可读，攻击面会变得更清晰：命令处理逻辑、鉴权方式、远程请求路径、错误处理分支、隐藏功能开关，都会更容易被逆向。

对于 AI 编程工具，这种暴露尤其敏感。因为它们往往不只是一个本地命令行程序，还会和模型接口、权限系统、缓存、遥测上报、文件系统交互，任何一层写得随意，都可能被放大成实际风险。

• 公开时间：2026-03-31
• 曝光者：Chaofan Shou
• 泄露位置：npm 注册表中的包文件
• 泄露载体：sourcemap 文件
• 涉及产品：Anthropic 的 Claude Code

为什么 sourcemap 会把事情搞大

Sourcemap 的初衷很朴素：帮助开发者把压缩后的代码映射回原始源码，方便排查问题。可一旦发布流程没管住，sourcemap 就会从调试辅助变成“源码出口”。

这次事件之所以被讨论得很热，是因为 Claude Code 本身是面向开发者的工具，用户群对技术细节很敏感。大家会自然联想到：如果一个做 AI 编程工具的公司，连发布包里的 sourcemap 都没检查好，那它对供应链安全的管理到底有多细。

更现实的一点是，npm 生态里很多包都会被自动拉取、缓存、镜像和二次分发。一次上传失误，可能在多个缓存节点里停留很久。你删掉上游文件，不等于所有副本都立刻消失。

“Security is a process, not a product.” — Bruce Schneier

这句 Bruce Schneier 的老话放在这里非常合适。源码泄漏往往不是单点事故，而是流程、审查、发布、回滚、缓存管理一起出问题的结果。

和其他软件泄漏事件比，差别在哪

很多软件泄漏事件都发生在内部仓库、误配存储桶，或者测试环境里。Claude Code 这次更尴尬的地方在于，它出现在公开的包分发渠道里，任何人都能直接拿到。

从影响面看，这类公开分发错误通常比内部泄漏更难收拾。内部泄漏还可以追溯访问日志，公开包则意味着已经进入了全球镜像系统，传播速度快，回收速度慢。

如果拿几个常见场景做对比，会更直观：

• npm 公开包泄漏：任何人都能下载，传播最快，修补最难
• GitHub 私有仓库误公开：通常能尽快撤回，但可能已被抓取
• 内部日志或对象存储泄漏：影响面可能更小，但取证和清理更复杂
• CI/CD 制品泄漏：经常和自动发布绑定，错误会被重复放大

从开发者视角看，真正该警惕的不是“源码被看见”本身，而是“为什么它会被看见”。如果一个包里连 sourcemap 都能带出核心逻辑，说明发布门禁、产物审查和签发流程至少有一环没拦住。

这也是为什么这类事件常常比表面看起来更麻烦。它逼着团队回答一个很具体的问题：到底哪些文件应该进入公开制品，哪些文件必须在发布前被清理掉？

这对 Anthropic 和开发者意味着什么

对 Anthropic 来说，最直接的伤害不是“被嘲笑”，而是信任成本上升。一个卖 AI 编程工具的公司，最怕的就是开发者怀疑它对工程细节的把控能力。

对用户来说，这件事也不只是围观八卦。你今天用的是 Claude Code，明天用的可能是别家的 CLI、插件、代理层或者本地编排工具。只要它们依赖公开包分发，就都可能踩到类似的坑。

从更实际的角度看，这件事给团队的启发很明确：发布前要检查 sourcemap、删除未必要的源码映射、审查包内容、把敏感逻辑从可公开制品里剥离出去。听起来像老生常谈，但真正出事时，往往就是这些老生常谈没做全。

• 检查 npm 包内容，确认没有多余的源文件和映射文件
• 关闭或限制 production 环境下的 sourcemap 发布
• 把发布制品和源码仓库分开审计
• 对 CLI 工具的鉴权、遥测和远程调用路径做额外复核

如果你在团队里负责前端、Rust、Node.js 或发布流水线，这次事件值得顺手做一次自查。尤其是那些会自动生成 map 文件、bundle 文件和 debug artifact 的项目，最容易在最后一步把不该公开的东西顺手打包出去。

想看类似的 AI 工具发布与安全问题，我们之前也写过一篇关于 AI 工具发布前的安全检查清单，里面列了不少实际可执行的检查项。

最后看什么：修补速度，而不是公关话术

这类事故最能看出一家公司的工程成熟度。真正重要的不是发一条“我们正在调查”的声明，而是能不能快速确认影响范围、撤下有问题的包、轮换可能暴露的密钥，并把发布链路补上缺口。

我更想看到的是一个明确动作：Anthropic 是否会公开说明这次泄漏涉及哪些版本、哪些文件、哪些构建步骤，以及他们准备怎么改 npm 发布流程。只要这些信息够具体，开发者就能判断这到底是一次偶发失误，还是流程本身就有系统性问题。

我的判断是，这次事件不会让 Claude Code 失去用户，但会让更多团队开始盯紧自己的包发布链路。接下来值得观察的，不是舆论热度能持续多久，而是各家 AI 工具会不会开始默认把 sourcemap、调试产物和公开制品分开处理。谁先补上这个洞，谁就少一次把自己放到聚光灯下的机会。