开发者 ferstar 在 2026 年 9 月 18 日发布的逆向分析显示，智谱旗下 AI 编程桌面端 ZCode 在登录状态下会静默打包整个工作区——包括完整 .git 历史、LFS 缓存、reflog 与全局配置——用服务端下发的 RSA 公钥加密后直传阿里云 OSS，单次产出 313MB、42,411 个文件的加密包，私钥仅 Z.ai 持有，UI 开关全部失效。智谱当日致歉并承诺修复、开源，但已外送的代码资产能否真正销毁尚无技术层面交代。
313MB 加密包，连用户自己都打不开
登录之后到底发生了什么？客户端在后台把整个工作区打包上传，而唯一能解开它的钥匙，不在你手里。
2026 年 9 月 18 日，研究者 ferstar 发布了对 ZCode 的逆向分析。ZCode 是 Z.ai 出品的 AI 编程桌面客户端，Z.ai 正是 GLM 系列开源模型的母公司。
用户登录后，客户端在后台把整个工作区——完整 .git 历史、LFS 大文件缓存、reflog、全局应用配置——打包成 tar.gz，用 AES-256-CTR 加密，POST 到阿里云 OSS。
ferstar 抓包得到一个 313MB 的加密归档，来源是 345MB、42,411 个文件的商用工作区，期间记下 564 次失败的上传尝试。同一份分析里他给出一张 payload 拆解表：.git/lfs 196.1MB、.git/objects 102.2MB、.git/logs 0.6MB、源码和文档 46.2MB，整个 .git 目录占了 86.6%。
加密走的是信封式：载荷用对称密钥加密，对称密钥再用服务端下发的 RSA-OAEP 公钥（一种非对称加密算法，常用于密钥包裹）包一层。ferstar 试了本机所有本地私钥，全部失败。私钥只存在 Z.ai 那一边。他说得直白：“服务器独占的密钥只有一个作用——确保它想读你的代码时随时能读。”
UI 里不是没开关。设置里能看到「Optimize Experience」和「Repo Snapshot Indexing」两个选项，但 ferstar 比对代码后发现，前者只决定数据能否拿去训练模型，后者只决定上传后是否被服务器索引——抓取和上传本身不受这两个开关控制。宿主侧的 sidecar（随主程序一起跑的辅助进程）启动时无条件实例化，唯一门槛是拿到一个有效 JWT（登录态令牌）。
Z.ai 当晚在官方社群承认数据被上传，解释是「代码库索引」功能，生成 wiki 页面后销毁，初期默认开启已修复，并宣布近期开源 ZCode 仓库、邀请第三方审查，同时补偿一次免费周额度重置。
开关全在，但按的全是错地方
出事之后第一反应是去设置里找开关。问题是，关错了——ZCode 的抓包不归设置管，它在更底层的宿主进程里。
「Optimize Experience」名字像在管「能不能用你数据训练模型」，也确实只管这一件。抓包照常。「Repo Snapshot Indexing」听起来更对路——仓库快照索引，像管上传的？也不全是。
这个开关只控制云端要不要给上传过的快照建索引，方便后续搜索。客户端该打包还是打包，该传还是传。这两个开关跟「要不要把代码送出去」没关系。
会话日志里的数字更直接：单次活跃会话触发 62 次抓取，每个 prompt 之前各一次，任务结束再来一次。抓取模块挂在宿主进程上，启动时无条件实例化——没有「先问用户同不同意」这步，唯一前置条件是 token provider 能签出合法 JWT（登录后服务端发的一次性身份令牌，相当于临时通行证），也就是你登录了。
AI 代理自己也不知道这事在发生。OrcaPromptVault 抓到 ZCode 那 131KB 的系统提示和 31 个工具清单，没有一个跟「上传」或「遥测」沾边。代理在它自己的世界里干活，对背后偷偷打包一无所知。
还有一刀：ZCode 内置一个 ReadSessionContext 工具，能按 session ID 读本地别的会话内容。快照把会话信息送上云端，这个工具能跨会话读——本地存一份，云端也存一份。
两个月前发生过一样的版本——xAI 的 Grok Build 走的是「关掉训练开关、仓库照样打包传 GCS（Google Cloud Storage，谷歌云的对象存储服务）」的套路。当时 5.1GB 上传量，模型真正用到的只有 192KB，差出近两万八千倍。两次事件形状几乎一致：UI 看起来给你控制权，控制的是另一件事。这套机制怎么转、为什么「关开关」救不了你、用户怎么自保——下一节讲。