Claude Code源码泄露传闻真伪辨析：从npm包到agent loop的安全排查-开发者社区

简介：Anthropic 官方 Claude Code 命令行工具的完整源代码压缩包（2026年4月1日版），面向 AI 编程助手研发者、CLI 工具爱好者和希望深入理解 MCP 协议、Agent 工具链及终端交互设计的中高级开发者，是一份适合源码级拆解与二次开发的基础参考。源码在 src 目录下按职责清晰分层：commands 实现斜杠命令，components 与 design-system 负责终端 UI，services 包含 API、MCP、分析、设置同步等核心服务，tools 提供 Bash、文件读写、Grep、Glob、Task 等工具，另含 hooks、schemas、ink 等基础模块，模块划分完整，类型定义清晰，方便逐一研读。压缩包共 1903 个文件，以 TypeScript 为主，其中 1332 个 ts 与 552 个 tsx 分别承载纯逻辑与 UI 组件，另有少量 js 和 1 个 md 说明文件，包体大小约 9.43MB。目前已有 707 人学习下载。通过通读源码，可掌握 Claude Code 的命令调度机制、工具封装方式、MCP 通信设计以及终端交互渲染逻辑，对自研 AI 编程助手或二次开发脚手架具有直接参考价值，尤其适合研究工具调用、上下文维护与权限控制等核心实现。

1. 源码泄露？先看一眼日期再决定要不要激动

“Claude Code源码泄露”这个标题，真正值得先看的不是内容，而是日期。4月1日，懂的都懂。这几天确实有技术群里在转一个几百 MB 的压缩包，配文是“限时删除”“错过再无”这类话术。作为一个被各种假源码坑过的人，我的第一反应不是下载，而是问三个问题：官方发布形态里到底有没有“源码”这个概念；如果真泄露了，普通开发者拿到能做什么；如果是个钓鱼包，我能不能在五分钟内识别出来。这篇笔记就是围绕这三个问题展开的。

2. Claude Code 的发布形态与“源码”的边界：npm包、打包产物、闭源推理层

2.1 所谓的“源码”在工程上其实分三层

先说结论：Claude Code 的发布形态是一个 npm 包，安装后本机跑的是打包压缩过的 JavaScript 产物，不是一份能直接阅读、修改、重新构建的 TypeScript 工程。所谓“源码泄露”，在工程上至少要拆成三个层次看待。

第一层是 CLI 侧逻辑，包括命令行解析、会话管理、工具调用、权限确认、日志输出。这一层会以压缩后的 dist 文件形式出现在你本机的 node_modules 里，严格说它“可见”，但变量名和函数名都被混淆过，可读性很差，谈不上“泄露”。

第二层是 agent 循环的编排层，官方术语里叫 harness。它负责把用户的一句话目标翻译成多轮工具调用，维护上下文状态，决定什么时候调用 read_file、什么时候执行 bash、什么时候停下来问你要权限。这一层同样打包在 npm 产物里。

第三层是模型推理服务本身。真正的模型权重、推理逻辑、服务端调度都在远端，CLI 进程里只有一个 HTTP 客户端。这一层是不可能通过一个“源码压缩包”泄露到你手里的，因为它在任何本地分发链路中都不存在。

所以当你看到一个帖子声称“Claude Code 完整源码泄露”，先问它说的是哪一层。如果压缩包里是几千个 .ts 源文件且带完整 .git 目录，反而说明它是别人重新整理过的二手工程；如果声称包含模型服务端源码，那基本可以直接判断为噱头。

2.2 从安装到首次运行：一条命令背后发生的事

很多人搜“claude code安装”“claude code下载安装”，以为装完就能看到全套源码，其实安装过程本身就说明了它的分发策略。最常见的安装方式是全局 npm 安装，命令如下：

# 全局安装 Claude Code 的官方 npm 包 npm install -g @anthropic-ai/claude-code # 查看安装后的可执行文件 which claude # 常见输出：/usr/local/bin/claude -> ../lib/node_modules/@anthropic-ai/claude-code/cli.js

安装完成后，npm 会在系统全局目录下建立 bin 软链，把 cli.js 暴露成 claude 这个命令。你真正执行的入口就是一个压缩后的 JavaScript 文件，它内部再按需 require 同目录下的一系列 chunk 文件。

这里有几个安装时需要留神的参数和环境问题。Node.js 的版本要满足官方要求，太老的版本会在启动时直接报语法错误，因为打包产物使用了较新的 JS 语法。全局安装目录的写权限也经常出问题，如果你之前改过 npm prefix，或者用 sudo 装过别的全局包，后面会出现 auto-update failed 一类的报错，这个我在第 4 章单独讲。网络源方面，npm registry 可以换成你网络环境下访问更快的镜像节点，但要注意镜像节点的同步频率，官网已发布新版而你本地的镜像还没同步，是很多“装完还是旧版”的根源。

第一次运行 claude 会要求完成登录授权，这是官方的账号流程，和源码无关。在 VSCode 里配置 Claude Code，本质上也只是在集成终端里运行同一个 claude 命令，不需要单独的插件安装，很多教程把这件事复杂化了。

2.3 真正值得研究的骨架：harness、agent loop 与工具调用循环

抛开“源码”这个诱饵，Claude Code 里真正有学习价值的是 harness 的工程设计，而这些信息并不需要靠泄露包获取。官方文档中对 harness 的描述、CLI 自身的日志输出、hook 机制、MCP 配置格式，已经把架构轮廓暴露得很清楚。

一个典型的 agent 循环是这样运转的：用户输入目标 → 模型返回一个决策，可能包含工具调用 → CLI 检查该工具是否需要权限确认 → 执行工具并把结果回填给模型 → 模型继续决策 → 直到模型认为任务完成。这个循环和很多开源 agent 框架的结构一致，差别在于实现细节：工具结果如何截断、上下文窗口满了怎么办、失败的工具调用如何重试、权限确认怎么不打断用户节奏。

// 一个高度简化的 agent loop 伪代码 let messages = [{ role: "user", content: "把当前目录的 README 总结成 5 条要点" }] while (true) { const decision = await model.chat(messages) // 调用模型 if (decision.tool_calls == null) break // 不再要工具说明任务结束 for (const call of decision.tool_calls) { if (needPermission(call.name)) await confirm(call) // 关键交互点 const output = await tools[call.name](call.arguments) // 执行 messages.push({ role: "tool", content: output }) // 回填结果 } if (messages.length > 40) messages = trimHistory(messages) // 控制窗口 }

这段代码里最值得品的是 needPermission 和 trimHistory 两个点。前者是 agent 在真实工程环境中能落地的前提——工具权限不能全程自动放行，否则一个错误指令就能删库；后者决定了长任务的稳定性，窗口一满，简单粗暴地丢弃早期消息会导致 agent 失去任务上下文，这是很多自建 agent 翻车的常见原因。

理解了 harness 与模型服务的关系，就能回答一个常被问到的问题：能不能把 Claude Code 的 harness 换成别的模型来跑。从架构上看，CLI 和模型服务之间是协议解耦的，社区里也有人通过改环境变量里的接口地址和模型名，把整个工具链指向兼容 OpenAI 协议的第三方服务。这件事和“源码泄露”没关系，它恰恰说明协议层的研究价值高于追逐一个假泄露包。

3. 判断一个“Claude Code源码包”的真伪：四步核对法

3.1 第一步：核对包名、版本号与发布时间

拿到一个号称 Claude Code 源码的压缩包，先别急着解压。第一步是回到 npm registry，核对官方真实的包名、版本号和发布时间。伪造者最容易犯的错误，就是给一个根本不存在的版本号，或者发布时间对不上。

# 查官方包的最新版本号和各版本发布时间 npm view @anthropic-ai/claude-code dist-tags --json npm view @anthropic-ai/claude-code time --json # 查官方包名是否存在 npm view @anthropic-ai/claude-code name version

dist-tags 里看 latest 字段，这是当前稳定版的真实版本号。time 字段里能看到每一个版本的发布时间，重点看 modified 时间，它代表官方最近一次更新。如果压缩包里的 README 声称自己是 5.x.x，而 latest 明明是 2.x.x，说明这个包要么是改名的翻版，要么是故意夸大的噱头。

版本号相同也不能直接信任。很多钓鱼包会把 README 改成和官方一模一样，但 package.json 里的 name、version、bin 字段被悄悄改过。所以下一步要做的不是读 README，而是对比 package.json 的完整字段和文件清单。

3.2 第二步：检查文件清单和入口，识别官方产物特征

解压之前可以先列清单。无论压缩包是 tar.gz 还是 zip，都可以在不解压的情况下查看内部文件列表，这一步能暴露大量信息。

# 查看 tar.gz 包内的文件清单 tar -tzf claude-code-source.tar.gz | head -50 # 查看 zip 包内的文件清单 unzip -l claude-code-source.zip | head -50

官方 npm 包的文件结构有两个显著特征：根目录一定有一个 package.json，bin 字段指向一个 cli.js 入口；主体代码在 dist 或者 vendor 目录下，是一堆压缩后的 js/chunk 文件。你可以看到 readme、license，但不会看到一个完整的 src 目录，更不会有 .git 目录。

我见过把官方发布产物重打包成“源码包”的例子，也见过拿一个无关开源项目改标题的例子，两种情况的文件清单截然不同。把常见特征整理成一份对比，判断时会快很多：

这个表不能覆盖所有情况，但能帮你过滤掉八成以上的假包。真正需要继续做硬核对的是那些文件结构看起来很像官方产物的重打包包。

3.3 第三步：拉官方包做哈希与体积比对

文件清单看着像还不够，第三步用哈希和体积做一次硬核对。npm 自带 pack 命令，可以把官方包完整下载成 tgz，然后计算哈希和你的压缩包对比。

# 下载官方包到本地 npm pack @anthropic-ai/claude-code # 生成类似 anthropic-ai-claude-code-2.x.x.tgz 的文件 # 计算官方包的哈希 shasum -a 256 anthropic-ai-claude-code-2.x.x.tgz # 计算你手上“泄露源码包”的哈希 shasum -a 256 claude-code-source-4-1.tar.gz

哈希完全一致的情况几乎不存在，因为两个包的构建时间和元数据不同；但你可以看体积数量级。官方 CLI 打包出来是一个正常工具链该有的大小，如果你手上的“完整源码”只有 200KB，那它连官方产物都未必是，更别谈源码。反过来，如果自称源码的包体积异常巨大，里面大概率塞了一堆不相关的资源文件撑体积。

这里有一个容易误导人的点：哈希不一致不能证明它是假的，它可能是某一次构建快照；但哈希不一致加上文件结构和版本对不上，三个证据叠加，基本可以下判断。还有一个更直接的检查方向，打开压缩包里的 JS 文件随便抽几段，搜有没有官方域名、官方 CLI 标志性的提示语、以及产物混淆痕迹。一个声称“源码”的包里没有这些字符串，说明它和真正的 Claude Code 关系不大。

3.4 第四步：断网最小启动，盯住网络行为

文件和哈希都核对完，还有一种情况需要实测：包是别人重打包的官方产物，但被注入了后门逻辑。这时候要做的不是直接在主力环境里登录运行，而是找一个隔离环境做一次启动观察。

# 在隔离目录里直接调用入口脚本，先看它打印什么 cd /tmp/inspect-source node cli.js --help # Linux 上用 strace 观察网络相关系统调用 strace -f -e trace=network node cli.js --help 2>&1 | head -50

第一次运行建议加 --help 或者直接传一个无害参数，目的不是完成任务，而是看它的启动过程有没有超出预期的行为。如果它突然开始请求一个陌生域名、往临时目录写奇怪的文件、尝试读取 ~/.ssh 或 ~/.aws 下的密钥，那这就是一个带后门的重打包包。

需要特别强调的是，不要在主力环境、不要用真实账号去试运行一个来源不明的包。我见过拿到包就迫不及待登录官方账号跑 demo 的开发者，结果账号密钥通过环境变量被脚本读走，几分钟后就看到了异地登录提醒。所谓的“泄露源码”验证，安全优先级永远是第一位。

4. 号称泄露的源码包避坑记录：五分钟内出现这些现象就该停手

4.1 现象：装完CPU占用异常飙升

现象描述：解压后照着 README 运行安装脚本，机器风扇马上狂转，CPU 占用率冲到 90% 以上，而且没有任何窗口显示任务进度。

原因分析：这类“源码包”里通常带一个安装脚本，脚本在后台拉取并执行了挖矿模块。挖矿程序为了不被立刻察觉，往往把自己写成无界面守护进程，占用率又不做限流，结果就是整机卡顿。

解决思路：立即断开网络，用 htop 按 CPU 排序找出可疑进程并 kill，再去检查 crontab、开机自启目录和 /tmp 下的临时文件。然后把全局 node_modules 里那个可疑包彻底删掉，改回官方 npm 源重装。这个处理顺序很重要：先断网再做清理，否则挖矿程序会从远端拉取新版继续运行。

4.2 现象：一运行就要求安装“Python依赖包”

现象描述：运行时脚本提示“缺少环境依赖，需要执行 python 安装命令”，给出的命令里含有一段你从没见过的一大串 --index-url 参数。

原因分析：这是典型的供应链注水手法。安装脚本在安装阶段通过自定义 pip 源把恶意 Python 包混进环境，后续通过 Python 进程执行命令。伪造者预判了你的好奇心，把“安装依赖”包装成常规初始化动作，用户很容易习惯性回车执行。

解决思路：任何时候都不要直接执行 README 或 install.sh 里给的安装命令。先打开脚本读一遍：head -80 install.sh，看里面有哪些外联地址、有没有 base64 解码、有没有把内容重定向到某个 URL。一旦看到类似 curl xxx | bash 或 python -c “…” 的结构，果断停手。如果已经执行了，检查 pip list 里是否多了和项目无关的包，再看 ~/.bashrc 是否被追加了可疑行。

4.3 现象：配置目录里藏着无法解释的外联地址

现象描述：包自带的“激活脚本”往 ~/.claude 下写入了 settings.json，打开后里面多了一个你在官方文档里没见过的 apiBaseUrl 或 endpoint 字段，指向某个陌生地址。

原因分析：这类配置把模型请求的流量转发到第三方服务器。Claude Code 这类 CLI 是按协议和远端服务通信的，配置文件里的接口地址、认证密钥就是流量入口。被篡改后，你的授权信息会随每次请求一并发送给攻击者。

解决思路：检查 ~/.claude 目录下所有 json 配置，对照官方文档确认哪些字段是合法的。出现不在官方文档里的 apiBaseUrl、代理地址、自定义证书路径，直接删除对应字段或整份配置。修改配置后重启 CLI，再看日志输出里的请求地址是否恢复为官方域名。

4.4 现象：auto-update failed: no write permission to npm prefix

现象描述：装了某个来源不明的包之后，启动 claude 时报 auto-update failed: no write permission to npm prefix，自更新一直失败，但命令行本体能跑。

原因分析：这个问题其实不一定是恶意包引起的，更多是全局 npm 目录权限不对。npm 的全局 prefix 指向 /usr/lib/node_modules 或 /usr/local/lib/node_modules，如果之前用 sudo 装过包，目录所有者被改成了 root，后续以普通用户运行 claude 时自更新就写不进去。所谓“破解版”经常遇到这个报错，因为它的安装方式改了目录权限。

解决思路：先看 prefix 指向哪里，再修正目录所有者，不要用 chmod 777 这种一刀切方式。

npm prefix -g ls -ld "$(npm prefix -g)" sudo chown -R "$(whoami)" "$(npm prefix -g)"

修正后再跑 claude 的自动更新，确认能顺利拉到新版，这本身也能验证你装的包是否还和官方更新通道连通。如果 chown 之后启动仍然报错，说明这台机器的 node 安装路径本身有问题，可以考虑改用用户级目录重新安装，但不要因此轻易卸掉系统 node，容易造成其它全局命令同时失效。

4.5 现象：提示“源码已加密”，交钱才给解压密码

现象描述：压缩包解压到一半弹出提示，说主目录被 AES 加密，联系发布者付费才能拿到密码。这是最直接的信号。

原因分析：这已经不是“源码泄露”问题了，是拿泄露噱头做引流或骗局。所谓“限时删除”“交押金看源码”，本质是利用白嫖心理让人付费。真正的开源或泄露内容不会用加密套娃的方式分发。

解决思路：不付款，不联系，直接放弃这个包。也不要因为好奇去运行它附带的主程序，加密可能只是个幌子，主程序一旦执行就可能干别的事。对这类包的正确处置是记录文件名和来源渠道，然后删除，再回到官方 npm 渠道装一遍正规产品。

5. 不追泄露也能拆开学：基于官方安装产物的工程梳理与最小复刻

5.1 从 package.json 和 dist 入口反推启动链路

不追伪造的泄露包，官方安装产物里的工程信息已经足够学一阵。安装完成后，先定位全局包目录，把 package.json 和文件结构读一遍。

NODE_PATH=$(npm root -g) ls -la "$NODE_PATH/@anthropic-ai/claude-code" cat "$NODE_PATH/@anthropic-ai/claude-code/package.json" # 用 node 直接读取关键字段 node -e "const p=require('$NODE_PATH/@anthropic-ai/claude-code/package.json'); console.log('version:', p.version); console.log('bin:', JSON.stringify(p.bin)); console.log('main:', p.main)"

package.json 里的 bin 映射能告诉你 claude 命令实际指向哪个入口，main 字段则标记了库模式下的入口。顺着 cli.js 打开，能看到它 require 了哪些模块，这个依赖关系就是启动链路的地图。

读这一层时，重点不是读懂每一行混淆代码，而是记录模块名和文件大小，找出哪些 chunk 被入口直接依赖、哪些是懒加载。懒加载文件通常对应按需功能，比如某个特定工具或某种登录方式，启动时不会被立即执行。这种静态分析习惯，比追一个假泄露包能积累更扎实的工程判断力。

5.2 用字符串搜索定位 agent loop 的关键节点

打包产物虽然被压缩混淆，但字符串常量不会被全部抹掉。工具名称、权限提示语、错误信息、日志模板这些字符串，会原样留在产物文件里。用 grep 做一次字符串挖掘，就能还原 agent loop 的大致地图。

NODE_PATH=$(npm root -g) CLAUDE_DIR="$NODE_PATH/@anthropic-ai/claude-code" # 列出所有工具相关的字符串 grep -roh "read_file\|execute_command\|write_file\|notify" "$CLAUDE_DIR" | sort | uniq -c | sort -rn | head -20 # 检索权限确认提示语 grep -roh "permission\|allow\|deny" "$CLAUDE_DIR/dist" | sort | uniq -c | sort -rn | head -20

grep 结果里出现频率高的工具名，基本就是 agent 默认开放的工具集；权限相关字符串的密度能告诉你哪些操作默认需要确认。把这些字符串和一个实际的运行日志对照看，你会发现模型的 tool_calls 参数名、CLI 内部的事件名、日志里打印的字段名是一一对应的。

这个方法的妙处在于完全基于官方产物，合法且可持续。每次官方更新版本，重新跑一遍字符串挖掘，还能看到新增工具和变更提示语，相当于一份自动生成的版本差异说明。如果你要写自己的 agent，这些字符串就是现成的兼容性参考。

5.3 一份最小可运行的“harness”骨架

前面分析了这么多，最终价值应该落在能动手。我经常给同事看的一份最小 agent 骨架长这样：它只有一个 read_file 和一个 bash 工具，通过一个循环把模型决策和工具执行串起来。代码刻意精简，目的是展示 harness 的核心机制，不是复刻产品。

import os import subprocess TOOLS = { "read_file": lambda path: open(path, encoding="utf-8").read(), "bash": lambda cmd: subprocess.run( cmd, shell=True, capture_output=True, text=True ).stdout, } def call_model(messages: list[dict]) -> dict: # 这里通过任意兼容 OpenAI 协议的端点调用模型 # 需要设置环境变量 LLM_ENDPOINT 和 LLM_MODEL endpoint = os.getenv("LLM_ENDPOINT") model = os.getenv("LLM_MODEL") # 省略 HTTP 请求细节，返回模型的响应 JSON raise NotImplementedError("用你手头的模型服务补全这段") def agent_loop(task: str, max_turns: int = 5) -> None: messages = [{"role": "user", "content": task}] for _ in range(max_turns): resp = call_model(messages) tool_calls = resp.get("tool_calls") if not tool_calls: print(resp["content"]) return for call in tool_calls: name = call["function"]["name"] args = call["function"]["arguments"] result = TOOLS[name](args) # 执行工具 messages.append({"role": "tool", "tool_call_id": call["id"], "content": result}) print("达到最大轮次，停止。")

这段骨架里的关键参数是 max_turns，它决定了 agent 不会因为模型反复请求工具而进入死循环。TOOLS 字典是工具白名单，不加新工具模型就无法调用它。实际运行前应该把环境变量配好，并确认 TOOLS 里每个函数都能处理异常，工具抛错会直接中断整个循环，这是新手最容易翻车的地方。

从这个骨架再往前迈一步就是权限确认、消息历史裁剪、工具结果截断。每一步都是在解决真实场景里的一个问题，而不是追逐一份来路不明的源码。理解了这些，再回头看“源码泄露”的标题，你会发现真正该学的部分从来不在那个压缩包里。

6. 一个具体习惯：拿到任何代码包，先“三查三试”再动手

把前面五章的思路浓缩成一条可执行的习惯，就是三查三试。三查：一查包名和版本是否与官方 registry 对得上；二查文件清单里有没有不该在发布包里出现的东西，比如源码目录、.git、加密提示、安装脚本外联；三查解压后的配置和脚本内容，重点看 api 地址、密钥路径、base64 解码段。三试：一试试在隔离目录里，不用主力工作目录；二试先断网或最小权限跑 --help，观察有没有意外外联；三试看日志和进程列表，确认没有多余的子进程常驻。

这个习惯在分析任何来源的第三方包时都通用，不只是 Claude Code。源码泄露的瓜每年都有，但绝大多数最后都被证伪成引流工具或钓鱼包，真正值得投入时间的，是理解一个成熟 CLI 的发布形态和 agent 循环的骨架设计。这些年我养成的习惯是，任何来路不明的包都不直接进工作目录，先解压到 /tmp 看一眼脚本再决定。这个习惯帮我避开了很多麻烦，不只是挖矿脚本，还有各种伪装成工具包的引流陷阱。希望这篇笔记能帮你在下次看到“完整源码”标题时，先花五分钟做三查三试，而不是被 4 月 1 日的时间戳带着走。希望帮到你。

本文还有配套的精品资源，点击获取