ZCode疑似后台上传项目代码？一次完整排查记录

ZCode疑似后台上传项目代码？一次完整排查记录

SEO关键词： ZCode、智谱ZCode、ZCode代码上传、ZCode隐私、AI编程工具、Git历史、项目代码安全、ZCode checkpoints

文章摘要：
最近看到一篇针对智谱 ZCode 的深度排查文章，作者从本地磁盘占用、程序日志、app.asar 代码以及网络请求等多个角度进行了分析。文章声称 ZCode 会在登录状态下创建项目快照，并将加密后的快照上传到阿里云 OSS。本文整理这次调查中的关键证据和防护方法，方便使用 ZCode 的开发者了解相关机制。

一、事情是怎么发现的？

作者最开始只是清理磁盘空间，却发现用户目录下的：

~/.zcode

占用了 700MB 以上。

进一步检查后发现，其中：

cli/              ≈257MB
computer-use/     ≈130MB
v2/checkpoints/   ≈303MB

其中 v2/checkpoints/ 最值得关注。

目录里存在一个超过 300MB 的加密文件，同时还有对应的状态信息。

例如：

{
  "workspacePath": "/Users/ferstar/myprojects/<a commercial project>",
  "lastCompressedSize": {
    "encryptedSizeBytes": 313070842,
    "workspaceSizeBytes": 345549173
  },
  "kind": "baseline",
  "failureCount": 564
}

从字段来看，这个文件对应一个项目 Workspace 的快照，原始数据约 345MB，加密后约 313MB。

作者还发现此前已经存在 564 次上传失败记录。

需要强调的是：这些属于原作者对自己设备上的 ZCode 行为进行的调查，并不等同于已经获得官方确认。

二、ZCode到底上传了什么？

作者继续对 ZCode 的 app.asar 进行逆向分析，并还原出了大致的数据流程：

ZCode
  ↓
请求 Snapshot 上传凭证
  ↓
服务器返回 OSS 签名 + RSA 公钥
  ↓
本地打包项目
  ↓
tar.gz
  ↓
AES-256-CTR 加密
  ↓
RSA-OAEP 包装密钥
  ↓
上传 .tar.gz.enc
  ↓
Aliyun OSS

调查结果显示，客户端首先向 zcode.z.ai 请求上传凭证。

服务器会返回 OSS 表单签名、Object Key、大小限制以及本轮使用的 RSA 公钥。

之后客户端在本地完成压缩和加密，再通过 HTTP POST 将加密后的文件直接上传到阿里云 OSS。

也就是说，从作者还原出的流程来看，ZCode 的项目快照并不是简单保存在本地，而是存在向云端上传的流程。

三、最值得关注的是加密密钥

调查中发现，ZCode 使用的是典型的信封加密思路：

keyId: String(i.encryption.key_version),
keyWrapAlgorithm: "rsa-oaep-sha256",
publicKeySpkiPem: Ylt(i.encryption.public_key)

具体来说：

• 项目内容使用临时 AES-256-CTR 密钥加密；
• AES 密钥再通过服务器提供的 RSA 公钥进行 RSA-OAEP-SHA256 封装；
• 对应 RSA 私钥并没有出现在用户设备上。

因此，作者认为本地生成的 .enc 文件无法直接由用户解密。

这一点本身并不能证明服务器会如何使用数据，但确实说明：如果私钥仅由服务端掌握，那么客户端本地并不拥有完整的解密能力。

四、更麻烦的是：可能不只是当前代码

调查中一个比较容易被忽略的问题，是项目快照可能包含 .git 目录。

作者对一个包含 42,411 个文件的快照进行了拆分：

内容	大小	占比
.git/lfs/	196.1 MB	56.8%
.git/objects/	102.2 MB	29.6%
.git/logs/	0.6 MB	0.2%
源代码及文档	≈46.2 MB	13.4%

按照这份样本计算，.git 目录占到了约 86.6%。

这意味着如果调查结果准确，那么需要关注的就不只是当前工作区代码，还可能包括 Git 历史、LFS 文件以及 reflog 等内容。

尤其是 Git 历史中可能存在已经删除的配置、旧 API Key、内部域名以及其他历史信息。

这些内容即使当前版本已经删除，也可能仍然存在于 Git 对象库中。

五、关闭设置真的有用吗？

作者还检查了 ZCode 中与数据相关的两个设置：

设置	表面作用	作者调查到的行为
Optimize Experience	控制数据用于模型训练的授权	不影响 Snapshot 捕获和上传
Repo Snapshot Indexing	控制服务端是否建立 Snapshot 索引	不影响本地打包和上传

根据作者对客户端代码的分析，Snapshot 相关组件会在启动时初始化，并没有发现由这些 UI 开关控制上传流程的逻辑。

同时，作者观察到 Snapshot 可能在 发送 Prompt 前以及任务完成后触发。

单次会话中，作者记录到最多出现 62 次 capture event。

六、如果担心项目代码，可以怎么处理？

作者尝试直接删除：

~/.zcode/v2/checkpoints

但发现之后又会重新生成新的 Snapshot。

因此给出的解决方案不是不断删除文件，而是直接从文件系统层面阻止目录写入。

macOS

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints

恢复：

chflags nouchg ~/.zcode/v2/checkpoints

Linux

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints

恢复：

sudo chattr -i ~/.zcode/v2/checkpoints

这种方式的原理比较简单：让程序无法向 checkpoints 目录写入快照文件。

代价也比较明显——依赖这些 Snapshot 的回滚、Timeline 等功能可能无法使用，而普通聊天、代码补全以及工具执行通常不依赖这个目录。

七、写在最后

这次调查真正值得开发者关注的，不只是一个 300MB 文件，而是 AI 编程工具到底会收集哪些项目数据。

正常的 AI 编程功能需要读取代码上下文，这是比较容易理解的。

但 Workspace Snapshot、Git 历史、LFS 文件等数据属于更大的数据范围。

如果你平时使用 AI 编程工具开发商业项目，尤其是涉及：

• 商业源代码
• API Key
• 内部接口
• 公司 Git 仓库
• 未发布功能
• 客户项目

建议不要只看产品宣传页面中的“代码补全”和“智能编程”，同时检查本地数据目录、网络请求、隐私政策以及数据上传机制。

本文整理的是原调查作者在特定环境下得到的结果，并非对 ZCode 官方行为的独立最终认定。 如果后续官方对 Snapshot 的用途、上传范围以及数据保留策略作出说明，还应该以官方信息为准。

对于 AI 编程工具来说，功能强大是一回事，代码去了哪里、保存多久、谁拥有解密能力，同样值得开发者关注。