中国开发者 Ferstar 周五在检查 ZCode 本地目录时发现，一个 313MB 的加密归档文件正准备发送至阿里云存储，该上传任务此前已失败 564 次，而另一个较小文件已成功发送。据媒体报道，该归档文件包含 Ferstar 正在开发的商业项目快照及其 Git 历史记录。
用户无法解密，上传默认开启
这一细节将该事件与普通隐私投诉区分开来。Ferstar 表示，由于私钥存储在 Z.ai 后端，他和 ZCode 客户端均无法解密该归档文件。他指出，上传功能默认开启且无关闭按钮。另一位博主 Feng Ruohang 周五也证实，观察到至少三个文件的上传行为。
截至周日，阿里巴巴方面未就此事回应评论请求。
Git 历史泄露深层安全隐患
问题的核心并非数据量大小，而是仓库 Git 目录保存了自项目启动以来的每一次变更。已被提交但随后撤销的凭证、废弃分支、内部主机名及意外暴露的提交信息均保留在历史记录中。
这凸显了编码代理比聊天机器人更严峻的安全挑战。工具被信任的范围与其可审计范围之间存在差距，已成为行业固有弱点。此前，研究人员仅通过要求 Claude Code 总结网页便成功实施了劫持。
官方致歉称“特性”而非“故障”
Z.ai 周五在官方飞书社区道歉并宣称问题已解决。声明指出，问题源于支持会话断点恢复、版本回滚和 Repo Wiki 的代码库索引功能。在云端生成 Wiki 页面可能触发代码库上传，且该功能在发布后默认开启。
这种对“产品特性”而非“系统故障”的描述，决定了用户追问的方向：漏洞可以被修补，而默认设置则是人为决策的结果。
数据销毁说法难以独立验证
Z.ai 表示，一旦 Wiki 页面生成，上传数据会立即销毁且不予保留。Ferstar 周六质疑该说法的可验证性。由于 Z.ai 构建了仅其自身可读取的加密归档，只有 Z.ai 能报告数据的最终命运，第三方无法独立核实。
隐私政策存在盲区
查阅 ZCode 于 6 月 15 日生效且未修改的隐私政策发现，服务仅收集通过对话提交的文本、文件和代码。包含代码库及历史的打包快照不属于用户主动提交内容，政策的权限表也未提及代码库快照功能。
政策中唯一的控制选项“优化计划”默认关闭，仅规定内容是否用于训练，而非是否传输。这意味着，即便开发者未更改训练开关，也无理由预期代码库会被上传。
对比 xAI：可验证的修复才是关键
Grok Build 曾将完整 Git 代码库上传至 xAI 服务器，尽管其营销声称会话期间不传输代码。在中国开发者对比指出后，埃隆·马斯克确认了上传行为，xAI 删除了用户数据，记录了零保留政策并添加了隐私端点。随后的重新测试证实上传已停止，将声明转化为事实。相比之下，Z.ai 尚未提供同等程度的验证。
开放权重与封闭客户端的矛盾
Z.ai 凭借免费开源模型建立了声誉，年销售额接近 10 亿美元，付费产品主要围绕这些模型构建软件生态。但这暴露了其结构性矛盾：模型权重是可审查的，而在本地磁盘读取数据的客户端却处于黑盒状态。
创始人唐杰认为安全性来自广泛参与和监督，而非技术壁垒。然而，这一论点未能涵盖安装在开发者机器上的软件组件安全。
信任代价已然显现
一家领先中国机器人公司的软件工程师透露，出于安全考虑，雇主已在内部禁止使用 Z.ai 工具。上海开发者 Tuxi 指出，损害将落在社区信任上，而非模型本身。由于 GLM 运行在包括 OpenAI Codex 在内的多种编码工具中，用户可以在保留模型的同时弃用特定客户端。
后续关注重点
首先，关注开源范围是否涵盖上传组件。Z.ai 承诺发布 ZCode 代码库并邀请第三方评估，关键在于包含工作区打包功能的组件是否在开源范围内。
其次，关注重新测试结果。外部人员在同一客户端上确认上传停止，比任何声明都更具说服力。
最后，关注隐私政策更新。目前政策仍仅描述通过对话提交的文件，自周五以来尚未进行修改。