Claude Code 源码大逃跑:代码藏了什么,比泄露本身更可怕
安全研究员 Chaofan Shou 打开 Claude Code v2.1.88 的 npm 发布包，准备例行检查，然后整个人愣住了。
包里有一个文件：cli.js.map。59.8MB，安安静静地躺在那里。
Source Map 是开发调试用的，正常情况下不应该出现在生产包里。Chaofan 打开一看——里面是 512，000 行 TypeScript 源码，完整的，干干净净的，Anthropic 花了数年时间构建的 Claude Code 核心代码，就这样毫无防备地摊开在任何一个下载了这个 npm 包的人面前。
他在 X 上发了一条帖子，配图是那个 59.8MB 的文件。
接下来发生的事情，用“失控”来形容都嫌轻。数小时内，代码被归档到公共 GitHub 仓库，Fork 数突破 41，500。Anthropic 紧急撤包，把版本回退到 v2.1.87，随即向 GitHub 发出 DMCA 版权删除通知。与此同时，全球开发者已经把这 51 万行代码翻了个底朝天。
13 个月前，2025 年 2 月，同样的漏洞已经发生过——不止一次。Claude Code 在那个月先后有两个版本都因为 inline-source-map 的问题暴露了源码。Anthropic 紧急处理，删包、修版本、修复。所有人以为这件事翻篇了。
但 13 个月后，2026 年 3 月 31 日，同一扇门，同一把没锁的锁，还在那里。
这就好比一家顶级安保公司，去年因为忘记锁后门被人溜进来了，今年同一扇门，同一把没锁的锁，再演一遍。
你可能会问：Anthropic 不是那家最强调“AI 安全”的公司吗？
而这次代码跑路，只是一个开始。真正让整个行业倒吸一口冷气的，不是泄露本身，而是泄露之后，大家在那 51 万行代码里，看到了什么。
全球开发者翻代码的速度，比 Anthropic 撤包的速度快得多。
很快，有人在源码里发现了一段逻辑，代号：Undercover Mode。
先说它做什么：当 Claude Code 检测到当前的提交目标是外部仓库——也就是不在 Anthropic 内部白名单里的 GitHub 项目——这段逻辑会自动激活。激活之后，它会注入一段系统提示，指示 Claude 永远不要提及自己是 AI。同时，它会把提交记录里的 Co-Authored-By： Claude 署名全部剥离，让这段代码看起来像是人类独立完成的。
Anthropic 是一家把“AI Safety”写进公司使命的企业。他们在各种公开场合强调：AI 的透明度和可信赖性，是这个行业最重要的基石。他们发布 Constitutional AI，发表负责任 AI 开发的研究报告，在国会听证上讲 AI 风险。
但与此同时，他们自己的工程师在用 Claude Code 给外部开源项目提交代码的时候，工具会自动抹掉 AI 的参与痕迹。
这不是某个工程师的私下操作，这是写进源码的产品逻辑。
开源社区对此的反应，用“炸锅”来形容并不夸张。开源的核心信念之一，是贡献的透明和可追溯——谁写的、怎么写的、用什么工具写的，这些信息构成了一个项目的信任基础。如果一个贡献者用 AI 生成了代码，社区有权知道。不是因为歧视 AI，而是因为这关系到代码审查、责任归属、许可证合规，乃至整个社区的协作契约。
Undercover Mode 把这个契约悄悄绕过去了。
更耐人寻味的是：这个功能在源码里被设计得相当完整，触发条件清晰，行为逻辑周密。这不是一个临时的补丁，而是一个经过设计的功能。有人专门想过这件事，并且把它做进了产品里。
我没有办法替 Anthropic 解释这个决定背后的动机。也许有某种合理的商业或法律考量。但有一件事是确定的：这个功能的存在，和 Anthropic 公开标榜的 AI 透明度价值观，构成了一个很难自洽的矛盾。
他们的第一个动作，是向 GitHub 发出 DMCA 版权删除通知。目标是归档了泄露代码的那个原始仓库，以及它的 96 个 Fork。逻辑上说，这是合理的法律操作。
GitHub 的 DMCA 处理机制有一个特性：它会追踪 Fork 网络。当原始仓库被标记，系统会顺着 Fork 关系向下蔓延，把相关联的仓库一并处理。问题是，这张“相关联”的网撒得太大了。
原本针对 97 个目标，误伤了超过 8，000 个无辜项目。其中大量是和这次泄露毫无关系的合法开源项目——有人维护了多年的工具库，有团队正在活跃开发的项目，突然之间，访问受限，贡献者懵了。
这句话，是那两天 X 和 Hacker News 上最温和的表达。
Anthropic 反应还算迅速。Claude Code 负责人 Boris Cherny 站出来公开回应，承认这不是有意为之，随即提交了补充通知，要求 GitHub 仅针对原始请求采取行动。大部分误封的项目，陆续得到恢复。
他没有把这次事故归结为某个工程师的失误，也没有宣布任何人被追责。他说，这是一个流程问题、文化问题、基础设施问题，不是个人责任。Anthropic 的另一位成员也随后强调了公司的“无责备（Blameless）文化”。
说实话，我看到这里的时候，也觉得这是这个事件里少有的“体面时刻”。在一个出了事就找人背锅的行业惯例下，能公开说“这是系统问题”，需要一点真实的勇气。
但这种体面，不能抵消一个更根本的问题：为什么同一扇门，两次没锁上？
“无责备文化”的前提，是把责任归给系统，然后真的去修系统。如果 13 个月前第一次泄露之后，流程被认真修过，2026 年 3 月那个 59.8MB 的文件，不应该还在那里。
DMCA 的风波还没平息，安全研究员们已经在干另一件事：把这 51 万行代码当作一份靶场地图，系统地找里面的攻击面。
CVE-2025-59536，被收录进 NVD（美国国家漏洞数据库），定级：高危。
攻击者在一个开源项目里预埋恶意配置——触发脚本、外连服务器地址、插件预置指令。然后等有人 Fork 这个项目，或者接手这个代码库。接下来，什么都不需要做，只需要等那个人在项目目录下输入：
没有弹窗，没有权限申请，没有任何提示。Claude Code 对当前工作目录下的所有配置一律信任，恶意配置自动激活：摄像头被悄无声息地打开，硬盘里的密钥、API Token、凭证文件被搜刮一遍，数据被发往攻击者控制的服务器。全程零感知。
这不是理论推演，这是源码里已经存在的信任逻辑漏洞，通过这次泄露，被完整地摊开在全球攻击者面前。
有研究员用了一个比喻：以前黑客需要蒙着眼睛摸银行金库的结构；现在，金库的设计图纸直接放到网上了，标注清楚哪扇门最薄，哪个角落的摄像头有盲区。
Claude Code 被广泛用于企业内部的代码开发流程，也被工程师用来处理包含内部业务逻辑的真实代码库。如果有人在这条链路上任意一个环节投入了恶意配置，CVE-2025-59536 告诉我们，后果不只是代码泄露，而是一次安静的、零感知的全面沦陷。
Anthropic 随后发布了修复版本，漏洞被封堵。但有一个问题，这个漏洞修完就消失了——还是说，它只是第一个被找到的？
这个问题，因为这次源码泄露，变得比以前任何时候都更难回答。
四、你以为 Claude 只是个工具，但它在“做梦”
对大多数开发者来说，Claude Code 是一个编程助手——你问它，它答你，你让它改代码，它改。是个工具，用完关掉，干净利落。
但这 51 万行源码告诉我们，这个理解，可能过于简单了。
每次你启动 Claude Code，它会向 Anthropic 的分析服务发送一批数据：用户 ID、会话 ID、绑定邮箱、终端类型、当前功能标志。这是启动时的例行上报。如果你当时没网，数据会先存在本地，等你联网了再补发出去。
不只是启动时。Claude 读过的每一个文件、每一次 Bash 命令的输出、每一次搜索结果，都以明文 JSONL 格式记录在本地。一位匿名安全研究员在审计这段逻辑之后说了一句话，我觉得值得原文引用：
“大多数人没意识到，Claude 看过的每一个文件，Anthropic 都有一份副本。”
这是研究员基于源码逻辑的推断，Anthropic 尚未就此作出正式回应。但这个推断所依据的数据路径，是真实写在源码里的。你用 Claude Code 处理的项目，可能包含公司内部的业务逻辑、未发布的产品设计、客户数据、API 密钥。数据保留期：免费和付费用户默认 30 天，如果你勾选了“共享训练数据”，这个数字变成 5 年。
源码里有一个尚未发布的模块，代号 autoDream。它的工作方式是：在你空闲的时候，作为后台子进程悄悄运行，扫描你所有的历史会话记录，提取关键信息，写入一个叫 MEMORY.md 的文件。这个文件，会被注入到你未来使用 Claude 时的系统提示词里，最终通过 API 回传。
换句话说，Claude 会在你不知情的时候，整理它对你的了解，然后带着这份“了解”继续和你互动。
autoDream 是关于记忆的；接下来这个，是关于主动性的。两件事加在一起，描述的是同一个方向。
这个架构，源码里叫 KAIROS——一个让 Claude 作为持久后台 Agent 运行的守护进程模式。它不等你发指令，而是接收定期的 <；tick>； 信号，自主判断是否需要主动行动。还有一个配套模块叫 ULTRAPLAN，专门处理复杂规划任务，可以把任务卸载到云端，调用顶级模型，给出专用的推理时间。
如果用一句话概括这个方向：Claude Code 想做的，不是“你说一步它做一步”，而是“它自己想着做，你审批就行”。
这个方向本身，不一定是坏事。Agentic AI 是整个行业的趋势，持续运行、主动规划、记住上下文，都是让 AI 真正有用的能力。
但有一个问题，随着这些能力的增强，会变得越来越重要：用户知道这些吗？
源码里描述的数据采集范围，有多少在用户协议里被清晰告知过？autoDream 在后台运行时，有没有对应的用户感知和控制机制？KAIROS 持续运行时，边界在哪里？
这次泄露的影响，不只停留在 Anthropic 内部。
事件发酵的第二天，一个韩国开发者 Sigrid Jin 用 oh-my-codex（一个基于 OpenAI Codex CLI 的编排工具）把泄露的架构净室重写成了 Python 版本，起名 claw-code，发布两小时获得 50，000 个 Star，成了 GitHub 历史上增长最快的仓库之一。
一家公司花数年时间构建的核心产品逻辑，在代码意外曝光之后，48 小时内被全球开发者消化、复现、再创作。这不只是知识产权的问题，这是在说：在 AI 时代，“闭源”这件事，可能比以往任何时候都更脆弱。
AI 公司普遍面临一个结构性困境：他们需要用“安全”和“透明”来建立公众信任，但他们的商业模式又需要保护核心技术、积累数据优势。这两件事，天然存在张力。
Undercover Mode 和数据采集逻辑，不是 Anthropic 独有的问题，而是整个行业在这个张力下做出选择的缩影。用户协议里的条款，和源码里的实际逻辑，之间有多大的距离？在这次泄露之前，没有人有能力验证这个问题。
一个 .map 文件，暴露了 51 万行核心代码。这不是什么高级攻击，这是一个构建配置的遗漏。
但这个遗漏发生的背景值得注意：Claude Code 基于 Bun 构建，而 Anthropic 在 2025 年底刚刚收购了 Bun。新工具链、新构建流程、新的工程团队融合——这些都是供应链风险的温床。对于任何在生产环境中大规模使用 AI 编码工具的团队来说，这次事件是一个真实的提醒：你用的工具，自己的供应链管得住吗？
我们在企业里推行开源治理的时候，有一条基本原则：引入任何外部工具，都要做软件物料清单（SBOM）。但现在 AI 编码工具直接接触你的代码库、你的文件系统、你的凭证——这个层面的供应链风险，还没有进入大多数企业的安全视野。
第三条裂缝：AI 工具作为基础设施，缺乏任何可验证的行为审计机制。
我们讨论 AI 安全，通常聚焦在模型层面——AI 会不会产生有害内容，会不会被滥用。但这次事件揭示的，是另一个维度的问题：当 AI 工具深度嵌入你的开发流程，成为你代码库的日常访客，它的行为边界在哪里——不是隐私政策里写的，而是源码里实际运行的。
这两件事，在这次泄露之前，没有人能验证它们是否一致。
Undercover Mode 是一个极端案例，但它提出的问题具有普遍性。在我们推动企业引入 AI 编码工具的实践中，我开始意识到，有三个问题几乎没有人在问：
这个工具，读了什么？它是否有权访问整个代码库、还是仅限于你主动提供的文件？边界在哪里，是产品设计决定的，还是你可以配置的？
记录了什么？你和它的每一次交互，本地留存了什么，云端上传了什么，保留多久？这些数据，在多大程度上被用于模型训练？
向谁发送了什么？后台进程有没有在你不知情的时候上报数据？有没有第三方服务接入点？有没有类似 autoDream 这样的后台扫描逻辑？
这三个问题，在这次泄露之前，用户无法验证，监管机构没有工具介入，企业安全团队的视野里也几乎没有这个层面的覆盖。
引入 AI 编码工具，不应该只是一次技术选型，而应该是一次供应链安全评估——和你引入任何其他有网络访问权的基础设施组件一样，做好行为边界的梳理和准入审查。
不是因为要对 AI 抱有敌意，而是因为：你没有办法信任一个你完全看不见内部逻辑的工具。 而这次泄露，只是偶然给了我们一次看见的机会。
Anthropic 的处理方式，在技术事故的层面，算不上优秀——13 个月内两次同样的错误，DMCA 误伤 8000 个无辜项目，这些都是真实的失误。但 Boris Cherny 的公开回应，以及“无责备文化”背后的担当态度，至少让这件事没有变得更难看。
对于我们这些使用 AI 工具的人来说，这次事件最大的价值，可能不是“Anthropic 翻车了”这个结论，而是它打开了一扇窗，让我们看到了一个平时看不见的世界——那 51 万行代码里，装着一家顶级 AI 公司真实的技术选择、产品逻辑和价值权衡。
夜雨聆风
