智谱AI编程工具陷信任危机:悄悄打包几万个文件传OSS,官方回应“已物理移除”

一切始于一次极其日常的磁盘清理。

2026 年 9 月 17 日，开发者 ferstar 在清理自己 256GB 的 MacBook Air 磁盘时，顺手查看了本地隐藏目录。他发现智谱官方推出的 AI 编程桌面端 ZCode 数据根目录 __CODE_SPAN_0__ 异常占用了超过 700MB 空间。

其中 __CODE_SPAN_0__ 目录下，静静躺着一个体积高达 313MB 的 __CODE_SPAN_1__ 加密文件。旁边对应的状态描述文件赫然写着：类型为 __CODE_SPAN_2__（全量快照），失败重试计数已达 564 次。

解包 Electron 客户端打包文件 __CODE_SPAN_0__ 并还原全部代码后，这位长期订阅 GLM Coding Max 的工程师在 9 月 18 日早晨发布了详细排查记录：只要用户处于登录状态，ZCode 就会在后台将整个本地工作区静默打包、使用信封加密后直接上传至阿里云对象存储（OSS）。在被捕获的 3.12.3 版本中，即便用户手动关掉界面上的“优化体验”与“快照索引”开关，后台打包上传链路依然照常运转。

事件在国内外开发者社区迅速发酵。9 月 18 日傍晚 17:44，智谱在官方社群发布通报承认存在上传行为，解释该逻辑属于“代码库索引”功能，用于在云端生成代码仓库知识库（Repo Wiki）以及会话检查点回滚，由于早期版本默认开启影响了部分用户；官方强调上传数据在 Wiki 生成后“立即销毁不予留存”，并在随后推送的 3.14.0 版本中物理移除了云端上传代码。

这起事件不仅关乎一次产品功能的工程越界，它直接撞上了所有 AI 辅助编程工具最敏感的底线：在 Agent 渴望吞噬更多上下文以提高自主能力的时代，开发者的本地代码资产到底归谁掌控？

在传统的本地版本回退或编辑器恢复机制中，备份文件应当由本地密钥加密，或者直接以明文增量保存在本地磁盘。

但逆向排查揭示出的架构完全打破了这一常理。

根据 ferstar 对 __CODE_SPAN_0__ 的源码复原，ZCode 客户端在后台执行的上传流水线分为两步：

• 第一步：向协调服务器索取凭证。
   客户端首先向智谱的主控端点 __CODE_SPAN_0__ 发起请求，主控端动态返回阿里云 OSS 的直接上传表单签名（包括 __CODE_SPAN_1__、__CODE_SPAN_2__）、动态分配的文件存储路径、上传大小限制，以及一枚服务端生成的 RSA 加密公钥。
• 第二步：直接走 HTTP 表单直甩阿里云 OSS。
   客户端在本地将工作区文件打成 __CODE_SPAN_0__ 压缩包，采用流式 AES-256-CTR 对称加密，随后用服务端下发的 RSA 公钥把这枚对称密钥包裹成数字信封（Envelope Encryption）。最后，加密后的文件不经过智谱自建的应用服务器，而是直接通过 HTTP POST 表单上传至阿里云 OSS 存储节点。

这种信封加密的设计带来了极大的技术矛盾。

用于加密本地压缩包的 RSA 公钥由云端动态下发，而对应的私钥完全留存在智谱云端。

这意味着用户本地生成的这份几百兆加密快照，不仅开发者本人打不开，连断网状态下的 ZCode 客户端本体也无法解密。如果这项功能的真实用途仅仅是官方声称的“会话检查点回滚”，那么将解密密钥完全收归远端服务器、让客户端丧失本地解密能力的设计在工程逻辑上缺乏合理支撑。

正如逆向分析所指出的，一把只有服务端能够解开的钥匙，其技术目标就是确保远端能够单方面获取和阅读这批资产。

虽然加密后的压缩包无法在本地逆向解密，但 ZCode 客户端在打包时生成的本地清单文件（Manifest）是以明文形式记录在本地的。

从抓取到的 Manifest 清单来看，一个被选中的完整商业项目共包含 42,411 个文件，解压后的总有效体积为 345.5MB。对这份清单的数据构成进行分类统计后，数字呈现出惊人的失衡：

• .git/lfs/（大文件存储缓存）：
   体积为 196.1MB，占整体体积的 56.8%。这里包含了项目历史上拉取过的所有二进制模型权重、测试数据包与媒体资产。
• .git/objects/（Git 核心对象库）：
   体积为 102.2MB，占比 29.6%。这里存储着该代码仓库自创建第一天起的所有 Commit 提交、Tree 目录树与 Blob 数据块。
• .git/logs/（Git 引用日志）：
   体积为 0.6MB，占比 0.2%。记录了本地开发者每一次切换分支、重置代码与本地未推送操作的完整 reflog 轨迹。
• 当前业务源码与配置：
   __CODE_SPAN_0__ 以及各项项目配置文件加在一起约为 46.2MB，仅占总打包体积的 13.4%。

整个 `.git` 版本控制目录吃掉了整个打包载荷的 86.6%。

将整个 __CODE_SPAN_0__ 目录打包上传的严重性，远远超过了单纯泄露当前项目代码：

• 被覆盖删除的敏感配置复活：
   许多工程在早期开发中可能曾误提交过数据库密码、API Token 或私有证书，即便后续通过新 Commit 删除了明文，这些密钥依然完整固化在 __CODE_SPAN_0__ 的历史版本树中。
• 未公开的研发路线暴露：
   本地尚未推送至远程仓库的私有分支名，直接揭示了企业未经公开的新功能研发计划。
• 内网基础设施架构外泄：
   __CODE_SPAN_0__ 文件中配置的内部自建 GitLab 域名、端口与私有仓库克隆地址，将企业内网的拓扑与代码资产分布全盘公开。

此外，逆向代码还发现了一项名为 __CODE_SPAN_0__ 的附加清单逻辑：该逻辑会计算用户全局 ZCode 配置文件（如 __CODE_SPAN_1__）的哈希值，将其跨工作区打包，随着每次快照同步发往云端。

当开发者发现数据异常时，常规的第一反应是进入设置面板关闭数据上报。然而，针对 3.12.3 版本的代码审计表明，前端的用户设置并未在底层起到拦截作用。

• “优化体验”开关（optimizeAgentExperienceEnabled）：
   多数用户认为该开关用于关闭数据遥测与上报。然而底层代码逻辑显示，它仅用于标记“是否允许将数据用于模型训练”。无论开启还是关闭，后台快照抓取与上传链路均不受影响。
• “仓库快照索引”开关（repoSnapshotIndexingEnabled）：
   表面上对应快照功能本身，但代码实现中它仅控制服务端在接收到快照后“要不要在云端建立索引”。本地打包、加密与尝试上传 OSS 的动作照常触发。

在 3.12.3 的组装逻辑中，负责快照捕获与上传的后台协程（sidecar）在客户端启动时被无条件实例化。代码中完全没有基于用户配置的条件拦截分支，唯一的运行前置条件仅仅是身份提供模块（__CODE_SPAN_0__）能够返回一个有效的登录 JWT 令牌。

只要用户登录了账号，后台上传机制就会随之常驻运行。

抓取触发点主要分布在两处：一是每一次用户输入提示词之前（__CODE_SPAN_0__），二是每次任务结束并标记为 __CODE_SPAN_1__ 时。在作者的单次活跃会话日志中，系统最高记录到了 62 次快照捕获行为。

随着事件引发广泛关注，原作者与多位社区安全研究者进一步核对了网络流量与新版修复情况，厘清了核心事实边界：

• 313MB 的大型商业项目未成功离网：
   ferstar 通过家庭 OpenWrt 路由器的连接跟踪与流量日志反复核对确认，该 313MB 的商业项目快照因单文件体积超过了服务端分配的尺寸上限，连续经历了 564 次上传失败，始终卡在本地 __CODE_SPAN_0__ 目录中，未曾真正流出局域网。
• 小型公开仓库确实已被云端接收：
   另一个包含 538 个文件、压缩加密后约 15KB 的轻量工作区快照，在状态文件中明确标记为已被服务端正式接收（__CODE_SPAN_0__）。包括 NodeSeek 论坛用户在内的多位 Windows 与 Linux 开发者随后也在本地系统复现了相同的目录结构与接收状态。
• 3.14.0 版本的物理拆除：
   智谱在 9 月 18 日通报后紧急推送了 3.14.0 更新。逆向比对证实，新版本已在代码层彻底剥离了上传管线，仅保留本地检查点功能，同时云端的上传凭证分配接口（__CODE_SPAN_0__）已下线并返回 HTTP 404 错误。

智谱在 9 月 18 日 17:44 发出的官方通报给出了三条核心说明：

1. 功能定位：
    上传属于“代码库索引”早期默认开启的功能，旨在云端生成 Repo Wiki 和支持检查点回退。
2. 数据处理：
    生成 Repo Wiki 后，相关上传数据会在云端“立即销毁，不予保存”。
3. 补救措施：
    问题已在新版中修复，承诺近期将 ZCode 代码库完全开源以接受第三方审查，并向全体用户补偿一次周额度重置。

然而，这份通报并未完全平息业界的疑虑。

首先是工程逻辑上的自相矛盾。 官方将该功能同时定义为“Repo Wiki 生成”与“会话检查点回退”。如果是为了支持随时随地的版本回滚，那么数据必然需要在云端持久化存储以备拉取；如果真如通报所言“生成 Wiki 后立即销毁”，那么“检查点回滚”机制在云端根本无从实现。

其次是存量数据的验证困境。 外部用户与安全专家无法在技术上验证云端此前接收到的加密快照是否已在物理存储上彻底覆灭，也无法确认掌握私钥的云端环境是否存在解密日志残留。

9 月 19 日后，太原承明科技有限公司等企业用户公开发函向智谱追责，对受影响期间的数据流向、销毁证据链以及是否存在未经许可的数据留存提出了正式质询。随后，智谱通过其 MaaS 开放平台宣布将上线数据“内容不留存”申请机制，允许企业和开发者提交工单开通更为严苛的隐私隔离保障。

这起风波给所有正在重度依赖 AI 编程工具的团队敲响了警钟。

过去的代码补全插件（如 GitHub Copilot 早期形态）只会在单次触发时光标前后的代码片段作为 Prompt 发送；然而现在的 Coding Agent 都在追求“全局上下文理解”、“自动化重构”和“项目全景知识库”。在激进的产品设计追求下，工具厂商很容易产生一种工程惯性：试图将开发者的本地文件树一股脑推向云端算力。

在开发商彻底建立规范之前，开发者需要明确两层防线：

对于依然在使用各类桌面端 Agent 的工程师，单纯依赖 UI 界面上的“关闭遥测”复选框已经不够安全。在操作系统内核级别锁定权限是更彻底的止血手段：

• macOS 系统：
   可以对快照与遥测目录添加文件系统不可变标志（Immutable Flag），彻底剥夺应用写入权限：

• Linux 系统：
   使用 __CODE_SPAN_0__ 命令锁定属性：

智谱 ZCode 事件应当成为整个国内 AI 软件生态的合规分水岭。任何具备代码自主探索能力的 Agent 工具，必须遵守三条基本契约：

• .git 目录必须列入硬编码黑名单：
   任何涉及云端分析的功能，必须严格过滤版本控制元数据、分支日志与历史对象，严禁将历史 commit 与 LFS 资产纳入上传范围。
• 任何全量数据外发必须二次弹窗授权：
   涉及超越即时对话窗口的整仓索引行为，不得以“默认开启”或隐晦勾选的方式静默执行，必须向用户明确展示待上传文件的清单与体积。
• 端到端加密与密钥归属透明：
   如果提供跨设备同步功能，加密密钥必须基于用户本地主密码派生，确保云端服务商在任何情况下均无法单方面解密用户的核心商业资产。

AI 编程工具的终极壁垒从来不只是基座模型的生成能力，而是开发者愿意将整个代码仓库敞开托付的商业信用。 这一次，是一台磁盘吃紧的 MacBook Air 偶然触发了警报；但下一回，重塑信任的代价将远不止一次周额度补偿。

我是 KmTech，专注分享前沿 AI 技术与工程实践观察。

如果你觉得今天这篇有收获，欢迎点赞、在看、转发支持，我们下篇见。