你只是登录了一下，它搬走了你整套 Git 历史
SNAPSHOT UPLOAD · 2026.09.18
有人在清磁盘时发现 ~/.zcode 占了 700 多 MB，一路挖到 v2/checkpoints/ 下一个 313MB 的 .enc 文件。旁边那份状态元数据，把整件事说得很清楚。
EVIDENCE · 本地状态元数据
// ~/.zcode/v2/checkpoints/ 状态文件
"kind": "baseline" ← 全量快照
"workspaceSizeBytes": 345549173
"encryptedSizeBytes": 313070842
"failureCount": 564 ← 已失败重试 564 次
那个仓库总共 10GB，剔掉依赖后剩下的 345MB，几乎全是核心资产。而这份包已经上传失败 564 次，还躺在 pending/ 里等下一次重试。
传到哪去了 · 还原链路
钥匙在谁手里
教科书式的信封加密：内容走 AES-256-CTR，对称密钥再用服务端下发的公钥做 RSA-OAEP-SHA256 包裹。问题是——私钥从头到尾不在你机器上。作者试遍本机所有私钥都没能解开。
如果这真是给你做回滚或跨设备同步的，钥匙理应留在本地，像 Git 和 Time Machine 那样。一把只有服务端能用的钥匙，只有一个用途：确保服务端随时能读你的代码。
— ferstar · 逆向分析报告 · 2026.09.18
装了什么 · 42411 个文件
云端拿到的不只是当前工作树，是仓库从建库至今的全部血脉：后被删掉的历史密钥与敏感配置、未推送的分支名（等于未发布的功能计划）、.git/config 里写死的内网 GitLab 域名和仓库路径。
两个开关，都管不了它
翻 host 装配代码就明白了：捕获与上传的 sidecar 在启动时无条件实例化，没有任何基于用户偏好的判断分支，唯一门槛是能拿到登录 JWT。触发点是每次发提示词前的 captureBeforePrompt，以及任务结束时的 repo-wiki-update——单个活跃会话出现过 62 次捕获。
而隐私政策通篇只写收集「对话中提交的文本、文件与代码」。FAQ 和更新日志里，一次都没提过打包整个工作区和完整 Git 历史。
删了没用 · 得锁
作者第一次直接删了 pending 包，半小时后它又抓了一份新的，重试计数从 564 跳到 565。上传器发现文件没了，就再打一个。有效办法是在文件系统层加锁：
# macOS —— 内核级拒绝写入，上传链路无产物可发
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints
# Linux
sudo chattr +i ~/.zcode/v2/checkpoints
# 恢复：chflags nouchg / sudo chattr -i
代价是检查点回滚、时间线界面失效；对话、补全与工具执行不受影响。
推理需要上下文，这大家都接受。
真正越界的是两件事：数据范围和架构姿态。
工具不让你关，就让操作系统内核把它关进笼子。
※ 本文基于开发者 ferstar 于 2026 年 9 月 18 日发布的逆向分析报告整理（blog.ferstar.org），相关行为以智谱官方正式说明为准；如涉侵权请联系删除。
