宝玉：Claude Code 源码泄露不是因为 Bun，是开发者失误

核心要点

2026年4月1日，知名开发者宝玉（@dotey）发布澄清声明，明确指出此前 Claude Code 源码泄露事件的根本原因并非 Bun（JavaScript 运行时）本身存在安全漏洞，而是开发者在构建配置环节出现的失误——在打包 npm 包时错误地将 Source Map 文件一并包含在内，导致用户安装后可通过 Source Map 轻易还原出完整的源代码。Anthropic 随后修复了该配置问题并重新发布了包。

原文 + 中文翻译

原文："关于 Claude Code 源码泄露，澄清一下——不是 Bun 的 bug，是开发者在构建配置上犯了错，把 Source Map 打进了 npm 包里。"

翻译："Regarding the Claude Code source code leak, let me clarify—it wasn't a bug in Bun, but rather a developer mistake in the build configuration that included Source Maps in the npm package."

原文（补充背景）："Source Map 本意是帮助调试，生产环境不应该包含它。这次泄露暴露的是构建流程的疏漏，不是运行时的问题。"

翻译："Source Maps are meant for debugging and should never be included in production. This leak exposed a gap in the build pipeline, not a runtime issue."

深度解读

技术层面的真实原因：构建配置失当，而非运行时漏洞

此次 Claude Code 源码泄露事件的核心技术链条并不复杂。Source Map 是一种源代码映射文件，能够将压缩/混淆后的生产代码反向映射回原始源代码，主要用途是在开发阶段帮助开发者调试未压缩的代码。正因其功能特性，一旦 Source Map 被打包进发布给终端用户的 npm 包中，就等于直接将源代码交付给了任何安装该包的开发者——这正是此次事故的本质。

宝玉的澄清指向了一个关键区分：许多人最初怀疑是 Bun 这个相对较新的 JavaScript 运行时在处理打包产物时存在某种行为异常或安全缺陷，但实际情况是问题出在 Claude Code 项目的构建脚本或打包配置上。在典型的 Node.js/Bun 项目中，构建工具（如 esbuild、rollup、webpack 等）通常提供配置选项来控制是否生成 Source Map、以及是否将 .map 文件排除在最终发布包之外。如果开发者在项目根目录的 .npmignore / .gitignore 或构建脚本中没有明确排除 Source Map，或者构建配置中错误地将 sourcemap 选项设为 true 并将输出一并发布，就会导致此次泄露。

行业影响：重新审视开发工具链的信任边界

这起事件对 JavaScript/TypeScript 生态有超出个案本身的警示意义。Claude Code 作为 Anthropic 官方推出的 AI 编程辅助 CLI 工具，其代码库包含的可能不仅是业务逻辑，还涉及与 Claude API 的通信方式、Prompt 设计、安全机制等敏感信息。当源码可被轻易还原，意味着竞争对手或安全研究者能够深入了解其实现细节——无论是为了逆向学习还是寻找潜在漏洞。

更深一层看，此事件也暴露了开发者在使用新兴工具（如 Bun）时可能存在的理解偏差。Bun 在 2024-2025 年迅速普及，部分开发者倾向于认为其行为与 Node.js 完全一致，因而在迁移项目或使用其打包功能时可能忽略某些配置差异。但宝玉的澄清表明，此次问题与 Bun 本身的行为无关——无论是用 Bun 还是 Node.js 执行构建，只要构建配置正确，都不会泄露 Source Map。

安全实践反思：从"能跑就行"到"发布即安全"

这一事件再次将"npm 包供应链安全"这一议题推至聚光灯下。近年来，npm 生态中因依赖混淆、恶意包名、构建脚本植入恶意代码等导致的安全事故频发，行业已逐渐形成对第三方包引入的审慎态度。但此次 Claude Code 泄露提供了一个新的视角：即使发包方本身并无恶意意图，配置失误也可能造成等同于源代码泄露的严重后果。

对于企业级开发团队而言，这一事件的教训在于：CI/CD 流水线在发布 npm 包前，应强制执行 Source Map 检测——确认生产包中不包含 .map 文件或 .map 引用；同时，依赖开源工具链的项目在切换运行时（如从 Node.js 迁移到 Bun）或构建工具时，务必重新审计打包配置，而不能假设"历史配置在新环境下天然有效"。

值得关注

• Anthropic 官方修复确认：需确认 Claude Code 官方是否已发布修复版本（预期版本号应有更新），以及新版本是否已从 npm registry 重新上架。可关注 npm view @anthropic-ai/claude-code 的版本历史和 dist-tags 变化。
• 泄露源码的传播范围：Github、GitLab 等平台是否出现 Claude Code 源码仓库的 fork 或镜像，需检索确认。虽然 npm 包已修复，但已安装旧版本的开发者终端仍持有泄露的 Source Map 文件。
• Bun 官方态度：Bun 团队是否就此事件发表声明，强调其运行时本身不涉及此次泄露，以消除开发者社区对其安全性的疑虑（尽管此次与 Bun 无关，但舆论往往会将两者关联）。
• npm 安全机制讨论：npm Inc. 或 pnpm / yarn 社区是否会借此推动"Source Map 不得进入生产包"的最佳实践标准化——例如在 package.json 中增加 "publishConfig" 字段约束，或在 registry 层面增加自动化检测。
• Claude Code 商业竞品影响：GitHub Copilot、Cursor 等同类工具的团队是否会借此事件审查自身构建流程，以及 Claude Code 泄露的源码是否会为竞品提供有价值的参考（如 API 调用策略、Agent 架构设计）。

信源行：
• 原文链接：@dotey (宝玉) 澄清推文
• 背景报道：Hacker News 讨论帖：Claude Code Source Map 泄露事件、The Verge - Anthropic Claude Code 相关报道（相关事件跟进中）