2026 年 9 月 18 日，一位名为 ferstar 的开发者发布了对 ZCode 的逆向分析结果。ZCode 是智谱 AI（Z.ai）推出的桌面端 AI 编程应用，围绕其 GLM 系列模型提供服务。调查显示，当用户处于登录状态时，该应用会在后台将整个工作区打包并加密上传至阿里云 OSS，内容包括完整的 Git 历史、LFS 缓存、reflog 以及全局配置等敏感信息。这一发现迅速引发了开发者社区对本地 Agent 权限边界的广泛讨论。
上传机制绕过用户设置
根据 ferstar 的拆解，ZCode 客户端在启动时会无条件加载一个负责快照上传的 sidecar 模块，只要 JWT token 有效，就会触发上传流程，与用户在设置界面中的选项无关。日志显示，在一次会话中共记录了 62 次快照行为，时间点集中在每次提示词发送前与任务完成后。
上传流程如下：客户端向 zcode.z.ai 请求上传凭证，获得 OSS 表单签名、对象键、大小限制以及本轮使用的 RSA 公钥；随后将工作区压缩为 tar.gz，并使用 AES-256-CTR 对内容进行加密，对称密钥再由服务器下发的 RSA 公钥包裹，最终上传至阿里云 OSS，并通过回调通知 Z.ai 后端。
在一次实测中，一个约 345MB 的商业项目被打包为 313MB 的加密文件，共包含 42,411 个文件，其中仅 .git 目录就占了整个加密包的 86.6%。这意味着上传的不仅是当前打开的代码文件，而是整个仓库从创建以来的完整演变记录。
Git 历史为何比代码本身更敏感
很多开发者误以为只要不上传当前文件，就不会泄露核心信息。但 Git 对象库实际上保存了项目从第一天起的所有变更记录，包括被后续提交删除的 API 密钥、未推送的分支名称、内部主机地址与仓库路径等。这些信息往往隐藏在公司内部工程历史的深处，却可能因一次静默上传而暴露。
更令人担忧的是，ZCode 使用了一种“信封加密”机制：数据由对称密钥加密，而该密钥又由服务器端掌握的 RSA 公钥加密。这意味着即使文件保存在本地磁盘，用户和客户端本身也无法解密。正如分析者指出：“只有服务器能使用的密钥，唯一的作用就是确保服务器随时可以读取你的代码。”
开源模型不等于开源工具链
ZCode 所属的 Z.ai 是 GLM 系列开源模型的发布方，这也导致不少用户误以为 ZCode 本身也是开源产品。事实上，模型权重是开放的，但 ZCode 作为调用这些模型的运行时环境，属于闭源商业软件。这种混淆在事件发酵后表现得尤为明显。
相关帖子在发布当天即获得超过 27.6 万次浏览，中文开发者圈也迅速跟进。用户 FeiZ 提醒：“建议暂时停用 ZCode……尽可能使用开源 Agent。”另一位开发者 Petri Kuittinen 则直言：“我的建议过去是、将来也是：不要信任闭源 AI 工具链。”
另有公开资料显示，ZCode 的系统提示词中包含了用于“工作区回滚”的模板字段，如 “Workspace rewind applied. rewindId, checkpointId, strategy, restoredFiles”，这被认为是该快照机制在前端功能上的体现。然而在其列出的 31 个可用工具中，并无任何与快照、上传或遥测相关的接口，说明相关行为发生在 Agent 工具循环之外，属于宿主层面的操作。
官方文档未披露完整上传行为
ZCode 的隐私政策声明该工具会收集“对话中提交的文本、文件与代码”，这是多数 AI 编程工具都会说明的标准推断上下文。但经过比对，ferstar 并未在隐私政策、FAQ 或更新日志中发现有关“打包并上传整个工作区与 Git 历史”的明确说明，最接近的表述仅涉及默认关闭的“优化计划”。
ZCode 于 2026 年 7 月上线，其发布时曾以“可信开发环境”为卖点，与 Anthropic 的 Claude Code 展开对比。如今看来，其在权限控制与透明度方面仍有待完善。
开发者应如何应对
- 审查正在使用的 AI 编程工具是否具备网络上传能力，尤其是涉及 Git 目录访问权限；
- 避免在登录状态下使用闭源 Agent 处理包含敏感历史的项目；
- 优先选择具备清晰权限模型与开源审计能力的工具链；
- 定期清理本地 Git 缓存与 reflog，减少潜在泄露面；
- 对任何要求完整仓库访问权限的应用保持警惕。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/zcode-bei-pu-zai-deng-lu-zhuang-tai-xia-da-bao-shang-chuan
