2026 年 9 月 18 日，开发者 ferstar 发布了针对 ZCode 的完整逆向分析。ZCode 是 Z.ai 推出的 AI 编程桌面应用，该公司总部位于北京，是 GLM 系列开放权重模型的开发者——包括本站此前跟踪过的 GLM-5.3-Flash，这些模型在本地 AI 社区的个人设备上被广泛使用。分析揭示的行为比一般意义上的隐私争议更为严重：只要应用处于登录状态，它就会静默打包用户的整个工作区——完整的 .git 历史记录、LFS 资产缓存、reflogs 以及全局应用配置——完成加密后，将压缩包上传至阿里云 OSS 对象存储。研究者自行抓包的数据显示：一个 345MB 的商业工作区被压缩为一个 313MB 的加密压缩包，内含 42,411 个文件；在调查期间，客户端日志中记录了 564 次失败的上传尝试。
一个在本地运行 GLM 的人需要明白一点：发布模型权重的公司，与开发者在权重之上使用的运行时，是两个不同的信任层面。评论区的反应印证了这种混淆确实存在——部分评论者以为 ZCode 是开源软件，事实并非如此。模型权重是开放的，但承载它的客户端不是。其卖点在于与 Z.ai 模型的第一方深度集成，这是任何第三方编辑器无法替代的。
消息在数小时内以中英文两种语言扩散。ferstar 的帖子浏览量突破 276,000，FeiZ 发布的中文提醒帖（"暂时停用 ZCode……现阶段应尽可能使用开源 Agent"）获得 63,800 次浏览。被引用最多的回复来自 Petri Kuittinen，他本人开源的 AI Agent 附带完整的安全文档："我的建议过去是、现在仍然是：不要信任闭源的 AI harness。"
关键在加密密钥
让"可疑的上传目录"坐实为一桩事件的，是加密方案本身。ZCode 采用信封加密：有效载荷先用对称密钥加密，该对称密钥再经 RSA-OAEP 公钥包裹。公钥由服务器在上传凭证协商阶段下发，对应的私钥只存在于 Z.ai 的云端。ferstar 尝试用本地系统上能找到的所有私钥解包该压缩包，全部失败。也就是说，用户自己磁盘上这份 313MB 的密文，用户本人和 ZCode 客户端都无法解密。
一把只有服务器能使用的密钥，其用途只有一个：确保服务器随时可以读取你的代码。
压缩包里有什么
打包清单以纯文本形式存储在本地，内容非常具体。以这份 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 加密，包裹对称密钥，随后将压缩包直接发送至阿里云 OSS，再由 OSS 回调 Z.ai 后端完成快照登记。测试期间，运行中的客户端与 zcode.z.ai 及两个阿里云 OSS 节点保持着持续连接。
设置开关拦不住它
用户的直觉是打开设置关闭相关功能。但逆向结果显示，界面上的两个开关与实际行为并不对应：
- "优化 Agent 体验"（optimizeAgentExperienceEnabled）：仅控制数据是否被授权用于模型训练。快照的捕获与上传照常进行。
- "仓库快照索引"（repoSnapshotIndexingEnabled）：仅控制服务器是否对上传的快照建索引。本地的打包与上传同样照常进行。
宿主组件在启动时无条件实例化捕获侧车进程，不检查任何用户偏好——唯一的启动条件是令牌提供方能生成有效的 JWT。会话日志显示，单个活跃会话触发了 62 次捕获事件，每个提示词和任务完成前都会触发。
第二份独立来源印证了这一机制。公开的 AI harness 提示词收集项目 OrcaPromptVault 收录了 ZCode 泄露的 131KB 系统提示和 31 个工具接口。检查点/回滚功能与系统提示中的"应用模板：工作区回滚，回滚 ID、检查点 ID、策略、恢复文件"字段相关联——这些字段共出现五次。这是快照管道面向用户的入口，也是文件系统锁所能禁用的功能。
该 Agent 的完整工具接口列表中没有任何快照、上传或遥测工具。也就是说，泄露管道并非 Agent 工具，而是在工具循环之外由宿主级侧车进程执行的。这就是为什么没有任何权限设置能够阻止它，也是为什么 Agent 自身从未感知到它的存在——系统提示中只字未提阿里云、OSS、上传或隐私。
捕获过程还揭示了一个 ferstar 未提及的细节：ZCode 提供一个 ReadSessionContext 工具，可按会话 ID 读取其他持久化的 ZCode 会话。结合宿主级快照侧车，会话内容既在本地持久化，也被同步捕获至云端。
隐私政策只字未提
ZCode 的隐私政策声明，该工具会收集用户在对话中提交的"文本、文件和代码"——这属于 AI 编程工具的常规上下文披露。但 ferstar 在隐私政策、常见问题与更新日志中均未找到任何关于打包并上传整个工作区及 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 小时内浏览量突破 276,000；V2EX 和 Hacker News 上的讨论主要沿一条界线分裂：Agent 在工具调用时按约定上传代码片段属于常态，且经过用户同意；而本案是未经同意地上传完整代码仓库及其全部历史，并加密至只有供应商可读取。
有效的缓解手段
删除待上传的压缩包没有效果：客户端会在半小时内重新打包一份全新的 313MB 压缩包，重试计数继续增加。可行的修复需要在文件系统层面实施，在内核级别让检查点目录不可写：
Linux：
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints
macOS：
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints
代价是：检查点回滚界面将停止工作——这首先是一个依赖上传代码才能实现的功能。聊天、自动补全与工具调用均不受影响。如需恢复，使用 chattr -i 或 chflags nouchg 即可。
这意味着什么
"在本地运行开放权重模型"一直是本地 AI 社区的核心理念：模型归你，硬件归你，没有按 token 计费的账单，也不受供应商关停影响。ZCode 事件表明，这条信任链在模型层之上就被突破了。围绕模型的运行时——工具带、桌面应用、更新管道——同样是信任面的一部分；一个裹在云工具带里运行的本地模型，并不算真正的本地。
问题也不限于 ZCode：任何 AI Agent harness，登录之后会传输什么、存储的内容谁能解密，都值得审视。本站持续跟踪主流 Agent harness 及其遥测行为正是出于这一原因。如果 Z.ai 随后发布修复、披露变更或官方声明，本文将予以更新。
资料来源
- 《Inside ZCode: Silently Uploading Your Entire Git History to the Cloud》— ferstar，2026 年 9 月 18 日（完整取证：asar 逆向、加密流程、开关失效证据）
- ferstar 首发帖子（X）— 总结线程，276K 次浏览
- FeiZ 中文提醒帖（X）— 63.8K 次浏览
- ZCode 发布页与更新日志 — Z.ai 官方
- V2EX 讨论帖 — 中文社区反应
- 本站此前的相关报道
