ZCode 被查出登录后打包上传整个 Git 历史，官方随后开源核心仓库并公布第三方核查结论

一位开发者在清理磁盘时发现 ~/.zcode 目录占了 700MB 以上，顺着查下去得到结论：ZCode（智谱的 AI 编程桌面客户端）在登录状态下会把整个工作区打包上传到云端对象存储，内容包含完整的 .git 历史、LFS 资源缓存、reflog 以及全局应用配置；上传内容是加密的，而加密用的公钥由服务端在运行时下发，私钥只存在于云端，也就是说留在本机的那份密文客户端自己也无法解密。作者记录到的一次快照包含 42,411 个文件、313MB，其中 .git 目录占 86.6%，界面上的开关挡不住这个行为。9 月 21 日事件有了后续：官方在 X 发布声明并开源核心仓库（Apache-2.0），作者逐条比对后指出几件事——新仓库只有两个提交（一个空的初始提交，加一个一次性导入 6,973 个文件、约 103 万行代码的提交），历史提交被完全抹平，PR 与 Issue 一并关闭；他此前抓到的上传凭据接口、直接上传对象存储、AES-256-CTR 加密与公钥下发在代码里检索不到任何匹配；官方称「会话检查点回滚需要上传整仓快照」，但代码里检查点的实现完全依赖本地 Git 命令，元数据存在本地目录下，与云端无关。官方同时转述两家第三方评估的结论：一家确认线上存储桶中已无数据、客户端 v3.14.0 移除了快照生成与上传流程，另一家确认存储桶与内部对象均已删除、未发现外发传输路径。

线索来自一次清理磁盘

事情的起点很日常：作者在腾磁盘空间时注意到 ~/.zcode 占了 700MB 以上。查下去他发现，只要处于登录状态，这个 AI 编程桌面客户端就会把整个工作区打包上传到云端对象存储——打包内容包含完整的 .git 历史、LFS 资源缓存、reflog 以及全局应用配置；记录到的一次快照有 42,411 个文件、313MB，其中 .git 占 86.6%。

更值得记的是加密方式：上传内容用 AES-256-CTR 加密，而加密使用的公钥由服务端在运行时下发，私钥只存在于云端。结果是留存在本机的那份密文，客户端自己也无法解密。界面上的开关挡不住这个行为，作者给出的临时防御手段是锁定相关目录。

9 月 21 日的后续：声明、开源与逐条比对

事件在 9 月 21 日出现转折。官方在 X 发布声明，并开源了核心仓库（Apache-2.0）。作者拿到代码后做了逐条比对，给出了几个具体观察：

新仓库只有两个提交——一个空的初始提交，加一个一次性导入 6,973 个文件、约 103 万行代码的提交；历史提交被完全抹平，PR 被锁定、Issue 被关闭，属于单向代码投放；
他此前抓到的上传凭据接口、直接上传对象存储、AES-256-CTR 加密与公钥下发等特征，在公开代码里检索不到任何匹配；
官方称「会话检查点回滚需要上传整仓快照」，但代码里的检查点实现纯依赖本地 Git 命令（按提交 OID 执行 diff），元数据以 JSON 存在本地目录下，与云端无关。

官方引用的第三方结论

官方声明中还转述了两家第三方评估机构的结论：一家确认线上存储桶中已无数据、客户端 v3.14.0 移除了快照生成与上传流程；另一家确认存储桶与内部对象均已删除、未检测到外发传输路径。作者的评价是：彻底删除存储桶是必要的止血动作，但「当前代码里没有」与「历史上没有发生」是两件事。

这件事真正留下的经验

对使用方来说，可复用的经验有三条：第一，把「客户端会不会把工作目录之外的东西送出本机」当成采购前的必查项，用出站流量监控实测，别只看界面开关；第二，代码托管在本地时，.git 历史本身就是敏感资产，包含被删掉的密钥与内部文档；第三，当事故进入「已开源、已核查」阶段，评价重点应该从「有没有上传」转到「删除能不能被验证、后续版本有没有可审计的变更记录」。