ZCode 被曝静默上传 Git 历史记录

2026 年 9 月 18 日，一位网名 ferstar 的开发者发布了对 ZCode 的逆向分析报告。ZCode 是 Z.ai 推出的 AI 编程桌面应用，Z.ai 是总部位于北京的公司，开源权重模型 GLM 系列背后的团队——本地 AI 社区里无数机器上跑的正是这些模型，包括本站跟踪的 GLM-5.3-Flash。这一发现比大多数隐私丑闻还要离谱：只要应用处于登录状态，它就会静默打包用户的整个工作区——完整的 .git 历史、LFS 资源缓存、reflog 以及全局应用配置——加密后上传到阿里云的 OSS 对象存储。研究者自己抓到的数据：一个由 345MB 商业工作区、42,411 个文件生成的 313MB 加密压缩包，调查期间还记录到 564 次上传失败的尝试。 如果你在本地跑 GLM，要明白发布模型权重的公司和开发者在其之上使用的运行时工具并不是一回事——而讨论区的反应说明这种混淆真实存在：好几条评论以为 ZCode 因为 GLM 开源所以也是开源的。它不是。权重是开放的，但这个"壳"是闭源的，而且正是 Z.ai 为自家模型打造的外壳，主打第三方编辑器无法企及的官方集成。 这件事在几个小时内在中英文社区同时传开：ferstar 的帖子浏览量突破 27.6 万，FeiZ 的中文预警帖（"暂时禁用 ZCode……尽量用开源 agent 才是最稳妥的"）又收获了 6.38 万浏览。被引用最多的回应来自 Petri Kuittinen，他自己的 AI agent 是开源的，还配有安全文档："我的建议一直没变，以后也不会变：不要相信闭源的 AI 外壳。" 把一个可疑目录变成新闻的关键细节是：加密密钥。ZCode 采用信封加密——数据先用对称密钥加密，这个对称密钥再用 RSA-OAEP 公钥封装。公钥由服务器在上传凭证协商时下发，对应的私钥只存在于 Z.ai 的云端。ferstar 尝试用本地系统上的所有私钥去解开压缩包，全部失败。这 313MB 存在用户自己磁盘上的密文，用户自己解不开，ZCode 客户端本身也解不开。 ferstar 在帖子里的结论是："一把只有服务器才能用的密钥，唯一的用途就是保证服务器随时想读你的代码就能读。"

打包了哪些内容

```markdown

打包清单以明文形式存储在本地，且细节明确。对于包含 42,411 个文件的快照：

内容	大小	占比
.git/lfs/	196.1 MB	56.8%
.git/objects/	102.2 MB	29.6%
.git/logs/	0.6 MB	0.2%
源代码与文档	46.2 MB	13.4%

仅 .git 目录就占负载总量的 86.6%。

这一点至关重要，因为 Git 对象库并非工作树的快照，而是仓库自创建以来的完整谱系。即使在后续提交中已删除的 API 密钥、揭示未发布产品计划的未推送分支名称、以及 .git/config 中的内部主机名和仓库路径，都包含其中。一旦归档被截获，获取的是数年的工程历史，而非你当时打开的文件。

根据客户端 app.asar 重建的上传流程如下：客户端向 zcode.z.ai 请求凭证，后者返回 OSS 表单签名、对象键、大小上限及每轮 RSA 公钥；客户端将工作区打包为 tar.gz，使用 AES-256-CTR 加密，封装对称密钥，并将归档直接 POST 至阿里云 OSS，随后由 OSS 回调 Z.ai 后端注册该快照。测试期间，运行中的客户端维持着与 zcode.z.ai 及两个阿里云 OSS 节点的持久连接。

开关无法阻止上传

最自然的反应是打开设置。ferstar 将 UI 开关与代码进行了交叉比对：

```

• “Optimize Experience”（optimizeAgentExperienceEnabled）仅控制数据是否被授权用于模型训练。快照捕获与上传始终继续进行。
• “Repo Snapshot Indexing”（repoSnapshotIndexingEnabled）仅控制服务器是否对上传的快照建立索引。本地打包与上传始终继续进行。

宿主程序在启动时无条件实例化捕获 sidecar（伴随进程），不受用户偏好设置任何限制——唯一要求是 token provider 能生成有效的 JWT。会话日志显示，单次活跃会话触发了 62 次捕获事件，发生在每次提示提交前及任务完成时。

第二份佐证印证了这一机制。OrcaPromptVault 是一个公开的 AI 框架提示词集合，其中包含 ZCode 的 131KB 系统提示词和 31 个工具界面。检查点/回退（checkpoint/rewind）功能已嵌入系统提示词——模板 “Workspace rewind applied. rewindId, checkpointId, strategy, restoredFiles” 出现了五次。这是快照流水线中面向用户的终端功能，也是被文件系统锁禁用的功能。

该 agent 的完整工具集不包含任何快照、上传或遥测（telemetry）工具。数据外泄流水线并非 agent 工具，而是宿主级别、在工具循环外实例化的 sidecar。这就是为什么没有任何权限设置能阻止它，也是 agent 本身无法感知它的原因。在 131KB 的捕获指令中，未提及 Aliyun、OSS、上传或隐私。

捕获还揭示了一个 ferstar 未提及的细节：ZCode 内置 ReadSessionContext 工具，可按会话 ID 按需读取其他已持久化的 ZCode 会话。结合宿主级别的快照 sidecar，会话内容既被本地持久化，又被捕获至云端。

隐私政策未提及此事

ZCode 的隐私政策声明该工具会收集“对话中提交的文本、文件和代码”——这是所有 AI 编程工具的标准推断上下文披露条款。ferstar 翻遍了政策、FAQ 和更新日志，都没有找到关于打包并上传整个工作区和 Git 历史记录的说明。最接近的一条，只是一个模板式声明，说优化计划默认关闭。

让事情更糟的背景

ZCode 于 2026 年 7 月发布，发布卖点直接打的是信任牌。就在 Claude Code 隐藏遥测争议爆发几周后，Z.ai 把 ZCode 作为 Anthropic Claude Code 的对标产品推出，将开源权重定位为摆脱“远程开关”问题的出路。有 Z.ai 高管在 X 上被问及 ZCode 是否会包含“任何形式的间谍软件”时，回答称公司不会实现 ZCode 网站上未列出的“任何东西”。

而工作区快照并没有列在 ZCode 网站上。

Z.ai 于 2026 年 1 月在香港交易所上市。截至发稿，该公司官方 X 账号尚未回应 ferstar 的帖子。最显眼的回复来自一个与 ZCode 团队相关的账号——“哎，很抱歉让你发现了”——这读起来更像是对该机制的确认，而非反驳。ferstar 的推文在 13 小时内浏览量突破 27.6 万，V2EX 和 HN 相关社区的讨论基本分成一边倒的两种声音：智能体在工具调用时上传代码片段是常有的事，而且都经过用户同意。但这次是完整仓库加上全部历史记录，未经同意，还做了加密，只有厂商能读取。

有效的防御方法

删除待上传的压缩包没用：客户端半小时内就重新打包了一个新的 313MB 压缩包，重试计数器还在递增。真正管用的办法是文件系统层面的——在内核层面把 checkpoints 目录设为不可写：

Linux：

Copy

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints

macOS：

Copy

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints

代价是：checkpoint 回滚 UI 会失效——毕竟这个功能本身就需要上传你的代码。聊天、自动补全和工具调用均不受影响。需要恢复时，用 chattr -i 或 chflags nouchg 即可。

对本地部署意味着什么

本地部署开放权重模型向来是这一赛道的卖点：模型归你，硬件归你，没有按 token 计费，也不存在供应商随时断供的风险。但 ZCode 的案例将安全考量延伸到了模型层之外——模型周围的运行环境，包括测试框架（harness）、桌面应用和更新管道，同样是信任边界的一部分。一个在本地运行、却依赖云端通信外壳的模型，本质上并不算“本地”。

由此可得出两项关键检查，适用于该领域的所有运行框架，而非仅限于 ZCode：登录状态下运行时会传输什么数据？谁有能力解密其存储的内容？Tokenstead 正追踪各智能体框架及其遥测行为，正是出于这一目的。若 Z.ai 后续发布修复、调整披露策略或发表声明，本文将同步更新。

参考资料：

• Inside ZCode: Silently Uploading Your Entire Git History to the Cloud - ferstar，2026 年 9 月 18 日（完整取证：asar 重建、加密流程、清单解析）
• ferstar on X - 概要帖，27.6 万次浏览
• FeiZ on X - 中文预警帖，6.38 万次浏览
• ZCode releases and changelog - Z.ai 官方
• V2EX discussion thread - 社区讨论（中文）
• lookonchain coverage