ZCode 被曝上传 Git 历史与源代码：AI IDE 的安全性与隐忧
梳理 ZCode 工作区快照上传事件的证据、官方回应、开源和额度补偿，并讨论 AI IDE 在代码隐私、Git 历史与供应链安全上的风险。
本页目录 14 个小节
ZCode 被曝上传 Git 历史与源代码：AI IDE 的安全性与隐忧
2026 年 9 月，ZCode 的工作区处理逻辑引发了开发者对代码隐私的关注。争议的核心不是“AI 编程工具能不能联网”，而是：用户是否清楚知道哪些文件会被发送、发送的范围有多大、服务端能否解密，以及数据是否真的会被删除。
本文根据逆向分析文章、公开 Issue、官方说明和开源仓库整理时间线。
先说结论
- ZCode 3.12.3 在登录状态下会生成加密的完整工作区快照；快照可能包含源代码、
.git/objects、Git 历史、reflog 和 LFS 缓存。 - 调查者观察到一个约 313 MB 的商业项目快照反复尝试上传 564 次，但后续澄清显示该包没有成功上传，不能写成“313 MB 商业源代码已被窃取”。
- 另一个约 15 KB、包含 538 个文件的小型公开仓库快照显示已被服务端接收。这证明“快照上传链路确实可能触发”，但不等于所有用户的完整仓库都成功外泄。
- 官方承认 Repo Wiki 生成页面时可能触发仓库数据上传，表示问题已修复、相关对象存储数据已删除，并承诺开源代码和引入第三方审查。
- 自 2026 年 9 月 18 日起，官方向全体用户额外提供一次“周额度重置”。这是一次额度补偿，不应表述为所有套餐永久重置。
事件时间线
3.12.3：工作区快照进入上传流程
根据 调查者的逆向分析与实测记录，ZCode 3.12.3 在用户登录后可能创建一个加密的工作区快照，再尝试发送到远端服务。快照的潜在范围比当前编辑器中打开的单个文件更大，可能包括：
- 工作区内的源代码和配置文件；
.git/objects中的提交对象，以及分支、tag、reflog 等历史线索；- Git LFS 缓存和其他构建产物。
这里的“可能包含”很重要：实际内容取决于工作区、忽略规则和触发路径，不能据此断言每次请求都会携带完整仓库。
两组样本说明了什么
调查记录中，一个商业项目生成了约 313 MB 的加密包，并出现 564 次重试。后续更新明确说明，这个大包没有成功上传。因此，比较准确的说法是“客户端准备并反复尝试发送包含商业代码的快照”，而不是“313 MB 商业源代码已经被服务端成功接收”。
另一组约 15 KB、包含 538 个文件的小型公开仓库快照显示已被服务端接收。它提供了上传链路可达的实证，但样本规模有限，不能推导出所有仓库都会以相同方式上传。
官方回应与后续处理
官方在 反馈 Issue 707、Issue 709、Issue 711 和 Issue 715 中回应相关问题，并由媒体整理为 IT之家报道。目前可以确认的官方说法包括：
- Repo Wiki 生成页面时可能触发仓库数据上传。
- 团队已致歉并修复相关逻辑；调查文章提到 3.14.0 已移除快照生成和上传流程。
- 云端生成 Wiki 后会立即销毁上传数据，相关 OSS 存储桶数据也已删除。
- 计划开源代码并引入第三方安全检查。
- 自 9 月 18 日起向全体用户提供一次额外的周额度重置。
官方还提到中国信通院和绿盟科技的检查结论。除非完整报告、范围和方法公开，否则这类表述只能作为供应商声明，不能替代独立审计证据。
开源是否等于完全解决
2026 年 9 月 21 日，官方公开了 ZCode GitHub 仓库，采用 Apache-2.0 许可证，包含桌面端、Web、后端、共享 UI、Agent CLI 和运行时。这是积极的修复动作，但需要区分两个问题：
- 当前版本是否包含上传逻辑，以及修复是否容易被复现；
- 争议版本的完整提交历史、构建产物和服务器端配置是否能够被独立复核。
当仓库只有少量初始提交时，事后公开当前代码并不能自动还原 3.12.3 的全部历史。对于安全事件，版本差异、发布包哈希、构建脚本、网络请求日志和数据保留策略同样重要。
为什么 AI IDE 的风险比普通编辑器更复杂
AI IDE 通常同时拥有文件读取、终端执行、Git 操作、网络访问和模型调用能力。便利性越高，错误配置的影响面越大。
完整 Git 历史比当前文件更敏感
开发者删除过的密钥、客户数据、内部域名、数据库连接串和商业方案，可能仍留在 Git 历史或 reflog 中。只扫描当前工作树，不能证明仓库安全；把 .git 一起交给第三方，风险会显著扩大。
加密不自动等于端到端安全
客户端先加密再上传，可以降低传输途中被动窃听的风险，但如果服务端掌握解密密钥、能够完成 Wiki 生成或索引，仍然属于服务端可解密的数据处理。判断安全性时应追问密钥由谁持有、日志保留多久、管理员能否访问，以及删除是否有可验证记录。
“立即删除”需要可验证的控制
立即删除是一个承诺，不是技术证明。更有说服力的证据应包括对象存储生命周期策略、备份和缓存处理、访问审计日志、删除任务失败后的告警，以及独立第三方复核。
使用 AI IDE 的防护清单
个人开发者可以先做以下几件事：
- 不在默认工作区放置生产密钥、客户数据和未脱敏的
.env文件。 - 将 AI 工具使用目录与真实仓库分离，先复制最小可复现样例。
- 在防火墙、代理或系统审计中观察工具访问的域名和上传流量。
- 使用密钥扫描工具检查当前工作树、Git 历史和 LFS 对象；已经泄露的密钥要立即轮换。
- 关闭不需要的自动索引、Wiki、后台 Agent 和远程执行能力。
- 升级到已修复版本，并核对发布说明、安装包哈希和权限变化。
企业还应增加仓库分级、网络出口审计、最小权限沙箱、供应商安全评估、数据处理协议和可撤回的明确同意。高敏感仓库不应仅因为工具声称“加密”或“上传后删除”就默认允许上传。
对这次事件的看法
这次事件最值得重视的地方，不是某一个产品的单点失误，而是暴露了 AI IDE 的默认信任模型：用户以为自己在请求“补全一段代码”，工具实际可能需要读取整个工作区、调用 Git、生成索引并把数据交给远端服务。产品应该在第一次触发前清楚展示范围、目的、接收方、保留时间和退出方式，并把高风险操作设计为可审计、可撤回的明确授权。
开源、修复和额度补偿能够降低后续风险，也能修复部分用户关系，但长期信任仍取决于可复现的版本历史、透明的网络行为、独立审计和持续披露。对使用者来说，最稳妥的原则仍然是：把 AI IDE 当作拥有代码读取和网络能力的第三方代理，按最小权限、最小数据和可验证审计来使用。
参考资料
- ZCode 静默工作区快照上传调查
- ZCode 官方开源仓库
- ZCode 反馈 Issue 707
- ZCode 反馈 Issue 709
- ZCode 反馈 Issue 711
- ZCode 反馈 Issue 715
- IT之家：ZCode 官方回应相关问题
版权声明
- 作者
- Dawn
- 许可
- 本博客所有文章除特别声明外，均采用CC BY-NC-SA 4.0许可协议。转载请注明来源 Dawn's Blog！