Claude Code 源码泄露的具体原因是在构建其 npm 发布包时，错误地包含了用于调试的 Source Map 文件（cli.js.map），导致未经混淆的原始 TypeScript 源代码随包发布，最终通过 npm 的公开分发渠道被任何人下载和解析。这本质上是软件开发生命周期中一个典型的发布配置管理失误。

具体而言，其技术根因可以分解为以下几个层面的失效：

1. 构建与发布流程的配置错误：在准备发布 @anthropic-ai/claude-code 的 v2.1.88 版本时，构建脚本或配置（如 webpack.config.js、rollup.config.js 或 package.json 中的 files 字段）未能正确排除 .map 文件。.map 文件（Source Map）在开发阶段至关重要，它能将经过压缩、混淆或转译（如 TypeScript 转 JavaScript）后的生产代码，映射回原始可读的源代码，方便开发者调试。然而，在生产发布包中包含此文件，相当于将“地图”和“宝藏”一并公开。

2. 缺乏自动化的安全门禁（Security Gate）：一个成熟的 CI/CD（持续集成/持续部署）流水线应在发布前执行静态应用程序安全测试（SAST）和软件组成分析（SCA）。此类工具可以配置规则，用于检测发布产物中是否包含敏感文件（如 .map、.env、私钥文件等）。本次事件表明，Anthropic 的发布流程中可能缺少了针对发布包内容构成的关键安全检查环节，或者相关规则未被触发或执行。

3. 对供应链攻击面的忽视：现代软件高度依赖包管理器（如 npm、PyPI）构成的供应链。此次泄露并非通过攻击 Anthropic 的版本控制系统（如 Git）实现，而是利用了公开的、合法的分发渠道——npm 仓库。攻击者无需渗透内部网络，只需像普通用户一样 npm install @anthropic-ai/claude-code，即可获取包含完整源码的包。这暴露了团队对“发布包即攻击面”这一安全认知的不足。

从软件工程和安全的视角分析，此事件揭示了几个普遍存在的风险点：

为了防止此类事件，开发团队应在工程实践中实施以下加固措施：

// 示例：在 package.json 中明确排除敏感文件
{
  "name": "@anthropic-ai/claude-code",
  "version": "2.1.89",
  "files": [
    "dist/*.js", // 仅包含必要的编译后文件
    "README.md"
  ],
  // 使用 .npmignore 是另一种方式，但 `files` 字段是白名单，更安全
}

// 示例：在 CI/CD 流水线中添加安全检查步骤 (例如使用 `node-sec` 或自定义脚本)
// .github/workflows/release.yml
jobs:
  security-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check for sensitive files in package
        run: |
          # 模拟打包并检查内容
          npm pack --dry-run 2>/dev/null | grep -E '\.(map|env|pem|key)$' && exit 1 || exit 0
        # 如果发现敏感文件，构建失败

此外，从组织流程上，应强制实施 “发布清单（Release Checklist）” 制度，清单中必须包含“验证发布包不包含源码、映射文件及任何凭据”的条目，并由独立于开发团队的人员进行复核。

综上所述，Claude Code 源码泄露的直接导火索是一个低级的技术配置错误，但其根本原因在于软件发布流程中系统性安全控制的缺失。此次事件为所有依赖包管理器分发软件的团队敲响了警钟：必须将发布制品本身视为关键安全边界，并实施从代码提交到最终分发的全链路安全管控。

参考来源

• 51 万行源码泄露，Claude Code 惨遭“开源”！（附源码）