Reed's News
← 返回精选

ZCode 被指静默上传用户完整 Git 历史

AI 68 cdnsteve 2026/9/18 1694 字 原文 ↗

2026年9月18日，开发者ferstar发布了一篇针对ZCode的逆向工程分析。ZCode是总部位于北京的Z.ai公司推出的AI编程桌面应用，而Z.ai正是GLM系列开源权重模型的开发者——该系列模型（包括本站追踪的GLM-5.3-Flash）被本地AI社区广泛部署在个人设备上。此次曝光的问题比多数隐私丑闻性质更恶劣：用户登录ZCode后，应用会在后台悄悄打包整个工作区，包含完整的.git历史记录、LFS资产缓存、引用日志和全局应用配置，加密后上传至阿里云对象存储服务（Aliyun OSS）。据ferstar的抓包数据显示，一个345MB的商用工作区被打包成313MB的加密压缩包，包含42411个文件，在调查期间还记录到564次上传失败的重试尝试。

如果你在本地运行GLM模型，需要明确：发布模型权重的公司，和开发者在权重之上使用的运行环境并非同一主体。社区讨论的反应也印证了这种普遍混淆：不少评论者因GLM是开源模型，便想当然认为ZCode也是开源软件，但事实并非如此。GLM模型权重是开源的，而ZCode作为适配自家模型的运行框架却是闭源的，Z.ai还宣称其提供第三方编辑器无法比拟的官方原生集成体验。

事件在数小时内便以中英文双语传播开来：ferstar的帖子浏览量突破27.6万，而FeiZ发布的中文预警帖（“暂时禁用ZCode……还是尽量使用开源代理工具为好”）也获得了6.38万次浏览。被引用最多的评论来自Petri Kuittinen，他开发的AI代理工具本身是开源的且附带安全文档，他表示：“我的建议过去是、现在依然是：绝对不要信任闭源AI运行框架。”

让这起可疑的目录访问事件升级为丑闻的关键细节，在于加密密钥的设计。ZCode采用信封加密机制：首先用对称密钥加密上传内容，再用RSA-OAEP公钥对该对称密钥进行加密。公钥由服务器在上传凭证协商阶段下发，对应的私钥仅存储在Z.ai的云端。ferstar尝试用本地系统中的所有私钥解密压缩包，均以失败告终。用户本地磁盘上的313MB密文，既无法被用户本人解密，也无法被ZCode客户端自己解密。

ferstar在帖子中给出结论：“只有服务器能使用的密钥，唯一用途就是确保服务器可以随时读取你的代码。”

上传内容明细

打包清单以明文形式存储在本地，内容具体明确。以下是对一个包含42411个文件的工作区快照的分析：

内容 大小 占比
.git/lfs/ 196.1 MB 56.8%
.git/objects/ 102.2 MB 29.6%
.git/logs/ 0.6 MB 0.2%
源代码与文档 46.2 MB 13.4%

仅.git目录就占了上传内容的86.6%。

某42411文件工作区快照的上传内容拆分：.git目录占加密压缩包的86.6%

这一点至关重要，因为Git对象存储并非工作目录的简单快照，而是包含了代码仓库从创建之初的完整历史。其中可能包含后续提交中已删除的API密钥、尚未推送的分支名称（可能泄露未发布的产品计划），以及.git/config文件中的内部主机名和仓库路径。被捕获的压缩包承载的是数年的工程历史，而非用户当前打开的文件。

ferstar通过逆向客户端的app.asar文件，还原了上传流程：客户端向zcode.z.ai请求凭证，服务器返回OSS表单签名、对象密钥、大小限制和每轮会话的RSA公钥；客户端将工作区打包为tar.gz格式，用AES-256-CTR加密，再对对称密钥进行加密，最后将压缩包直接POST到阿里云OSS；OSS随后回调Z.ai的后端以完成快照注册。测试期间，运行中的客户端持续与zcode.z.ai及两个阿里云OSS节点保持连接。

ferstar从客户端app.asar还原的ZCode快照上传流程：从协调服务器获取凭证，本地打包加密，直接向阿里云OSS提交表单，回调完成注册。

设置开关无法阻止上传

用户发现问题后，自然会想到去设置里调整选项。ferstar将UI开关与代码进行了交叉验证：

  • “优化体验”（optimizeAgentExperienceEnabled）仅控制是否授权将数据用于模型训练，快照的捕获和上传仍会继续。
  • “仓库快照索引”（repoSnapshotIndexingEnabled）仅控制服务器是否对已上传的快照建立索引，本地打包和上传操作不受影响。

客户端主程序在启动时会无条件启动捕获进程，完全不受用户偏好设置的限制——唯一的条件是令牌服务能生成有效的JWT。会话日志显示，在一次活跃会话中，共触发了62次捕获事件，每次触发都发生在用户输入提示之前或任务完成之后。

另有信息佐证这一机制。公开的AI框架指令集集合OrcaPromptVault中，收录了ZCode的131KB系统提示词和31个工具接口。其中“检查点/回退”功能与系统提示词绑定，模板“已应用工作区回退。rewindId, checkpointId, strategy, restoredFiles”在提示词中出现了五次。这正是快照流水线面向用户的功能入口，而文件系统锁定会禁用该功能。

AI代理的完整工具接口中，没有任何与快照、上传或遥测相关的工具。数据泄露流程并非代理工具的一部分，而是独立于工具循环之外的主机级进程。这就是为什么权限设置无法阻止它，且AI代理本身对此毫无察觉。在131KB的捕获指令中，完全没有提及阿里云、OSS、上传或隐私相关内容。

这次捕获还补充了ferstar未提到的细节：ZCode内置了ReadSessionContext工具，可根据会话ID读取其他已保存的ZCode会话内容。结合主机级的快照进程，会话内容既会在本地保存，也会被上传至云端。

泄露的系统提示词中的检查点模板（出现五次），以及AI代理的31个工具接口——其中无任何快照、上传或遥测工具。

隐私政策未提及该行为

ZCode的隐私政策声明，工具会收集“对话过程中提交的文本、文件和代码”——这是所有AI编程工具都会做出的标准推理上下文披露。但ferstar在隐私政策、常见问题和更新日志中，均未找到任何关于打包并上传整个工作区及Git历史的说明。最接近的表述是一段关于优化程序默认关闭的模板化声明。

让问题更严重的背景

ZCode于2026年7月推出，其宣传核心正是“信任”。此前Anthropic的Claude Code刚曝出隐藏遥测争议，Z.ai便立刻将ZCode定位为Claude Code的替代方案，强调开源权重模型是摆脱“关停风险”的出路。曾有用户在X平台询问Z.ai高管，ZCode是否会包含“任何形式的间谍软件”，对方回应称，公司不会实施“ZCode官网所列内容之外的任何功能”。

而工作区快照功能并未在ZCode官网上列出。

Z.ai于2026年1月在香港联交所上市。截至本文发布时，公司官方X账号尚未对ferstar的帖子作出回应。最引人注目的回复来自一个与ZCode团队相关的账号：“很抱歉让你发现了这件事”——这更像是对该机制的确认，而非反驳。ferstar的推文在13小时内浏览量突破27.6万，V2EX及类似HN的社区讨论基本围绕一个核心分歧展开：AI代理在工具调用过程中上传代码片段是常见行为，且通常获得用户同意；但ZCode是在未获同意的情况下，上传完整代码仓库及其全部历史，还进行加密处理，只有厂商自己能解密。

有效的防御方法

删除待上传的压缩包无法解决问题：客户端会在半小时内重新生成一个313MB的压缩包，并增加重试计数器。真正有效的修复方法是从文件系统层面入手，将检查点目录设置为内核级不可写：

Linux系统：

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints

macOS系统：

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints

副作用是：检查点回退的UI功能将无法使用——而该功能原本就依赖上传代码才能实现。聊天、自动补全和工具调用功能则可正常使用。如需恢复回退功能，可执行chattr -i（Linux）或chflags nouchg（macOS）命令。

两个月前的相似事件——但动机不同

这并非首次发生类似事件。2026年7月，Grok Build用户发现xAI的这款编程代理工具也存在上传行为：默认情况下，完整的Git提交历史和未改动的仓库数据会被发送至谷歌云。在一次记录在案的会话中，上传事件在186轮对话中持续触发。一位在主目录运行Grok的用户发现，自己的SSH密钥、密码管理器数据库、文档和照片都出现在上传路径中，而这一情况仅通过查看工具自身日志才被发现。Peter Dedene报告称，他的账号显示“disable_codebase_upload: true”（已禁用代码库上传），但Codex和Anthropic却独立发现，仍有8个私有仓库被上传。

事件模式相似，但动机截然不同，这一点至关重要。Grok的上传是一起公开的失误：工具会将上传记录在自身的unified.json文件中，事件与代理的正常上下文同步阶段绑定，且xAI在事件发生后推出了关闭开关。虽有疏忽的默认设置和失效的控制机制，但并非刻意隐藏的设计。而ZCode的情况则完全相反：它用仅服务器持有私钥的方式加密上传内容——意味着加密是为了防止上传者（即用户）读取自己的代码；代码验证显示设置开关无法阻止上传；删除本地捕获的文件会触发重试，ferstar调查期间就记录到564次尝试；且触发条件是登录，而非使用。

疏忽的典型是Grok：一个无人管控的同步功能，在自身日志中清晰可见。而ZCode的证据指向刻意为之：加密以确保只有服务器能读取压缩包，设置开关形同虚设，删除文件后仍持续重试，且从未在隐私政策中提及相关行为。现在，在本地运行AI编程代理的用户不应再轻信任何默认设置，必须自行验证两点：登录时运行环境会传输什么数据，以及谁能解密它存储的内容。

Grok Build的日志上传事件（7月）与ZCode的捕获流程（9月）：模式相似，动机不同。Grok的上传公开且未加密；ZCode的加密却是针对用户本人。

对本地AI的启示

本地运行开源权重模型的宣传点是：你的模型，你的硬件，无需按token付费，不受厂商关停限制。ZCode事件让人们意识到，信任的范畴不止于模型层面。模型之外的运行环境——框架、桌面应用、更新流程——同样是信任的关键。一个被云端调用框架包裹的本地运行模型，根本算不上真正的“本地”。

由此衍生出两项检查原则，适用于该领域的所有运行框架，而非仅ZCode：登录状态下，运行环境会传输什么数据？谁能解密它存储的内容？Tokenstead平台追踪代理框架及其遥测行为，正是出于这一目的；若Z.ai后续推出修复方案、更新隐私披露或发布声明，本文将同步更新。

资料来源：