文章总结： 旧版ZCode客户端存在完整工作区快照上传行为，313MB加密包涉及Git历史与本地配置，官方确认并修复但外部无法验证历史数据删除。建议用户升级至3.14.0以上版本、轮换仓库中曾出现的凭据、检查本地异常文件与网络连接，并建立AI编程工具准入规则。
综合评分： 85
文章分类： 数据泄露,安全运营,应急响应,安全建设,解决方案
关掉训练开关，313MB代码仍被上传：旧版ZCode事件怎么自查
原创
tcode
tcode
字节脉搏实验室
2026年9月21日 12:32
北京
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
一个本该只保存本地会话的目录，却多出313MB加密包；包来自一个345MB的商业项目，状态文件显示上传失败重试了564次。2026年9月18日，独立开发者ferstar公布对AI编程桌面端ZCode的排查，争议焦点不是普通的遥测，而是完整工作区、Git历史和本地配置是否在用户不知情时被打包离开电脑。
当天傍晚，智谱通过官方用户群回应：问题源于“代码库索引”功能，Repo Wiki生成页面时可能触发仓库数据上传；数据在云端生成页面后立即销毁，功能早期默认开启，部分用户受到影响，相关问题已经修复。9月19日发布的ZCode 3.14.0更新日志写明“修复仓库百科异常上传的问题”。
事件已经进入修复阶段，但仍有三个问题不能靠一句“已修复”跳过：旧版到底上传了什么，已有数据能否被外部验证已经删除，开发团队又该如何判断自己的仓库曾经进入过上传链路。
313MB不是一个普通日志文件
ferstar的排查从一个体积异常的~/.zcode目录开始。目录约700MB，其中v2/checkpoints占主要空间。一个待上传包为313,070,842字节，对应工作区大小345,549,173字节；状态文件记录了项目路径、baseline类型以及564次失败重试。
更关键的是本地生成的Manifest清单。作者统计了42,411个文件，其中Git LFS缓存约196.1MB，占56.8%；Git对象库约102.2MB，占29.6%；reflog约0.6MB，占0.2%；其余源码和文档约46.2MB，占13.4%。把前三项相加，.git相关内容约298.9MB，占工作区的86.5%左右。
这个比例改变了事件性质。模型推理通常只需发送与当前问题相关的上下文；全量快照可能包含已经删除的配置文件、历史版本中的密钥、尚未推送的分支、内部仓库地址和本地操作轨迹。即使当前文件看起来干净，Git历史仍可能保留过去提交过的敏感信息。
作者还原的上传链路包括两步：客户端先向服务端申请上传凭证，随后使用服务端下发的公钥加密快照，再直传对象存储。公钥由服务端提供、私钥只留在云端的描述，被作者视为争议核心。第三方无法只凭本地密文判断云端如何处理，也无法独立验证“立即销毁”的生命周期。
官方回应解开了哪一半问题
官方回应确认了“可能上传仓库数据”和“早期默认开启”，这比把事件解释成单个界面开关故障更接近事实。但官方没有公开每个受影响版本的上传条件、数据量、保留日志和删除审计，因此公开材料仍不足以证明所有历史快照都已彻底清除。
对照版本也很有必要。ferstar复盘的被影响版本是3.12.3；他在更新后检查3.14.0，认为云端打包与上传代码已被移除，只保留本地检查点逻辑。官方更新日志则明确列出修复项，并继续在9月21日发布3.14.1的小版本更新。
“修复”和“没有发生过上传”是两件事。升级能阻止后续异常上传，却不能自动证明过去没有上传，也不能替用户判断历史提交里是否有密钥。安全团队需要把版本修复和历史数据处置分开处理。
两个隐私开关为什么容易让人误判
作者拆解旧版客户端后称，“优化体验”开关更接近是否允许数据用于训练，“仓库快照索引”开关控制服务端是否索引快照；关闭它们不等于停止本地打包和上传。这个判断来自逆向分析与日志观察，仍应由厂商开源代码后的第三方复核确认。
从产品设计看，问题不在开关数量，而在开关名称没有覆盖真实数据路径。用户理解“关闭优化”是为隐私降级，实际链路却可能仍在上传；只要默认开启，绝大多数用户就不会逐项验证后台sidecar、登录令牌和网络出口。
因此，AI编程工具的安全评估不能只问“是否训练我的代码”。还要分别问：发送范围是当前提示词还是整个工作区，是否包含.git，何时触发上传，是否保留副本，谁能解密，删除由谁审计，关闭功能后本地和云端各保留什么。
先判断自己处在哪一段链路
第一类是把旧版ZCode直接用于真实商业仓库的用户。仅升级还不够，应先确认使用的版本，再清点历史提交中是否出现过云密钥、数据库密码、私钥、内部域名或客户数据。历史上传范围和云端删除无法由用户单方验证，最稳妥的做法是轮换曾经出现在仓库里的长期凭据，并检查相关云审计日志。
第二类只是把公开代码或测试仓库交给ZCode。风险通常低于商业私有仓库，但仍应检查本地是否留下~/.zcode/v2/checkpoints加密包、状态文件和异常大目录；不要把加密包当成无敏感内容的普通缓存，也不要直接上传到工单或第三方分析平台。
第三类尚未升级或无法立即升级。应先使用进程、文件和网络三类证据确认上传行为是否仍存在，再通过网络出口或文件系统权限阻断异常链路，同时为本地检查点功能保留替代方案。临时阻断需要记录恢复条件，不能成为永久替代补丁。
升级到3.14.0或更高版本后，还要核对客户端是否真的运行新版本，而不是只看到下载完成。对于企业终端，版本清单应记录ZCode、Agent、插件和本地服务组件，避免用户更新了主程序却仍残留旧sidecar。
检查时的三个证据面
文件面先看~/.zcode/v2/checkpoints是否存在\*.enc、pending目录和体积远超普通会话的包，再查应用日志里的上传失败、重试和项目路径。网络面应关注ZCode进程对对象存储、协调服务和未知域名的持续连接，但要把正常模型API流量与快照上传分开记录。
账号面更值得投入。查看云对象存储和内部仓库的访问记录，确认是否有异常上传、短时存在的临时对象或未知客户端；如果仓库历史中含生产凭据，应直接进入轮换流程，不必等待确认快照是否被读取。密钥一旦进入历史并离开控制边界，继续复用它就不再是低风险选择。
最后要建立一条可执行的准入规则：AI编程工具能否读取整个工作区，敏感仓库是否允许模型服务访问，默认上传是否经过安全评审，客户端代码是否可审计。工具可以提高开发效率，但“能读代码”和“能打包全部历史”之间的权限差，必须在配置中显式区分。
这次事件最清楚的结论有三点：旧版客户端确实出现过完整工作区快照与上传尝试；官方确认部分用户受到影响并称已修复；外部仍无法验证历史快照和删除生命周期。把结论停在这里，同时完成升级、凭据轮换和终端审计，比争论“是不是偷传”更能降低实际风险。
如果团队负责人只知道“官方说修好了”，可以继续追问：“旧版上传过哪些仓库、云端保留多久、删除由谁验证，以及Git历史里哪些凭据需要立即轮换？”这四个问题的答案，才决定这次修复是否需要进一步处置。
热点来源
来源：ferstar原始取证：2026-09-18，https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/
来源：ZCode官方更新日志：3.14.0于2026-09-19发布，https://zcode.z.ai/cn/changelog
来源：IT之家官方回应整理：2026-09-18，https://www.ithome.com/1/004/310.htm
来源：ZCode 3.14.1发布记录：2026-09-21，https://zcode.z.ai/cn/changelog
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：字节脉搏实验室 tcode
tcode《关掉训练开关，313MB代码仍被上传：旧版ZCode事件怎么自查》