博主 Ferstar 在其博客发文称，ZCode在用户登录状态下，会于后台静默将本地工作区打包上传。
作者称，自己在排查磁盘占用时，在 ~/.zcode/v2/checkpoints 目录下发现一个 313MB 的加密压缩包，对应的状态文件显示该文件已连续上传失败 564 次，始终卡在本地待传队列中，涉及的是本地一个总大小约 10GB 的商业项目。
根据文章描述，该压缩包的生成逻辑是客户端会扫描当前打开的项目目录，排除 node_modules 等少量目录后，将剩余约 345MB 内容整体打包，标记为全量照baseline，再加密上传。
作者通过逆向客户端安装包中的 app.asar 还原了完整上传链路。
客户端先向 zcode.z.ai 请求上传凭证，服务端返回阿里云 OSS 的表单签名、动态生成的存储路径，以及一枚用于加密的 RSA 公钥。
随后客户端在本地对压缩包进行 AES-256-CTR 加密，并用该公钥以 RSA-OAEP-SHA256 方式包裹对称密钥，最终通过表单直传方式将密文发送至阿里云 OSS，全程不经过智谱自身业务服务器。
文章强调，用于解密的 RSA 私钥仅保存在服务端，本地生成的密文既无法被用户自己解开，客户端本体同样无法解密。
对于快照具体包含的内容，作者依据本地留存的文件清单进行了统计。
其中 Git LFS 缓存约占 56.8%，Git 对象库约占 29.6%，reflog 记录约占 0.2%，三项合计占比达 86.6%，其余约 13.4% 为源码及配置文件。
快照会附带一份跨工作区的全局配置清单及其哈希值一并上传。
该机制不受客户端设置中"优化体验"与"仓库快照索引"两个开关控制。
前者仅影响数据是否用于模型训练，后者仅影响服务端是否为快照建立索引，关闭两者均不影响本地打包与上传行为。触发时机包括每次提交提示词之前，以及任务结束时，单个活跃会话中最多可触发 62 次。
ZCode 现行隐私政策中未提及此项工作区打包上传机制。
针对防御方式，作者建议直接删除并重建 ~/.zcode/v2/checkpoints 目录，再通过 macOS 的 chflags uchg 或 Linux 的 chattr +i 命令为该目录加不可变锁，从文件系统层面阻止写入。
我使用本地的 Grok abuild 将文章全量复制到提示词中检查也发现相应的待上传加密内容。
如果你现在正在使用zcode，建议按作者的建议进行操作，不过这样会导致 ZCode 的检查点回滚与时间线功能失效，代码补全、对话等日常功能不受影响。
