副标题：ZCode被指打包整个仓库，我没装它，却在自己的仓库里查出一把躺了三个月的密钥

在这里，文章既写给你看，也写给你的 Agent。

我是 Jimiro，专注「用 AI 学 AI」。看完文章，你带走判断逻辑，AI 拿走可执行指令。

关注公众号「Jimiro」，成为真正能指挥智能体的实战派。

一、真实现场与核心判断

上周五晚上我刷到一条消息：一个 AI 编程工具，在你敲下回车之前，已经把整个代码仓库打包好了。

那个工具是智谱的 ZCode。我这台机器没装过它。

但我还是去查了自己这台。

先说事实。9 月 18 日，ferstar 和 vonng 两位作者各发一篇独立分析，检查版本是 ZCode 3.12.3。他们在本机 ~/.zcode/v2/checkpoints/ 下看到多份工作区快照，229MB 到 1.53GB。按作者观察，快照里带着 .git 目录，占体积 86.6% 到 93.9%——整段版本历史。

vonng 的原话是：「我反对的是不告诉我就拿走、全部拿走、而且不给我关掉的开关。」他说电脑上没有任何开关能否决这件事，是服务端决定什么时候采集。

再说边界，这条不能省。两位作者确认服务端成功收下的，只有小仓库。那个 313MB 的商业项目快照，因超体积限制失败 564 次，一直卡在本地。

所以「打包了」是确定的，「传出去了」要看仓库大小和运气。

智谱 9 月 18 日在官方社群回应（媒体转述，非官方原文）：是「代码库索引」功能所致，上线初期默认开启，影响了部分用户，已修复，将开源并邀请第三方审查。vonng 则认为上传发生在每次提问前，和这个功能无关。官方也没回应上传范围。这个冲突，我不替任何一方下结论。

9 月 20 日，太原承明科技发函，主张被传走的含数据库口令和云凭证（据 21 世纪经济报道）。这是一方主张，不是定论。

vonng 还有一句我记住了：私钥哪怕早就 git rm，甚至用 filter-repo 重写过历史，仍会躺在 .git/objects 里被一起打包。

ferstar 的结论更直白：「工具是工具，但用户得自己画边界。如果软件不让你关掉它，就用操作系统内核把它锁进笼子里。」

所以我先去画自己的边界。查了三样。

家目录里 AI 客户端的数据目录：.ollama 29G、.hermes 15G、.codex 12G、.gemini 2.2G、.workbuddy 2.0G、.claude 562M、.codebuddy 396M。体积大不等于在打包，但我第一次有了一份基线。

正在跑的进程里，两个的启动参数是 claude --dangerously-skip-permissions 和 codex --dangerously-bypass-approvals-and-sandbox。名字里就带 dangerously——为了少点几次确认，我亲手加的。翻译一下——「该不该问我」这个开关，是我自己拧掉的。

最后是 ~/projects/715-os：backups/2026-06-21-pre-vault-adjustment/hermes/.env 在 8 月 12 日首次提交时就进了版本库，到今天 40 天，还在 HEAD 里。字段有 DEEPSEEK_API_KEY、WEIXIN_TOKEN、FEISHU_APP_SECRET。我明天删掉这个文件，历史里也还在——任何会打包 .git 的工具，都拿得到。

对照组 wecom-group-autopush/.env 没进库，.gitignore 第 1 行就写着 .env。这个做对了。

这两件事都和 ZCode 无关。工具换了，问题还在原地。

不是 AI 偷走了你的代码，是你的密钥在仓库历史里躺了 40 天，而没有任何一份清单告诉你它可能被带走。

二、跑通这 3 步

第一步，查有什么输不起。在仓库根目录跑：

git log --all --diff-filter=A --name-only --pretty=format: | grep -Ei '(^|/)(\.env[^/]*|.*\.pem|.*\.key|id_rsa.*)$' | sort -u

列出来的，都是进过历史的文件。.env.example 这类只是模板，要人工看一眼。多个仓库就逐个跑，或者直接用下面的胶囊。

第二步，查谁在打包。du -sh ~/.codex ~/.claude ~/.gemini 量一遍，记下数字，下周再量。一次看不出异常，要看的是增长。再跑 ps -Ao command | grep -i dangerously，看看你自己有没有亲手拧掉哪个开关。

第三步，进过历史的密钥，按泄露处理。不是删文件——去平台把那把 key 作废重发，这是唯一真正有效的动作。作废前先确认这把 key 还有谁在用，别把自己的自动化一起停了。然后补 .gitignore，装一个 gitleaks 之类的 pre-commit 检查。这一步我今天也得自己走一遍。

三、Agent 投喂胶囊（直接丢给 AI 开工）

说明：复制下方指令，发给你的 AI 助手（Claude / Codex / DeepSeek / GPT 都行）：

角色

你是一个熟悉 Git 的安全审计助手。

任务

扫描我指定的项目目录，找出曾经进入 git 历史的密钥类文件，输出清单和处置建议。

前置输入

• 项目目录：[填路径]

约束

1. 只报告字段名，不打印字段值
2. 不要替我做 git 历史重写
3. 不确定的标「需人工确认」

输出格式

表格：文件路径 | 首次进入的提交 | 字段名 | 是否仍在 HEAD | 处置（作废重发 / 仅改 gitignore 不够）

四、新手最容易踩的坑

以为 git rm 之后就干净了。

因为 Git 里的「删除」本身也是一次提交，旧版本一直都在。你重写历史，也追不回已经被拷走的那份。

第二个坑是只补 .gitignore。它只管以后，管不了已经进去的。

顺序是：先作废，再清理，最后才是防再犯。

写在最后

工具会一直换。但「它能带走什么」这件事，第一次有人被追问了。下一个工具装上之前，你知道自己有什么输不起吗？

这篇转给那个把 .env 丢在项目目录里的朋友，或者正在用 AI 编程工具的人。

说句真话：你上一次查自己仓库的历史，是什么时候？评论区聊聊。

想跟同样在用 AI 学 AI 的人交流，图卡3二维码扫码进「AI学AI实战局」。

本文部分内容由人工智能生成合成，已按相关规定进行标识。文中数据与说法均标注来源，第三方转述不代表官方口径，请以官方公开信息为准。

参考链接：

ferstar《ZCode Silent Workspace Snapshot Upload》逆向分析（2026-09-18）

blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/

vonng《Zhipu, Why Is ZCode Packaging and Uploading My Repositories?》（2026-09-18）

blog.vonng.com/en/ai/zcode-upload/

21 世纪经济报道：太原承明科技发函智谱（2026-09-20）

www.21jingji.com/article/20260920/herald/33c035e727adca7abeb569355f534454.html

IT时代网转述智谱官方社群回应（2026-09-18）

news.qq.com/rain/a/20260918A0AQLJ00