Claude Code 源码泄漏分析：从 npm source map 漏洞看 51 万行 TypeScript 工程与供应链安全

2026年3月31日，Claude Code的完整源码赫然出现在了GitHub上。

这次泄露的规模远超常规，总计约1900个文件、51万行 TypeScript 代码。其工具系统、权限模型、多智能体协调机制、IDE桥接模块，乃至对MCP协议的支持，全都暴露无遗。事件的起因，是Claude Code通过 npm 分发的发布包中包含了 .map source map文件，而这些文件直接指向了Anthropic公司R2存储桶上未做任何访问控制的原始TypeScript源码。最早公开指出这个问题的是Twitter用户 @Fried_rice。

项目卡片

• 项目：jarmuine/claude-code（源码镜像）
• 状态：2，022 Star / 5,721 Fork / 源码快照于2026-03-31暴露
• 一句话判断：这是一起典型的供应链安全事故的产物，但其泄露的代码本身，却是研究agentic CLI架构不可多得的一手材料。

泄漏是如何发生的

整个泄漏路径其实相当清晰：

1. Claude Code通过npm渠道分发，其发布的包中包含了用于调试的 .map source map文件。
2. 这些source map文件中引用的路径，直接指向托管在Anthropic自有R2存储桶上的、未经过混淆的TypeScript源文件。
3. 由于该R2存储桶的访问控制配置存在疏漏，导致这些源文件可以被公开访问和下载。

两个环节必须同时出问题才会导致这种严重后果：发布流程保留了敏感的source map文件，而云存储服务又没有限制公开访问。只要其中任何一个环节被堵住，源码都不会如此彻底地暴露。

镜像仓库的维护者jarmuine是一名大学生，这个仓库fork自更早的泄露镜像。其README中明确声明，这只是一个用于教育性和防御性安全研究的存档，原始代码的所有权归Anthropic所有。

当你把代码clone下来，第一反应可能会是：这51万行TypeScript代码，竟然全都堆在同一个 src/ 目录里。其中最大的一个文件 bridgeMain.ts 有2400多行。整个项目没有采用monorepo进行拆分，也没有依赖Rust编写的原生插件——这看上去是一个相当“传统”的大型TypeScript项目结构。

源码揭示了什么：整体架构

虽然结构传统，但这51万行代码被组织在一个清晰的分层架构中：

运行时选择了Bun而非Node.js。这个选择在代码中得到了充分的回报——项目大量使用了 bun:bundle 的 feature() 函数来做编译期的死代码消除，同时还依赖Bun原生的沙箱和WebView能力来支撑特定功能。入口文件 main.tsx 在模块加载阶段，就并行启动了MDM设置读取、Keychain预取、GrowthBook初始化等操作，将冷启动时间压缩到了最低。

终端UI基于React + Ink构建，将React的声明式开发模式搬到了命令行终端里。UI层包含了大约140个组件，覆盖了权限弹窗、diff内容查看、MCP连接状态显示、任务列表展示等各种场景。CLI的参数解析则使用了常见的Commander.js。

工具系统：AI Agent能力的基石

Claude Code之所以能展现出强大的“智能体”（agentic）行为，其核心在于它精心设计的工具系统。源码中完整实现了 37个工具，每个工具都是一个独立的模块，明确定义了输入参数的模式（使用Zod v4）、所需的权限模型以及最终的执行逻辑。

这些关键工具可以按功能分为以下几类：

• 文件操作类：FileRead、FileWrite、FileEdit、Glob、Grep、NotebookEdit。其中 Grep 底层调用的是ripgrep，Glob 用于文件模式匹配。特别值得注意的是 FileEdit，它采用的是直接的字符串替换逻辑，而非生成和应用diff补丁，这是一个有意识的设计选择。

• 执行类：Bash（执行shell命令）、PowerShell、REPL。Bash 工具的权限检查机制尤为复杂——它内部嵌入了一个基于tree-sitter的bash AST解析器，能够将一条原始命令拆解为结构化的参数数组，然后再去匹配预设的权限规则。解析器采用了 fail-closed安全策略：任何无法被识别的AST节点类型，都会导致整个命令被标记为“过于复杂”，从而转入正常的用户手动审批流程。

• 智能体类：Agent（用于派生子智能体）、TeamCreate/TeamDelete（团队级别的并行任务管理）、SendMessage（智能体间通信）、ScheduleCron（定时触发任务）。这套系统支持多层级的智能体协调。在coordinator模式下，一个主智能体可以管理多个worker，每个worker又可以拥有自己独立的工具集和权限范围。

• 环境交互类：MCPTool（用于Model Context Protocol）、LSPTool（语言服务）、WebFetch、WebSearch、EnterWorktree/ExitWorktree（用于git工作区隔离）。

其中 ToolSearchTool 工具的设计思路特别值得关注——它实现的是 延迟工具发现 机制。与其在每次对话时都把37个工具的全部schema都塞进大模型的上下文窗口里，不如在用户或智能体真正需要某个工具时，再按名称搜索并动态加载它。这是一个非常直接且有效的节省token开销的设计。

权限系统：三层递进的智能防线

权限系统可能是Claude Code代码中最复杂、也最精巧的部分。每一次工具调用，都需要经过 PermissionContext 的层层检查，该系统支持多种权限模式，如default、plan、bypassPermissions、auto等。

第一层防线：基于hook的自动审批。用户可以在 settings.json 配置文件中自定义shell hook，在工具调用前后自动执行脚本，从而实现类似“允许所有以 npm 开头的命令”这样的自动化安全规则。

第二层防线：bash命令的AI分类器。Bash 工具内部集成了一个异步的分类器，能自动判断一条命令是否安全。这个设计的关键在于，分类器的审批流程和用户交互确认流程是并行运行的——哪个先返回结果就采用哪个。读到这段代码时，你会觉得这个设计相当务实：AI分类器可能需要几秒钟来分析，但用户不必干等着。

第三层防线：最终的用户交互确认。当自动hook审批和AI分类器都无法给出确定结论时，系统才会弹出交互式确认对话框。用户可以在此选择“允许一次”、“永久允许”或“拒绝”。

被用户批准的权限更新会被持久化存储。下次遇到完全相同的“工具+参数”组合时，系统会自动匹配并放行。这就形成了一个 渐进式信任模型：随着使用，越来越多的常规操作会被自动放行，用户只需要关注那些真正需要人工判断的新颖或高风险场景。

多智能体协调与后台任务管理

coordinator/ 模块实现了多智能体协调器。在coordinator模式下，主智能体可以通过 TeamCreateTool 创建团队，每个worker智能体都拥有独立的工具池、权限模型和工作目录。

子智能体通过 AgentTool 派生，支持以下几种关键能力：

• 后台运行：通过 run_in_background 参数，可以让智能体在后台执行，不阻塞主线程。
• 隔离执行：通过设置 isolation: "worktree"，可以让子智能体在完全独立的git worktree中工作，避免污染主代码库。
• 模型覆盖：可以为子智能体指定使用与主智能体不同的模型（如sonnet、opus、haiku）。
• 生命周期管理：通过 TaskCreate、TaskUpdate、TaskStop 等一系列工具，可以精确跟踪和管理后台任务的状态。

后台任务如果运行超过2秒，系统会显示进度提示。在开启了auto-background特性（由GrowthBook功能开关控制）后，任何阻塞主线程超过120秒的智能体，都会被自动转入后台运行。

Feature Flags：超过80个编译期开关

源码中通过 bun:bundle 的 feature() 函数，定义了超过 80个feature flag。这个数量甚至比很多SaaS产品的功能开关还要多。更重要的是，这些flag不仅是运行时开关，更是 编译期死代码消除 的依据：未启用的功能模块在构建时会被完全剥离，不会出现在最终的分发包中。

一些值得关注的功能开关包括：

• KAIROS：助手模式，一个独立于主REPL的会话模式。
• COORDINATOR_MODE：多智能体协调器模式。
• AGENT_TRIGGERS：定时任务和循环执行能力。
• PROACTIVE：主动模式，智能体可以自主决策发起某些操作。
• VOICE_MODE：语音输入支持。
• BRIDGE_MODE：IDE桥接功能。
• WEB_BROWSER_TOOL：内置浏览器工具（依赖Bun的WebView能力）。
• SSH_REMOTE：SSH远程会话支持。
• ULTRAPLAN：增强规划模式。
• FORK_SUBAGENT：以独立进程fork子智能体。

这种设计意味着Anthropic可以为不同的分发渠道（如npm、桌面客户端、移动端）构建功能集合各不相同的软件包，而无需维护多份代码库，极大地提升了工程效率。

Bridge系统：CLI与IDE的双向通信桥梁

bridge/ 模块实现了一个双向通信层，用于连接IDE扩展（如VS Code、JetBrains IDE插件）和本地的CLI进程。其核心机制包括：

• JWT认证：bridge使用JWT token进行会话认证，并实现了自动刷新调度器。
• 轮询模式：bridge主循环通过轮询（采用指数退避策略，最大间隔2分钟）与远程IDE端保持通信。
• 权限回调：IDE端可以拦截并处理来自CLI进程的权限请求。
• 会话管理：支持从IDE内启动、恢复和终止CLI会话。

这个桥接层使得Claude Code可以在VS Code等IDE的扩展中无缝运行：用户在IDE的UI界面内与Claude进行交互，而实际的大模型推理和工具执行则在独立的CLI进程中完成，实现了良好的职责分离。

Context管理与智能压缩

对于长对话场景，上下文管理是任何agentic系统的核心挑战。Claude Code在 services/compact/ 模块中实现了一套多层级的智能压缩策略：

• Auto Compact：自动检测对话上下文长度，在接近模型窗口限制时自动触发压缩。
• Micro Compact：更细粒度的消息级压缩。
• Session Memory：会话记忆提取，将对话中的关键信息持久化保存。
• Snip Compact：标记式历史截断（受特定feature flag控制）。

整个压缩过程会由一个 独立的forked agent 来执行，以避免阻塞主对话线程。压缩操作前后还会触发 pre/post compact hooks，允许开发者或用户自定义压缩行为。

从供应链安全视角看这次泄漏

这次事件首先是一个 发布工程上的严重问题。source map是开发调试的利器，但在将软件包发布到公开的npm registry时，必须要么移除它们，要么确保它们所映射的源文件无法被公开访问。Anthropic在这两个环节上都出现了疏漏。

单从泄露出的源码质量来看，Claude Code的工程水准相当高：

• 严格的TypeScript类型系统。
• 完善的错误处理和遥测上报机制。
• 精细到bash命令AST解析的权限和安全机制（fail-closed策略）。
• 成熟的编译期feature flag系统。

安全工程做得如此细致，却偏偏在最基本的“代码如何安全到达用户手中”这个环节出现了漏洞——这正是供应链安全领域最典型的盲区。开发者往往会投入大量精力保护运行时安全，却容易忽略发布管道本身的安全性。

对于希望深入研究AI Agent系统架构的开发者或研究者来说，这份泄露的源码信息密度极高。工具调用循环、多智能体协调、渐进式权限模型、IDE桥接、上下文管理——这些构建现代agentic系统的核心能力，全部用可读性较强的TypeScript实现，其参考价值远高于同类的Rust或C++项目。可以说，在当前的 开源社区 里，几乎找不到完整度与工程化水平相当的参考实现。