1. 一次 npm 发布事故为什么值得每个 TypeScript 开发者复盘Claude Code 源码泄露这件事表面看是 Anthropic 的公关危机但落到我们日常写 TypeScript、用 Bun 打包、往 npm 推包的工程场景里它其实是一份非常昂贵的“反面教材”。核心检索词先摆出来Claude Code 源码泄露的根因是 npm 发布链路里误留了 Source Map 文件而 Source Map 的sourcesContent字段会完整携带原始 TypeScript 源码。换句话说你辛苦写的 51 万行代码可能就藏在一个 59.8 MB 的cli.js.map里任何人npm pack解压后一行jq就能提取。这件事能做什么参考它适合所有用 TypeScript 构建 CLI 工具、SDK、Node 服务的团队尤其是用 Bun、esbuild、tsup、rollup 这类打包器的项目。你不需要是安全专家只要你会npm publish就有踩同一个坑的可能。我第一次看到sourcesContent能直接还原源码时也愣了一下——原来调试便利和源码裸奔之间只差一个构建配置。这篇复盘不会停留在“Anthropic 又翻车了”的吃瓜层面。我会把 Source Map 的机制、Bun 构建下的可复现排查清单、发布前校验动作以及如何用 TaoToken 统一 Key/API 通道管理多工具接入串成一条能直接跟着做的工程链路。你跟着操作至少能保证自己的下一个 npm 包不会因为一个.map文件把家底交出去。先说清楚泄露的规模感约 1906 个文件、512000 行 TypeScript、44 个功能标志、20 未发布特性。这些数字背后是一个生产级 Agent 平台的完整客户端实现。而泄露入口简单到离谱——npm pack anthropic-ai/claude-code2.1.88解压读cli.js.map。没有漏洞利用没有社会工程就是打包时没排除调试文件。这种“低级但致命”的失误恰恰是最值得写成检查清单的。2. Source Map 与 npm 发布链路从 cli.js.map 到源码裸奔的完整机制2.1 Source Map 到底存了什么Source Map 是前端和 Node 调试的利器。TypeScript 编译成 JavaScript、再经过压缩混淆后.map文件负责把产物“映射”回原始源码让调试器能定位到.ts文件的具体行。一个典型的.map结构长这样{ version: 3, sources: [../src/index.ts, ../src/utils.ts], sourcesContent: [// 完整原始源码..., // 完整原始源码...], mappings: AAAA,SAAS... }关键就在sourcesContent。它不是路径引用而是把每个源文件的完整文本直接内联进.map。所以只要.map进了 npm 包源码就等于公开了。mappings字段只是位置映射sourcesContent才是真正的“源码副本”。2.2 两次泄露的时间线对照2025 年 2 月Claude Code v0.2.8 及之前版本用了开发环境配置打生产包生成的.mjs高达 22MB正常应几百 KB原因是内联了inline-source-map。Anthropic 删除旧包、在 0.2.9 修正。2026 年 3 月版本演进到 2.1.88代码量膨胀近 10 倍同样的错误再次发生npm 包里误留cli.js.map59.8 MB。13 个月内同一个坑摔两次这才是最值得警惕的地方——修复一次不等于流程闭环。2.3 Bun 构建场景下的具体成因Claude Code 基于 Bun 构建。Bun 默认会生成 Source Map而.npmignore里没有加*.map排除规则package.json的files字段也没做白名单约束。还有一个可能相关的 Bun 行为即使生产模式也可能生成 Source Map。这意味着如果你只依赖“生产模式”这个开关而不做发布产物校验.map依然可能混进包里。提取方式简单到不需要任何工具链npm pack anthropic-ai/claude-code2.1.88 tar -xzf anthropic-ai-claude-code-2.1.88.tgz cat package/cli.js.map | jq -r .sources[]jq -r .sources[]列出所有源文件路径配合sourcesContent就能还原全文。这就是为什么说“Source Map 即源码”。2.4 发布链路的五层防护模型把这次事故抽象成可复用的工程模型发布安全应该分五层层级动作工具/配置Layer 1构建配置禁用 Source Mapbunfig.toml/ esbuildsourcemap: falseLayer 2.npmignore或files白名单*.map排除 / 只列必要产物Layer 3CI/CD 自动化检查npm pack后 grep.mapLayer 4发布前人工审核npm pack --dry-runLayer 5发布后自动扫描定期检查已发布包内容任何一层生效都能拦住这次泄露。Anthropic 五层全漏说明流程里没有强制卡点。下面我把每一层都写成可复制的配置。3. 可复制配置Bun TypeScript 项目的发布前校验片段3.1 bunfig.toml 禁用生产 Source Map如果你用 Bun 构建在项目根目录的bunfig.toml里显式关闭[build] sourcemap none注意不同 Bun 版本对sourcemap取值的支持略有差异none表示不生成。改完后务必用bun run build重新构建然后检查dist/目录下是否还有.map文件。这一步是 Layer 1最省事但最容易被“默认配置”绕过。3.2 package.json 的 files 白名单比.npmignore更可靠的是files白名单——只声明要发布的文件其余一律不进包{ name: your-cli, version: 1.0.0, files: [ dist/cli.js, dist/index.js, README.md, LICENSE ] }files是白名单机制优先级高于.npmignore。只要你没把dist/*.map写进去它就不会被发布。这是 Layer 2 的核心动作。我试过在几个小工具里用files白名单比维护.npmignore的排除规则省心得多因为新增产物默认不进包而不是默认进包。3.3 .npmignore 兜底排除如果项目历史原因必须用.npmignore至少加上echo *.map .npmignore echo *.d.ts.map .npmignore echo *.js.map .npmignore但要注意.npmignore是排除逻辑容易漏。比如你新增了dist/esm/目录里面的.map可能不在已有规则覆盖范围内。所以.npmignore只适合做兜底不能当唯一防线。3.4 CI/CD 自动化检查脚本在 CI 里加一段“发布前门禁”发现.map直接失败#!/usr/bin/env bash set -euo pipefail echo 检查打包产物是否包含 .map 文件 if npm pack --dry-run 2/dev/null | grep -q \.map$; then echo FAIL: 打包产物中发现 .map 文件禁止发布 npm pack --dry-run 2/dev/null | grep \.map$ exit 1 fi echo 检查通过无 .map 文件这段脚本可以放在prepublishOnly钩子里{ scripts: { prepublishOnly: bash scripts/check-no-map.sh } }prepublishOnly在npm publish前自动执行失败则中断发布。这是 Layer 3把人工检查变成强制卡点。实测下来这个钩子能拦住 90% 以上的误发布。3.5 多工具接入时的 Key 散落问题发布链路管好了还有一类风险常被忽略本地开发时多个 AI 编码工具各自存 Key。Claude Code、Cline、Codex 各有一套配置Key 散落在不同文件里一旦某个配置文件被误提交或误打包就是另一场泄露。TaoToken 的思路是提供统一 Key/API 通道把多工具接入收敛到一处管理。TaoToken 的 API 地址是https://taotoken.net/api官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。你可以先在控制台创建 Key再让各工具指向同一个 Base URL。这样密钥不再散落在每个工具的私有配置里轮换和吊销也只需在一处操作。4. 验证请求与成功结果确认你的包真的干净4.1 本地验证 npm 包内容构建完成后先做一次 dry-runnpm pack --dry-run输出会列出即将打包的所有文件。你要确认三件事没有.map、没有.ts源文件、没有.env或密钥文件。如果看到cli.js.map或index.d.ts.map立刻回到 Layer 1 和 Layer 2 修配置。4.2 解压真实产物做二次确认dry-run 通过后做一次真实打包并解压检查npm pack tar -tzf your-cli-1.0.0.tgz | grep -E \.(map|ts)$ echo 发现可疑文件 || echo 干净tar -tzf列出压缩包内所有文件grep -E \.(map|ts)$匹配.map和.ts结尾的文件。如果输出“干净”说明产物里没有源码泄露风险。这一步比 dry-run 更接近真实发布结果。4.3 用 TaoToken 验证多工具接入如果你用 TaoToken 统一通道可以这样验证 Key 是否生效。以模型对话为例先到模型对话页面确认通道可用https://taotoken.net/api配合控制台生成的 Key。然后在 Claude Code 或 Cline 里把 Base URL 指向 TaoTokenModel ID 填你实际使用的模型标识。三件套齐全Base URL、Key、Model ID。验证请求是否成功最直接的方式是发一条最小对话请求观察返回是否正常。如果返回 401说明 Key 无效或未带上如果返回模型不存在说明 Model ID 写错。把这两个错误区分开排查效率会高很多。4.4 成功结果长什么样一个干净的发布流程最终应该满足npm pack --dry-run无.mapCI 门禁通过解压产物无.ts/.mapTaoToken 通道下多工具共用同一 Key 且请求正常。这四点都过了你才算把“发布安全”和“密钥管理”两条线都收住了。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth5.1 401 Unauthorized这是最常见的接入错误。原因通常是 Key 没带上、Key 写错、或者 Base URL 指向了错误的端点。排查顺序先确认请求头里有没有Authorization: Bearer key再确认 Base URL 是https://taotoken.net/api而不是别的路径最后到控制台确认 Key 是否被吊销或额度耗尽。401 基本是凭证问题和模型无关。5.2 local proxy failed这个报错通常出现在工具尝试走本地代理但代理未启动或端口不通时。排查确认本地代理进程是否在运行确认端口是否被占用确认工具配置里的代理地址和实际监听地址一致。如果你用的是统一通道方案检查是否误配了本地代理地址而不是 TaoToken 的 API 地址。这个错误和网络环境配置强相关逐项对照即可。5.3 reading choices 报错reading choices这类错误一般出现在解析响应时说明返回结构里没有预期的choices字段。常见原因是请求打到了非兼容端点、返回了错误页 HTML、或者模型名不被识别导致返回了错误对象。排查打印完整响应体看是不是 JSON确认端点路径正确确认 Model ID 在通道支持列表内。不要只看报错行要看原始返回。5.4 OAuth 相关失败如果工具走 OAuth 流程失败通常表现为回调地址不匹配、token 过期、或授权范围不足。排查确认回调 URL 和注册时一致确认系统时间准确时间偏差会导致 token 校验失败重新走一次授权流程。OAuth 问题和 Key 直连是两条路径别混在一起排查。5.5 Claude Code / Cline MCP / Codex auth.json 的三件套无论你用哪个工具接入时都要写全三件套Base URL、Key、Model ID。以 Codex 的auth.json为例配置里要明确这三项缺一项就会报错。Cline 的 MCP 配置同理Base URL 指向 TaoTokenKey 用控制台生成的Model ID 填实际模型。Claude Code 的配置也是这三项。很多人只填了 Key 就以为完事结果 Base URL 还是默认的请求自然打不通。6. 把发布安全和密钥管理收进同一条工程链路回到这次 Claude Code 源码泄露最扎心的不是“又泄露了”而是同一个错误在 13 个月内重复两次。第一次是 inline-source-map第二次是cli.js.map根因都是发布链路缺少强制校验。代码可以重构流程漏洞不补就会一直复现。你现在就可以做三件事第一在bunfig.toml或打包配置里关掉生产 Source Map第二用files白名单约束 npm 包内容第三在prepublishOnly里加一段.map检查脚本。这三步做完你的下一个包就不会因为一个调试文件把源码交出去。密钥管理同理。多工具各自存 Key散落风险高用 TaoToken 统一通道把 Base URL、Key、Model ID 收敛到一处轮换和审计都简单。控制台创建 Key 后接入文档里有各工具的具体配置示例。需要长期跑编码 Agent 的可以看 Coding Plan只是验证模型连通性的用模型对话页面就够。工程基本功这件事平时不显眼出事就是大事。Source Map 是调试利器也是源码放大器npm 发布是日常动作也是泄露出口。把校验做成卡点而不是靠人记得才是这次复盘最该带走的东西。