智谱把 ZCode 开源了，然后呢？

一场由 ZCode 本地目录异常膨胀引发的排查，最后把一个 AI Coding 产品推到了安全和信任问题的中心。 9 月 18 日，开发者 ferstar 在清理 MacBook 磁盘空间时，注意到 ~/.zcode 本地目录占用了不少空间。继续逆向客户端和分析网络请求后，他发现，智谱旗下 AI 编程工具 ZCode 会生成本地工作区快照，其中不只有当前代码文件，还包括 .git 历史、Git LFS 缓存、reflog 等内容，并存在将加密快照上传到阿里云 OSS 的链路。ferstar 随后把 完整排查过程和证据链 "公开在个人博客上。 在他进一步分析的一次具体快照中，归档文件大小约 313MB，包含 42,411 个文件，其中约 87% 来自 .git 目录；状态文件显示，这份快照曾经历 564 次上传尝试。不过这份 313MB 快照因为超过大小限制，一直停留在本地 pending 状态，并没有成功上传。ferstar 随后使用另一个较小的公开仓库测试，包含 538 个文件、压缩加密后约 15KB，这一次快照被服务端实际接收。 ferstar 进一步发现，快照采用 AES-256-CTR 加密，加密密钥再由服务端提供的 RSA 公钥封装，对应私钥掌握在云端。按照他逆向得到的链路，客户端首先向 ZCode 服务端获取 snapshot ID、RSA 公钥和 OSS 上传凭证，在本地完成打包和加密后，再将密文直接上传至阿里云 OSS。 事情很快从一次开发者技术排查变成了一场产品信任危机。 智谱随后回应称，问题来自 ZCode 的代码库索引功能。该功能用于支持本地索引、历史版本会话检查点、历史版本回退和 Repo Wiki 等能力，其中 Repo Wiki 在云端生成时可能触发仓库数据上传。智谱表示，这项功能早期默认开启，相关数据在 Wiki 生成后销毁，没有用于模型训练，并就此向用户道歉。 三天后，智谱又采取了更进一步的动作：把 ZCode 整体开源。 目前 ZCode 已公开源代码 "，采用 Apache 2.0 许可证，包括 Desktop、Web、Backend、Agent CLI 和 Agent Runtime 等主要组件。与此同时，ZCode v3.14.0 删除 Repo Wiki，并切断本地仓库 snapshot 的生成和上传链路。智谱还邀请中国信通院和绿盟科技进行安全核查：前者确认相关 OSS bucket 已处于零数据状态，后者确认相关数据对象和 bucket 已删除；智谱同时承诺建立长期漏洞响应和奖励机制。 从事件响应来看，道歉、修复、删除数据、引入第三方核查，再到直接把产品开源，智谱在几天内连续做了几轮整改。不过，对于一款能够读取整个代码库、运行 Shell、连接 MCP、调用插件，并可能接触企业凭据的 Coding Agent 来说，事情并没有随着“开源”结束。 至少还有三个问题值得继续追问：今天公开出来的 ZCode，还有哪些数据会离开本地？为什么开源仓库没有保留事故发生之前的 Git history？当一款 Coding Agent 已经发生过数据边界争议后，“代码开源 + 第三方安全核查”能在多大程度上重新建立信任？ Repo Wiki 没了，但 ZCode 不是一个“只在本地活动”的程序 从目前公开的 ZCode 源码看，最受争议的那条数据链路确实已经被拿掉了。 ferstar 在开源代码公布后重新进行了 源码对账 "。他没有再找到此前客户端中的 repoSnapshot 上传管道，Repo Wiki 相关功能也已经消失。智谱披露的第三方核查结论同样表示，v3.14.0 中没有发现可以继续触发本地仓库快照生成或文件外发的功能路径。 不过，ZCode 也没有因此变成一款“数据不离开本机”的 Coding Agent。智谱在开源仓库里专门放置了一份相当详细的 NOTICE 文件 "，列出了 ZCode 目前仍然存在的外部交互面。 文件、Git、Terminal、Shell、Node REPL 可以在宿主操作系统账号权限范围内读写文件、启动进程和访问网络；插件可以带入自动执行的 Hook、本地程序和远端工具；MCP 可以使用配置中的命令、环境变量、认证 Header 或 OAuth 连接外部服务；内嵌浏览器可以访问网页、读取页面、截图、上传和下载文件；远端 Workspace、SSH、Web 服务又分别拥有自己的网络和权限边界。 ZCode 还在 NOTICE 中提醒用户：当前共享 Agent Runtime 默认并不提供操作系统级 Sandbox。独立 CLI 在使用 --prompt 进行非交互执行、又没有指定 mode 时，会进入 yolo 模式；在这一模式下，普通工具操作可以不经过逐次确认。 Repo Wiki 事件里最显眼的是工作区快照上传，所以最初的讨论基本都围绕代码库上传展开。但放到 Coding Agent 的工作方式里，数据边界显然要复杂得多。 模型 API 需要获取上下文，MCP Server 可能接触文件和凭据，插件和 Hook 可以读取工具参数和返回结果，Browser Agent 可能接触登录态，Shell 则能访问开发者机器上的其他目录。Git、包管理器以及项目里的 lifecycle script，也都可能进入 Agent 的执行链。 因此，判断一款 Coding Agent 如何处理用户数据，单独确认“是否上传 repository”还不够。还需要知道什么数据只停留在本地，什么会进入模型上下文，什么会传给智谱自己的服务器，什么会进入第三方模型；MCP、插件和 Browser 分别能够获得哪些数据；哪些行为需要用户确认；数据保存多久，以及服务端由谁拥有解密和访问能力。 ZCode 开源之后，社区至少有机会沿着源码逐项检查这些数据流。不过，目前公开的信息还不足以形成一张完整的数据流图。 一个只有两条 Commit 的开源仓库，很难还原事故发生时的 ZCode ZCode 开源之后，很快出现了另一个问题。 ferstar 对 公开仓库的 Git history "进行了检查：目前仓库历史极其简单，一个空的 initial commit，加上一个名为 feat: open source 的提交。后一个 commit 一次性加入了约 6973 个文件、103 万行代码。 也就是说，外界目前拿到的主要是整改完成之后的代码快照。此前包含 Repo Wiki、repoSnapshot 和上传逻辑的历史版本，没有随着开源仓库一起出现。 这会直接影响外部开发者对这次事件的复盘。比如，这条上传链最早是什么时候加入的？最初服务于哪个功能？经历过哪些修改？默认开启对应哪一次产品决策？哪些正式版本包含这段代码？最终删除时具体修改了什么？这些原本都可以通过 Git history 和版本 diff 提供线索，现在很难直接从开源仓库中还原。 当然，公开 100 多万行当前代码仍然有价值。至少外部开发者现在可以审查 ZCode 的现有实现，也可以基于 Apache 2.0 许可证自行构建、修改和部署。但如果开源同时承担了安全事件之后恢复信任的作用，代码历史同样是