智谱 ZCode，你打包上传我的代码仓库干什么？
内容提要
智谱ZCode被曝静默打包用户工作区并上传至阿里云OSS，快照包含完整.git历史，.git字节占比超九成，密钥过滤对Git历史无效。加密公钥由服务端提供，本地无解密密钥，设置中的“仓库快照索引”开关形同虚设，采集由服务端决定。作者已停用ZCode，建议清理密文、轮换凭据并锁死checkpoints目录。
延伸解读
快照范围为何远超必要
文章指出，ZCode 的快照机制并非只采集当前任务相关文件，而是打包整个工作区，包括完整的 .git 历史。在作者检查的案例中，.git 字节占比高达 93.9% 和 98.5%。这意味着即使你已从工作区删除敏感文件，只要它们曾进入 Git 历史，就会随 .git/objects 原样上传。这种设计让数据采集范围远超推理所需，也放大了凭据泄露的风险。
加密不等于用户可控
虽然快照经过 AES 加密和 RSA 封装，但解密私钥由服务端持有，本地没有用户可独立恢复的密钥。作者认为，如果功能真是用于回滚或同步，密钥理应在用户手中。加密只保护了传输和存储，却未赋予用户对数据的控制权。这种“信封加密”在缺乏用户密钥的情况下，更像是一种采集而非备份。
设置开关形同虚设
文章发现，设置中的“仓库快照索引”开关在日志中始终为 false，但快照仍被创建。代码分析显示，该字段并未接入采集路径，采集入口仅依赖 sidecar 实例，且该实例无条件构造。决定权实际在服务端：客户端每次 prompt 都申请上传凭证，服务端发就采。用户无法通过本地设置真正关闭上传。
用户可采取的应对措施
作者建议，若仍在使用 ZCode，可清理 ~/.zcode/v2/checkpoints/*/pending/ 下的密文，并检查 manifests/ 明文清单了解哪些文件被包含。历史中出现过的凭据应全部轮换，因为密钥过滤仅基于文件名，对 Git 历史无效。要彻底阻断，可用 chflags 或 chattr 锁死 checkpoints 目录，代价是回滚功能不可用。
Q&A
ZCode 被曝出静默上传用户代码仓库，具体上传了什么内容？
ZCode 会静默打包用户工作区快照，包含完整的 .git 历史，加密后上传至阿里云 OSS。快照中 .git 字节占比极高，例如 silo 仓库达 93.9%，mc 仓库达 98.5%。
ZCode 的加密上传机制是怎样的？用户能解密自己的数据吗？
文件经压缩和 AES 加密，对称密钥再由 RSA 公钥封装。加密公钥由服务端提供，本地没有用户持有的解密密钥，只有服务端能解密。
ZCode 设置里的“仓库快照索引”开关能关闭上传吗？
不能。该开关在采集路径上无效，日志中始终为 false，但快照仍被创建。采集由服务端决定，客户端每次 prompt 都无条件申请上传凭证，本地没有开关能否决。
ZCode 的密钥过滤能防止私钥泄露吗？
不能。密钥过滤只按文件名后缀判断，且 .git 放行排在所有排除规则之前，对 Git 历史无效。任何曾提交进 Git 历史的凭据，即使已删除或重写历史，也会随 .git/objects 原样上传。
如果还在使用 ZCode，应该采取哪些紧急措施？
清掉 ~/.zcode/v2/checkpoints/*/pending/ 下的密文；查看 manifests/ 明文清单确认哪些文件进了包；轮换历史中出现过的所有凭据；用 chflags uchg（macOS）或 chattr +i（Linux）锁死 checkpoints 目录以彻底阻断。
ZCode 的行为与隐私政策描述一致吗？
不一致。隐私政策收集范围限定为“通过对话提交”的文本、文件与代码，而后台快照并非通过对话提交，不在条款描述范围内。
类似 ZCode 静默上传的事件之前发生过吗？
有先例。2026 年 7 月，安全研究者发现 xAI 的 Grok Build 命令行即使提示词要求不读文件，仍将整个仓库打成 git bundle 上传至 Google Cloud Storage，关闭“改进模型”开关无效。事后 xAI 在服务端关停上传并增加退出选项。
