2026年9月18日，开发者费尔星（ferstar）发布了对Z.ai（Z.ai）旗下AI编程桌面应用ZCode（ZCode）的逆向分析。Z.ai是总部位于北京、通用语言模型（GLM）系列开放权重模型背后的公司，包括GLM-5.3-Flash。他发现，只要应用登录，就会静默打包整个工作区——完整.git历史、LFS资产缓存、reflogs和全局配置——加密后上传至阿里云对象存储（Aliyun OSS）。他捕获到313MB加密存档，来自345MB商业工作区，42,411个文件，调查期间记录了564次失败上传。

2026年9月18日，开发者 ferstar 发布了 ZCode 的反向工程解析。ZCode 是 Z.ai 推出的 AI 编码桌面应用，Z.ai 是总部在北京的公司，旗下有 GLM 系列开放权重模型（包括本地 AI 社区广泛部署的 GLM-5.3-Flash）。发现比多数隐私丑闻更糟：只要应用处于登录状态，就会静默打包用户整个工作区——完整的 .git 历史、LFS 资源缓存、reflogs 和全局应用配置——加密后上传到阿里云 OSS 对象存储。研究者自己抓包到一个 313MB 加密档案，来自 345MB 商业工作区、42,411 个文件，调查期间记录了 564 次失败上传尝试。

如果你在本地运行 GLM，发布权重的公司与开发者可能使用的运行时并非同一回事——帖子评论区显示这种混淆真实存在：有评论者因为 GLM 开源就以为 ZCode 也开源。其实不然。权重开源；但 harness 闭源，且是 Z.ai 为自己模型打造的 harness，号称是第一方集成，第三方编辑器无法比拟。

几小时内故事在双语圈传开：ferstar 的帖子浏览超 276,000，FeiZ 的中文警告帖（“暂时禁用 ZCode……尽量多用开源 agent”）另获 63,800 浏览。被引用最多的是 Petri Kuittinen 的回复，他自己的 AI agent 开源并带安全文档：“我的建议过去是、现在仍是：不要信任闭源 AI harness。”

让可疑目录变成丑闻的细节是加密密钥。ZCode 使用信封加密——载荷用对称密钥加密，该密钥再用 RSA-OAEP 公钥包装。公钥由服务器在上传凭证协商时下发。对应私钥只存在于 Z.ai 云端。ferstar 尝试用本地系统上所有私钥解包档案，均失败。那 313MB 密文留在用户自己磁盘上，用户和 ZCode 客户端都无法解密。

ferstar 在帖中的结论：“只有服务器能用的密钥只有一个目的：确保服务器想读你代码时就能读。”

打包了什么

打包清单以明文存在本地，内容具体。以 42,411 文件快照为例：

| 内容 | 大小 | 占比 | | --- | --- | --- | | .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%。

git 对象存储不是工作树快照，而是仓库自创建以来的完整谱系。后续提交中删除的 API 密钥在其中，未推送的分支名泄露未发布产品计划，.git/config 里的内部主机名和仓库路径也在其中。抓到的档案是多年工程历史，而非你打开的文件。

上传管道根据客户端 app.asar 重建：客户端向 zcode.z.ai 请求凭证，后者返回 OSS 表单签名、对象键、大小上限和每轮 RSA 公钥；客户端将工作区打包为 tar.gz，用 AES-256-CTR 加密，包装对称密钥，直接将档案 POST 到阿里云 OSS，OSS 回调 Z.ai 后端注册快照。测试期间运行中的客户端与 zcode.z.ai 及两个阿里云 OSS 节点保持持久连接。

开关拦不住它

自然反应是打开设置。ferstar 将 UI 开关与代码交叉比对：

• “优化体验”(optimizeAgentExperienceEnabled) 只控制数据是否被授权用于模型训练。快照抓取和上传照常。
• “仓库快照索引”(repoSnapshotIndexingEnabled) 只控制服务器是否索引已上传快照。本地打包和上传照常。

宿主程序在启动时无条件实例化抓取 sidecar，不以用户偏好为门槛——唯一要求是 token 提供方能产出有效 JWT。会话日志显示单次活跃会话有 62 次抓取事件，在每次提示前和任务完成时触发。

第二信源印证了该机制。OrcaPromptVault 是一个公开收集的 AI harness 提示库，其中存有 ZCode 的 131KB 系统提示和 31 个工具面。检查点/回退功能接入了系统提示——模板“Workspace rewind applied. rewindId, checkpointId, strategy, restoredFiles”出现了五次。这是快照管道的用户可见顶端，也就是文件系统锁所禁用的功能。

agent 的完整工具面里没有任何快照、上传或遥测工具。外泄管道不是 agent 工具，而是工具循环之外实例化的宿主级 sidecar。这正是没有任何权限设置能阻止它、agent 自身也看不见它的原因。在 131KB 捕获指令中，只字未提阿里云、OSS、上传或隐私。

抓取还补充了 ferstar 未提及的细节：ZCode 带有一个 ReadSessionContext 工具，可按会话 ID 按需读取其他持久化的 ZCode 会话。结合宿主级快照 sidecar，会话内容既本地持久化又被云端捕获。

泄露的系统提示检查点模板（出现五次）及 agent 的 31 工具面，其中不含快照、上传或遥测工具。

隐私政策没提它

ZCode 隐私政策称该工具收集“对话期间提交的文本、文件和代码”——这是每个 AI 编码工具都有的标准推理上下文披露。ferstar 在政策、FAQ 和变更日志中均未发现提及打包并上传整个工作区和 git 历史。最接近的一句是模板声明，称优化计划默认关闭。

让情况更糟的背景

ZCode 于 2026 年 7 月发布，发布宣传直接打信任牌。在 Claude Code 隐藏遥测争议后几周，Z.ai 将 harness 对标 Anthropic 的 Claude Code，并将开放权重定位为摆脱“厂商 kill-switch”问题的出路。Z.ai 一位高管在 X 上被问及 ZCode 是否会包含“任何间谍软件”时，回答公司不会实现“ZCode 网站所列之外”的任何东西。

工作区快照不在 ZCode 网站列出。

Z.ai 于 2026 年 1 月在港交所上市。截至发稿，公司官方 X 账号未回应 ferstar 帖子。最显眼的回复来自一个与 ZCode 团队有关的账号——“嘿，很抱歉让你发现了这个”——这像是对机制的确认，而非反驳。ferstar 的推文 13 小时内浏览超 276,000，V2EX 和 HN 相关渠道的讨论主要沿一条线分裂：agent 在工具调用时经同意上传代码片段司空见惯。但这是整库加完整历史，未经同意，且加密到只有厂商能读。

有效的防御

删除待传档案没用：客户端半小时内重新打包了新鲜的 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 或 chflags nouchg 可恢复。

对本地部署意味着什么

跑本地开放权重是卖点：你的模型、你的硬件、无按 token 计费、无厂商关闸。ZCode 故事把信任面超出模型层。模型周围的运行时——harness、桌面应用、更新管道——也是信任面的一部分，而被云电话 harness 包裹的本地模型并非真正本地。

由此引出两项检查，适用于该领域所有 harness，不仅 ZCode：登录时运行时传输了什么，以及谁能不能解密它存的东西。Tokenstead 追踪 agent harness 及其遥测行为正是为此；若 Z.ai 以修复、披露变更或声明回应，这篇分析将更新。

整体气氛是警觉加不满：多数人认为静默上传用户代码是不可接受的红线，并把矛头指向闭源 harness 这一结构性风险；少数人则觉得报道本身的技术细节不过关，甚至有人直接按国别归因（但被点踩）。

认为只要 harness 闭源就不可信，无关中美

• 闭源 agent 本身就是危险信号，应该只用有口碑、用户基数足够大、代码被人盯着看的开源方案，被点到名字的是 OpenCode 和 Pi（高赞） > 闭源 agent 无论出自中国还是美国都是危险信号，用开源且有足够用户盯着的最稳妥。（@tancop）
• 就算只是拿 ZCode 试用，也不该拿专有项目去冒险；光有开放权重模型不够，还需要开源 harness（较多人）
• 有人补充自己的 harness 没有后端、根本不往外发数据，以此作为对照（少数人）

认为零通知、无法关闭的静默上传已属于恶意软件

• 现代软件对隐私普遍随意，但这次越过了第二条线：毫无提示、规模侵入、数据几乎必然私密、外传可能违法，并且没有明显的关闭开关（较多人） > 这已经跨进了彻头彻尾的恶意软件范畴。（@api）
• 由此延伸到不信任 GLM 等 Z.ai 模型，因为无法判断训练数据里被塞了什么；也有人借题发挥补了一句地缘政治的阴谋论猜测
• 有人讽刺这不过是「又一个发现 agent 其实不在本地跑」的新闻，之前已经爆过类似的事，接下来大概就是「AI 公司未经同意使用我的数据」

质疑报道本身混淆了 git 历史与 git 仓库

• 文章分不清 git log 和这里真正指的整个 git 仓库，这个错误本身就说明很多（较多人） > 文章连 git 日志和 git 仓库都分不清，这一点本身就说明了不少问题。（@Aldipower）
• 也有人把它放进之前的「蒸馏」事件序列里，问这算是进步还是退步

少数人直接把矛头对准国别

• 有个别评论用国别标签解释一切，结果被社区点踩（少数人） > 中国人干中国人的事。（@tonyhart7）

有价值的补充

• 自己写 harness 时把项目文件、被忽略文件、dotfiles 和外部文件的读取权限分开，才发现 GLM 尤其是 DeepSeek 特别爱尝试读 dotfiles 和 .gitignore 里列出的东西，这类请求每次都会触发审批（@philbo）
• 同样做过读权限门禁的人指出，最麻烦的边角情况是符号链接逃逸出项目根目录（@hn1rig3rak）
• 有人指出 OpenAI 早前也做过类似的事，只是手法更隐蔽（@alightsoul）
• 玩笑一条：只有用他们的工具，才能解释周末那三亿 token 是从哪来的（@mococa）