Claude Code agent 源码泄露事件分析（二）：本地运行与源码调试

Claude Code agent 源码泄露事件分析二本地运行与源码调试上一篇我们把“泄露了什么、值不值得看”讲清楚了。这一篇只做一件事把它跑起来而且是可复现、可调试、对国内网络友好地跑起来。如果你只关心一句话结论优先本地源码运行做调试Docker 运行做隔离验证国内环境先解决镜像和代理不然 80% 的问题都卡在下载阶段。零、先跑通最小闭环3 步如果你想先“眼见为实”不用先啃完整源码首先下载源码 https://github.com/wisdomfriend/claude-code-source-2.1.88 , 再跑这 3 步1准备 DeepSeek API在项目根目录创建或修改.env可参考.env.example至少配置DEEPSEEK_API_KEY你的_deepseek_api_key DEEPSEEK_BASE_URLhttps://api.deepseek.com如果你用的是代理网关或中转服务把DEEPSEEK_BASE_URL改成你自己的地址即可。2准备 Node 运行环境node-vnpm-v建议 Node 20。如果版本过低先升级再继续避免后面出现兼容性问题。3运行 Python 启动脚本python run.py启动成功后你会看到类似下面这个界面Claude Code 启动页一、先说边界学习研究不碰红线这次事件的核心是一次工程发布失误不是授权开源。所以实践前先明确三条边界仅用于架构学习、工程分析、个人实验。不要将可疑来源代码用于商业交付。不要二次传播可能涉及版权争议的原始内容。技术可以学习边界也要守住。二、你要准备什么环境下面默认你已经有一份可用的源码镜像或你自己的分析副本。1基础依赖Git拉代码Node.js 20部分脚本依赖Bun 1.1源码里大量构建/运行逻辑基于 BunDocker Desktop可选用于隔离运行2先做“国内环境”基础设置非常关键npm 镜像npmconfigsetregistry https://registry.npmmirror.comBun 镜像可选但推荐bun configsetregistry https://registry.npmmirror.comGit 克隆慢时任选其一配置全局代理公司网络常见使用可访问的代码镜像源先本地下载 zip 再解压经验判断安装阶段报错里凡是ETIMEDOUT、ECONNRESET、fetch failed先别怀疑代码先怀疑网络。三、本地运行从“能执行”到“可调试”这一段是重点。我们分两步走第一步确认“能执行”第二步切到“可调试”1拉取并安装依赖gitclone你的源码地址claude-code-sourcecdclaude-code-source buninstall如果bun install失败按这个顺序排查bun --version是否正常镜像是否已配置是否被公司防火墙拦截切换热点网络再试一次最省时间2先跑“可执行版本”bun run build bun run start--help看到 CLI 帮助信息就说明主流程是通的。这一步的目标不是“用起来很爽”而是证明“依赖构建入口”都正常。3再跑“可调试版本”不同仓库脚本名字可能是dev/watch/start:dev先看package.jsonbun run常见调试启动方式示例bun run dev如果你习惯 VS Code/Cursor 断点调试可以走 Node Inspectornode--inspect-brk ./dist/main.js然后在 IDE 里附加调试重点盯这几块Agent 主循环任务分发、工具调用权限判断链是否允许执行工具上下文/记忆写入会话状态如何落盘这一步做完你就从“会跑”升级为“能改、能证伪、能复盘”。四、Docker 运行隔离环境快速验证Docker 的价值不是更快而是更干净你能把“我电脑环境有问题”这个变量直接排除。1最小 Dockerfile示例FROM oven/bun:1.1 WORKDIR /app COPY . . RUN bun install RUN bun run build CMD [bun, run, start, --help]2构建与运行dockerbuild-tclaude-code-src:local.dockerrun--rm-itclaude-code-src:local3国内环境下的 Docker 提速建议给 Docker Desktop 配置镜像加速器阿里云/腾讯云/DaoCloud 任一可用源基础镜像拉取失败就先docker pull oven/bun:1.1单独测试构建阶段尽量分层缓存先复制 lock 文件再 install一句话本地调试看“效率”Docker 运行看“确定性”。两者要并行不要二选一。五、源码运行支持国内环境一套实战配置这里给一套我自己常用的“低心智负担”方案尽量少折腾。1统一代理变量按需# Linux / macOSexportHTTP_PROXYhttp://127.0.0.1:7890exportHTTPS_PROXYhttp://127.0.0.1:7890exportALL_PROXYsocks5://127.0.0.1:7890# Windows PowerShell$env:HTTP_PROXYhttp://127.0.0.1:7890$env:HTTPS_PROXYhttp://127.0.0.1:78902锁文件优先多人协作时优先提交并使用 lock 文件bun.lockb或等价文件避免“同样代码不同依赖树”。3拆分“下载问题”和“代码问题”建议固定一个三段式自检命令buninstallbun run buildbun run start--helpinstall失败网络/镜像问题概率最高build失败依赖版本或编译问题start失败运行时配置问题这样你排错会非常快不会陷入“玄学修复”。六、你最可能遇到的 5 个坑Bun 版本过旧直接升级到 1.1。镜像没配全npm 配了Bun 没配结果还是慢。公司网络拦截 TLS看起来像依赖错实则证书链问题。脚本名不一致不同镜像仓库dev/build/start命名不同先bun run看清单。把 Docker 当调试器Docker 适合验证一致性不适合高频断点联调。七、这一篇的结论“能执行”只是门槛“可调试”才是生产力。这次源码事件真正有价值的不是围观热闹而是借这个机会把 Agent 工程化方法吃透本地源码运行拿到调试能力Docker 运行拿到环境确定性国内网络优化拿到稳定复现能力当你把这三件事打通后面无论是做架构拆解还是做自己的 Agent 产品速度都会完全不一样。我正在写下一篇《Claude Code agent 源码泄露事件分析三从源码里拆 5 个可复用的 Agent 设计模式》。