导读2026 年 9 月 18 日，智谱旗下 AI 编程工具 ZCode 被开发者曝出在后台静默打包并上传本地工作区快照，其中 .git 历史字节占比高达 90% 以上。官方随后致歉并归因于代码库索引功能，承诺开源客户端与周额度补偿。本文基于多方技术取证与反编译分析，客观拆解其打包链路、过滤缺陷与开关失效机制，并为开发者提供切实可行的本地风险排查与目录权限加固指南。
本文 3137 字，阅读约 8 分钟｜313MB 密文卡在队列：一次意外曝光的后台上传 → 拆解取证链：ZCode 到底打包了什么？ → 三重设计隐患：为什么本地开关与过滤全线失效？ → 守住事实边界：已知事实、官方回应与未解疑问 → 开发者本地自救指南：排查、清理与权限加固 → 拥有整盘权限的桌面 Agent，应当守住怎样的底线？
313MB 密文卡在队列：一次意外曝光的后台上传
事情的起因带有一丝戏剧性。
2026 年 9 月 18 日，一位开发者在清理本地磁盘时，偶然发现 ~/.zcode 目录占用了异常巨大的存储空间。顺着目录层级排查，他在快照缓存文件夹中发现了一个体积高达 313MB 的加密文件。
伴随的记录文件显示，ZCode 扫描了本地一个商业项目，排除常规依赖后，把剩余 345MB 的工作区内容打包成了完整快照。因为当时的本地网络连接异常，该快照在后台连续重试上传了 564 次，一直卡在重试队列中。
正是这份因网络故障而未能成功上传的本地残留，让整条静默上传链路浮出水面。
图片说明：开发者排查时发现的 313MB 快照及 564 次重试记录 图片来源：科技每日推送
消息在社区传开后，多位工程师在 macOS 和 Linux 环境下对 ZCode 3.12.3 进行了独立取证与逆向分析，证实该行为在特定条件下确实存在。随后智谱官方在社群发布情况说明并致歉，确认了该机制的存在并给出了修复方案。
作为每天都在使用各类 AI 编程工具的工程师，我们不应只停留在情绪化的讨论上。搞清楚它到底传了什么、为什么会传、本地设置为何没能挡住，以及我们当下该如何加固自己的开发环境，才是更重要的事情。
拆解取证链：ZCode 到底打包了什么？
根据多方针对客户端代码的静态分析与本机文件审计，ZCode 在触发快照时的完整打包流程可以清晰还原：
当用户在客户端发送 prompt 或任务结束时，客户端会向服务端（zcode.z.ai）申请上传凭证。服务端返回上传大小限制、OSS 表单凭证以及用于加密的公钥。随后，客户端按照本地筛选规则扫描工作区，完成压缩、加密并上传至云端存储。
但争议的核心，在于这个快照的内容构成与加密方式。
图片说明：开发者本地取证显示四个工作区快照中包含全量 Git 记录 图片来源：老冯云数
1. 被打包的不是代码切片，而是全量 Git 族谱
在常规的 AI 辅助编程认知中，客户端为了辅助推理，通常只会提取当前编辑文件、光标上下文或相关引用符号。
但在 ZCode 生成的快照明文清单（manifest）中，.git 目录不仅没有被排除，反而占据了绝大部分体积。在已公开的取证样本中，部分仓库快照的 .git 字节占比高达 93.9% 甚至 98.5%。
这意味着被打包的内容包含了整个仓库自创建以来的全部 commit 历史、分支变更、大文件缓存、悬空对象（dangling objects），甚至是开发者此前使用 git filter-repo 等工具试图从历史中抹除的敏感记录。
2. 本地不可逆的非对称加密
快照在本地经过了压缩与 AES 对称加密，而用于解密 AES 密文的密钥，又被服务端下发的 RSA 公钥进行了封装。
这种信封加密设计在技术上很规范，但带来了一个致命问题：解密私钥仅保存在云端服务器，本地只有公钥。
这就意味着，即使开发者在自己的磁盘里找到了这几百兆的密文包，本地客户端和用户自己都无法解密查看里面具体包含了什么。用户失去了对自己本地数据的知情权与验证权。
三重设计隐患：为什么本地开关与过滤全线失效？
许多开发者会产生疑问：软件设置里明明有隐私开关，难道项目里的敏感凭证也会直接传上去吗？
从逆向代码来看，该机制在工程实现上存在三重严重的设计缺陷：
图片说明：~/.zcode 目录下的 manifests 明文清单与状态记录 图片来源：老冯云数
缺陷一：放行优先级高于安全过滤
ZCode 客户端确实内置了敏感信息过滤逻辑，配置了针对常见密钥文件（如 .pem、.key、.p12）的排除规则，同时也排除了全局的 OAuth token 与 credentials 配置文件。
然而在底层的条件判定链中，对 .git 目录的放行逻辑排在所有排除规则之前。
这就导致文件体积上限与密钥过滤器对 .git 内部的任何文件均不生效。任何曾经提交到 Git 历史、哪怕后续通过 git rm 删掉的文件，都会原封不动地随着 .git/objects 打包进快照。此外，对于非标准后缀（例如 .asc 格式的 PGP 公钥），由于未命中黑名单，也会被直接收录进清单。
缺陷二：设置界面的开关未接入采集主干
在 ZCode 的客户端设置中，提供有“仓库快照索引”等相关选项。但在 3.12.3 版本的 host 源码中，该配置项仅用于界面状态与字段迁移，并未在底层的数据采集路径上设置阻断校验。
实际采集入口的判定条件仅依赖 sidecar 实例是否存在，而该实例在客户端启动时是无条件初始化的。换句话说，客户端每次都会向服务端申请凭证，只要服务端返回了上传凭证，本地就会执行采集与上传，前端开关在代码层面上并未起到否决作用。
缺陷三：数据所有权与备份概念的倒置
数据备份的核心前提是“数据所有者能够随时恢复”。当一个工具以“仓库索引与会话回滚”为名打包本地数据，却将解密密钥完全收归云端、本地无法自查时，在工程定义上它就已经脱离了本地备份的范畴，变成了静默的数据采集。
守住事实边界：已知事实、官方回应与未解疑问
在技术复盘中，保持客观和严谨的证据边界尤为关键。我们需要明确区分哪些是已证实的事实，哪些是官方说明，哪些仍属未知：
图片说明：智谱官方在社群发布的情况说明与整改承诺 图片来源：智谱官方社群公告
1. 官方的回应与技术定性
事件发酵后，智谱官方在官方社群发布了致歉声明，对该机制进行了解释：
功能用途：该机制属于 ZCode 的“代码库索引”功能，用于支撑本地仓库索引、会话恢复、历史回退以及 Repo Wiki 代码知识库。
数据留存：官方表示 Repo Wiki 在云端生成知识库页面时会触发数据上传，但页面生成后相关数据会在云端立即销毁，不会留存，亦不用于模型训练。
失误原因：该功能上线初期默认开启，导致部分用户在未充分感知的情况下触发了上传。
整改措施：已在服务端修复默认开启策略；近期将正式开源 ZCode 客户端代码，引入第三方独立审查机构并公开进展；同时向受影响用户发放一次周额度重置补偿。
2. 证据的客观边界
上传不等于用于训练：目前的逆向取证能够完全证实客户端的打包、加密和上传动作，但外部黑盒无法直接观测服务端内部的处理流程与销毁日志。我们不能仅凭上传行为直接断言数据已被用于大模型训练。
核心私钥未泄露的真实原因：部分取证开发者未丢失重要私钥，是因为其私钥从未被提交到 Git 仓库，或者全局凭证刚好被粗粒度规则排除，而非该过滤机制本身设计得足够严密。
事实上，这类由于客户端过度采集导致的信任危机并非孤例。早在 2026 年 7 月，xAI 的 Grok Build 命令行工具就曾因为将整个仓库打包为 git bundle 上传至 Google Cloud Storage 而引发轩然大波，随后 xAI 紧急关停了上传并在服务端提供了退出选项。两个月后同类问题再次出现在国产头部工具中，反映出行业在追求 Agent 深度上下文时普遍存在的数据边界模糊问题。
开发者本地自救指南：排查、清理与权限加固
对于正在使用或曾经使用过 ZCode 的开发者，建议立即按以下步骤进行本地排查与环境加固：
第一步：排查本地进包清单（Manifests）
打开终端，检查本机快照目录下的清单文件，确认是否有核心商业项目或敏感仓库被扫描：
第二步：清理本地待上传的 Pending 密文
如果因为网络原因或体积超限，部分密文仍留在本地 pending 队列中，必须立即删除，防止服务端恢复下发凭证后自动断点续传：
第三步：敏感凭据全面轮换（Key Rotation）
如果被打包的仓库中曾经提交过 API Key、数据库密码、云厂商 AccessKey、私钥或 Token（哪怕后续已经通过 git rm 删除）：
必须立刻在对应云平台和第三方服务商处作废旧 Key，重新生成并替换；
不要寄希望于过滤器的黑名单拦截，.git 历史对象一旦离机，必须默认凭据已处于不可信状态。
第四步：使用文件系统属性锁死目录（物理防御）
如果仍需要使用该工具完成特定任务，但希望彻底切断本地快照打包链路，可以直接利用操作系统的文件不可变属性（Immutable Flag）锁死 checkpoints 目录：
macOS 环境：
Linux 环境：
注意：锁定该目录后，客户端将无法创建快照和写入缓存，本地的会话回滚与仓库 Wiki 生成功能将不可用，但不影响基础的对话与代码生成。若后续需要恢复目录写入权限，macOS 可执行
chflags nouchg ~/.zcode/v2/checkpoints，Linux 可执行sudo chattr -i ~/.zcode/v2/checkpoints。
拥有整盘权限的桌面 Agent，应当守住怎样的底线？
在 AI 辅助编程从单纯的“聊天补全”进化到“全自主 Agent”的今天，运行在开发者电脑上的桌面客户端不再是一个受限的沙盒网页，而是一个常驻后台、拥有全盘读写权限、具备网络访问能力的超级进程。
在这样的背景下，衡量一个 AI 开发工具是否值得信赖，必须回到最朴素的三个工程原则：
1.
最小必要原则：推理需要哪些上下文，就精准读取哪些切片。把整个 .git 族谱打包带走，无论以任何功能为名，都已经远远超出了最小必要的范围。
2. 所有权对等原则：既然是为用户本地服务的索引与回滚，解密密钥就必须保存在用户本地。用户解不开的加密包，在逻辑上就是采集。
3. 明确且可否决的控制权：敏感操作必须有清晰的前置授权弹窗，设置中的禁用开关必须能在代码底层真正切断逻辑分支，而不是仅作展示。
智谱官方在此次事件中快速致歉、承诺开源客户端并引入第三方审查，展现了积极解决问题的态度。但代码和凭据是软件工程的生命线，开发者的信任一旦产生裂痕，修复往往需要付出数倍的努力。
对于我们每一位工程师而言，这次事件也是一次重要的安全警醒：在享受 AI 带来十倍效率提升的同时，必须时刻保持对本地运行环境的审计意识与防御底线。
参考资料
1. 科技每日推送：《智谱用户炸了，ZCode 被曝偷传代码！官方道歉并补偿》： https://mp.weixin.qq.com/s/OCj4pQa-dPBxJaz2kf8MUA
2. 老冯云数：《智谱 ZCode，你打包上传我的代码仓库干什么？》： https://mp.weixin.qq.com/s/LdXekkP-Yb2IQfoMV53uDw
3. 一行 Java：《智谱 ZCode 被曝上传用户代码，官方回应来了~》： https://mp.weixin.qq.com/s/pQ8wghiw6moAGCNDtXPrbQ
4. Ferstar：《扒一扒 ZCode 静默上传全量 Git 历史的骚操作》： https://blog.ferstar.org/posts/zcode-silent-workspace-snapshot-upload/
5. cereblab：《xAI Grok Build silent git bundle upload gist》： https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547
— THE END —
文章仅做学术分享，如有侵权请联系删除，非常感谢！