ZCode Git 历史上传：从编码便利演变为信任问题

据称，ZCode 在看似限制数据收集的设置下，仍上传了一个完整的 345 MB 开发者工作区，其中包括其 Git 历史。报道所称的 ZCode Git 历史上传并不局限于为 AI 提示词选定的文件，还包含仓库对象、reflog 和缓存的大型文件，这些内容可能保留了多年来的私人工程工作。

9 月 18 日发布的一项技术调查通过 ZCode 的封闭式桌面应用追踪了这一行为。该分析称，用户登录期间，客户端创建了加密的工作区检查点，并将其传输至 Alibaba Cloud Object Storage Service。

这一发现仍属于第三方逆向工程的说法，并非 Z.ai 经独立审计后披露的信息。截至发稿时，现有官方材料并未清楚说明所称上传的范围、检查点保留方式，或用户如何阻止此类上传。

这一核实缺口本身也是故事的一部分。ZCode 推广 GLM 模型及其代理，该代理旨在理解工作区、执行命令并恢复长时间运行的任务。然而，开放权重模型并不会让周边的桌面应用变得透明。

因此，核心冲突并非 ZCode 与另一款编码助手之间的竞争，而是产品可见的隐私控制与其隐藏检查点系统被指具备的行为之间的矛盾。

ZCode Git 历史上传报告发现了什么

该调查称，ZCode 捕获的是一个仓库归档，而不只是单次模型请求所需的代码。

研究者检查了一个包含 42,411 个文件的私有商业工作区。原始目录约占 345 MB，而 ZCode 的加密检查点约为 313 MB。

报告所述内容尤其值得关注。其中约 196.1 MB 来自 .git/lfs 目录，Git Large File Storage 可在此缓存大型项目资产；另有 102.2 MB 来自 .git/objects，即 Git 用于存储文件内容、目录树和提交记录的底层数据库。

Reflog 约增加了 0.6 MB。当前源文件、配置和文档约占 46.2 MB，即所测量材料的 13.4%。

在这一单独快照中，.git 目录占归档数据的 86.6%。这并不能证明所有 ZCode 安装环境的平均情况，但它说明，将此事称为一次常规代码上传，低估了所报告的范围。

这份原始说明称，ZCode 在本地应用数据目录下创建检查点，并在加密归档旁留下明文清单。该清单据称暴露了受影响工作区的绝对路径。

根据逆向工程结果，ZCode 从一项 Z.ai 服务请求上传凭证。响应中包含对象键、已签名上传表单、大小限制和 RSA 公钥。

据称，客户端压缩工作区，使用 AES-256-CTR 对其加密，并以 RSA-OAEP-SHA256 封装对称密钥。随后，它将加密对象直接提交至一个 Aliyun 存储端点。

报告称，传输完成后，一个回调会通知 Z.ai 的后端。如果这一重建结果正确，那么上传是经过设计的应用流程，而非包含过多上下文的意外模型请求。

加密并不能解决披露问题。在实现正确的前提下，它保护的是计算机与存储服务之间的数据免受旁观者窥视。但它无法阻止预定的服务运营方访问这些信息。

报告称，匹配的 RSA 私钥始终由服务器控制。因此，提供仓库的用户无法解密并检查存储在同一台计算机上的检查点。

这一差别至关重要。“已加密”听起来可能像是“供应商无法访问”，但两者并不等同。加密对数据的保护取决于谁控制相关密钥。

报告还称，两项可见的隐私设置均未阻止检查点创建或传输。这一指控尚未通过独立产品审计得到确认，且一位 Hacker News 参与者称未找到相应的检查点目录。

这种差异可能反映产品版本、操作系统、账户状态、分阶段部署或具体功能使用情况的不同。它也可能表明，原始案例并不适用于每一位用户。

Z.ai 需要澄清这些条件。在此之前，最稳妥的表述是：研究人员已在至少一个测试环境中记录到这一行为，但其实际普遍程度仍不明朗。

为什么完整的 .git 目录比当下的代码更敏感

Git 仓库包含项目的记忆，其中包括已不再出现在当前文件中的信息。

开发者常将 .git 称为“历史记录”，但其中不只有 git log 的输出。它还存储对象、引用、分支信息、配置、reflog 及其他仓库元数据。

Git 本质上是一个内容寻址数据库。其 blob 对象保留文件内容，tree 对象描述目录状态，commit 对象则将各个快照连接为历史。

官方的 Git 对象模型说明了这些元素如何保留在 .git/objects 中。复制该目录的应用，可能获取远多于工作树中可见文件的内容。

设想一名开发者周一误提交了一项 API 凭证，周二又将其删除。当前文件已不再显示该凭证，但早先的对象仍可能通过仓库历史访问。

仅删除最新副本并不够。GitHub 关于移除敏感数据的指南建议开发者先撤销已暴露的凭证，再考虑协调进行历史重写。

同样的问题也适用于私有证书、内部主机名、客户标识符、环境文件，以及嵌入测试夹具中的凭证。仓库还可能保留已废弃的架构、安全修复、未发布产品和许可材料。

Reflog 会进一步扩大风险。它记录本地引用如何移动，并可能保留通往已不再显示在共享分支上的提交的访问路径。

本地分支可能暴露从未推送的项目计划。提交信息可能提及客户、漏洞、员工或内部事件。仓库配置则可能识别私有远程仓库和基础设施域名。

Git LFS 又引入了另一类问题。它的缓存可能包含设计文件、数据集、媒体、打包模型或其他二进制文件，而开发者有理由认为这些内容不在助手的即时上下文之内。

因此，报告所称的 196.1 MB LFS 组成部分并非无关紧要的大体量数据。它可能代表项目中最不像文本、也最具商业敏感性的材料之一。

编码代理可能确实需要广泛的本地访问权限。若不读取相关模块、运行测试或理解依赖关系，它就无法重构复杂应用。

但这种本地权限并不自动意味着，允许其为进程可访问的所有内容创建持久化云端副本。为完成请求任务而读取文件、为推理发送选定上下文，以及归档完整仓库，是彼此独立的操作。

这正是为何 ZCode Git 历史上传的说法，比“云端编码助手会处理代码”这一观察更为严重。争议涉及范围、持久性、控制权和披露。

开发者可能会知情同意一项包含某个函数及其依赖项的模型请求；同一位开发者也可能拒绝上传 LFS 缓存、已删除的凭证、闲置分支和多年来的提交对象。

企业用户还面临额外担忧。仓库中可能包含受客户合同、源代码托管条款、出口管制、数据驻留规则或员工访问政策约束的材料。

关键问题不只是是否使用了加密。安全团队需要知道收集了什么、存储在哪里、谁持有密钥、保留多久，以及如何删除。

隐私控制与检查点似乎讲述了不同的故事

最尖锐的担忧，是用户能够控制的内容与应用据称实际行为之间的落差。

ZCode 的官方文档描述了一种能够理解工作区状态、文件引用、任务和 Git 分支上下文的代理。其代理文档也将状态恢复列为支持较长开发任务的一部分。

检查点机制可以服务于正当目的。一个会编辑数十个文件的代理，需要能在变更失败后恢复、比较状态，或还原因崩溃中断的工作。

这一功能并不要求检查点必须不可见，也不能证明 .git 的每一部分都必须包含在远程归档中。

注重隐私的设计可以默认排除 Git 对象和 LFS 缓存。它可以在传输前公布精确的归档清单，将检查点保留在本地，或在云同步前请求明确批准。

它还可以提供阻止远程快照的组织策略。管理员能够强制执行仓库级排除规则，并通过审计日志确认其效果。

相反，该调查称，ZCode 的归档流程在代理可见的工具循环之外运行。据报道，代理列出的工具中并没有用户可批准的快照或上传操作。

这种架构可以解释为什么命令权限未能阻止传输。即使用户限制 shell 执行或文件修改，主机级 sidecar 也能独立于模型工具运行。

这也暴露了当前代理界面的一个盲点。权限提示通常聚焦于显眼操作，例如运行命令、编辑文件或打开网络地址。

后台服务受到的关注较少。它们可以索引文件夹、收集诊断信息、同步会话，或创建恢复工件，而不出现在对话中。

推理与同步之间的区别在这里变得重要。向云端模型发送选定代码足够直观，大多数用户会期待云端支持的助手这样做。

为回滚或索引而复制底层仓库数据库，则是第二条数据流。它需要独立的说明、范围控制、保留规则和删除界面。

ZCode 当前的隐私政策称，个人数据可在提供服务、履行义务、保护合法商业利益以及提升安全性或稳定性所需的期限内保留。该政策还称，保留期限因数据类型、敏感性、用途和法律要求而异。

这些笼统表述并未回答报告引发的问题。该政策需要说明，工作区检查点属于用户输入、技术数据还是其他类别。

它还应说明适用哪个存储区域、分包商是否处理归档，以及删除账户是否会移除所有检查点。用户需要具体的保留期限，或与相关功能相对应的明确标准。

最重要的是，Z.ai 应说明隐私开关是否会影响检查点上传。如果一个控制项标注为数据收集相关，但实际只管理分析数据而不管理工作区同步，可能会造成虚假的安全感。

控制项的措辞和位置，与其内部实现同样重要。当性质明显不同的数据流被笼统术语归为一类时，开发者就无法作出知情决定。

Z.ai 最有力的回应应当是技术性的，而非修辞性的。它应列明受影响版本、触发条件、归档排除规则、端点、加密角色、保留期限和删除流程。

它还应说明该报告发布后相关行为是否发生变化。缺少这些细节，用户无法判断一次更新是修复了问题，还是仅仅移除了本地证据。

开放权重并不意味着封闭式编码代理能在本地运行

此次事件将模型与决定模型能看到什么、以及什么数据会离开设备的软件区分开来。

GLM 模型是 Z.ai 开发者战略的核心，部分版本以开放权重形式发布。开发者可以检查这些模型文件，在自己的基础设施上运行兼容版本，并避免使用托管推理端点。

ZCode 则属于不同的层级。它是负责选择上下文、调用工具、存储会话、管理检查点、连接云服务并自行更新的运行框架。

即便底层模型在本地运行，该框架仍可决定隐私结果。本地模型并不能阻止外围应用将遥测数据、索引、会话历史或恢复快照发送到其他地方。

同样，开放模型也无法揭示一个封闭的 Electron 应用在后台进程中做了什么。研究人员必须观察网络流量、检查应用程序包，并在发布后重建其行为。

这正是核心信任冲突。ZCode 的产品体验强调对本地工作区的理解，而报告描述的云端采集机制范围比开发者预期更广。

竞争产品同样会处理开发者数据，因此正确的比较并不是“ZCode 会上传代码，而其他所有代理都只在本地运行”。这种说法并不准确。

Claude Code、GitHub Copilot、Codex、Cursor 及其他云连接工具都会将部分用户输入和代码上下文发送至远程服务。仓库索引、代理会话和云端任务环境都可能产生额外副本。

差异在于披露和控制。例如，GitHub 记录了内容排除政策，并说明某些 Copilot 功能界面不支持这些排除规则。

GitHub 还说明了在 GitHub 之外的仓库进行语义索引时何时会上传数据，并表示企业管理员必须启用该功能。这些控制仍有限制，但用户可以识别数据流并据此评估。

这正是 Z.ai 当前面对的标准。如果产品依赖云端推理，供应商并不需要承诺代码永远不会离开计算机。

但它需要准确说明每一次传输。它必须区分临时提示上下文与持久化仓库快照，并给予管理员可执行的控制权。

开源运行框架提供了一种回应方式。其代码可以揭示归档排除规则、网络端点和更新行为，而独立审查者可测试文档化设置是否与实现一致。

开源并不是完整的安全保障。很少有用户会检查每一项依赖，已签名二进制文件可能与发布代码不同，遭入侵的更新仍可能造成损害。

封闭源代码工具也并不必然恶意。它们可以接受独立评估、提供详细的数据地图、实施租户控制，并发布可验证的网络行为。

然而，不透明会提高验证成本。当应用拥有广泛的文件系统权限和自主执行能力时，这种成本就成为实质性的安全考量。

Hacker News 上的讨论反映了两种观点。一些评论者认为，任何封闭式编码运行框架都是不可接受的风险；另一些人则指出，云端代理天然会接收项目上下文。

一位用户称，尽管自己在使用 ZCode，却无法复现报告中提到的检查点目录。另一些人认为，无论供应商或国家为何，沙箱都应限制每一种专有开发者工具。

这些反应指出了两种不同的责任。供应商必须披露其数据流，而开发团队必须限制代理可访问的范围。

两种责任互不抵消。沙箱不是同意，隐私控制也不是有效隔离。

即时风险取决于仓库内容和产品版本

现有证据支持紧急审查，但并不能证明每一位 ZCode 用户都上传了相同的数据。

有文档记录的示例涉及一个工作区和一种被观察到的应用配置。公开报道尚未确定有多少安装实例创建了检查点、这种行为何时开始，或所有操作系统是否遵循相同路径。

同样不清楚的是，用户是否必须启用某项特定的恢复或索引功能。登录状态可能也很重要，因为报告将传输行为与已登录状态关联起来。

版本历史同样重要。后续版本可能会改变目录、端点、排除规则或调度行为，但这并不意味着此前的观察无效。

这种不确定性应当收窄论断，而不是阻止调查。使用 ZCode 处理过私有仓库的团队，已有足够证据开展事件审查。

他们应首先界定范围：确定哪些开发者安装了 ZCode、运行了哪些版本、何时登录，以及在这些期间哪些仓库可被访问。

接下来，应检查端点、代理、DNS、防火墙及终端检测日志，寻找与 Z.ai 和 Aliyun 服务通信的记录。本地检查点文件可能有所帮助，但其缺失并不能确凿证明没有发生传输。

组织应在卸载或更新应用前保留证据。更新可能会修改日志、存储路径或二进制文件，而这些本可帮助调查人员重建活动。

安全团队应假定，任何提交到暴露仓库历史中的凭证都需要审查。GitHub 建议轮换泄露的凭证，因为仅从最新文件中删除它并不能消除风险。

这种应对仍应保持适度。不要仅因一名开发者安装了 ZCode 就轮换所有企业凭证。应先梳理仓库，再搜索其历史，并确认哪些密钥仍然有效。

仓库所有者还应检查敏感的非机密材料。旧提交可能包含客户数据、漏洞细节、内部端点、授权资产或需要法务审查的谈判信息。

如果仓库包含受监管或受合同限制的数据，法务和合规团队应评估通知义务。答案取决于司法辖区、合同措辞、已确认的传输证据及所涉数据。

继续测试 ZCode 的开发者应将其隔离。专用虚拟机或容器可以限制可见文件系统，但网络和挂载目录仍需谨慎配置。

应使用不含真实凭证或商业历史的可弃用仓库。避免挂载主目录、SSH 文件夹、云配置、包管理凭证或无关的源代码树。

文件系统限制可以阻止检查点目录，但这是脆弱的防御措施。路径和进程可能会随更新改变，禁止写入也可能禁用恢复功能或导致应用无法运行。

网络控制则提供另一层防护。团队可以限制出站目标并记录连接尝试，但阻断必要服务可能使产品无法使用。

更安全的长期模式是使用明确的允许列表。代理只能获得范围受限的项目检出、副临时凭证，以及完成任务所需的服务。

这种方法适用于各种工程工作流，并不只针对 ZCode。任何拥有文件系统和 Shell 访问权限的自主助手，都应被视为特权开发依赖项。

目标不是根据不完整证据证明存在恶意意图，而是降低未公开行为造成的后果。

三项信号将显示 Z.ai 是否弥合了信任鸿沟

下一项检验在于，Z.ai 是否能将未公开的数据流转化为范围有限、可见且可验证的产品功能。

第一个信号是详细的公开回应。Z.ai 应确认或反驳所报告的 ZCode Git 历史上传行为，说明受影响版本，并解释由何种产品状态触发。

一份有用的声明应直接回应已测量的归档内容。它应说明是否包含 .git/objects、.git/lfs、reflog、被忽略文件和全局配置。

如果 Z.ai 仅发布“数据已加密”之类的笼统保证，核心担忧依然存在。据报道，该公司掌握解密密钥，因此传输加密并不能回答访问权或保留期限的问题。

第二个信号是可执行的检查点控制。ZCode 需要一个能够停止远程快照、可由组织管理且独立于分析或模型训练偏好的设置。

用户应能够通过日志或文档化的网络事件验证该设置。应用应在首次传输前展示其计划上传的内容。

默认排除规则应移除 .git、LFS 缓存、被忽略文件、凭证和常见密钥位置。当任务确实需要时，用户可以选择加入额外历史记录。

仅限本地的恢复选项可缓解大部分矛盾。检查点可以支持回滚，而无需成为云端归档，尤其是在代理和模型运行于同一台机器时。

第三个信号是独立复现。研究人员需要在受支持操作系统、全新和既有账户以及不同隐私配置下测试当前版本。

这项工作应回答原始行为是普遍存在、存在条件限制，还是已发生变化。它还应验证通过产品删除检查点时，是否会移除每一个服务器端副本。

第三方评估将增强 Z.ai 的回应，尤其是评估方公开范围和方法时。可复现的数据包捕获和归档清单，将比宽泛的认证措辞更有价值。

对于开发团队而言，教训不止涉及一个应用。应将编码代理作为软件供应链组件进行盘点，记录其端点，并在授予私有仓库访问权限前审查其数据流。

提出五个直接问题：代理能读取什么？它会传输什么？什么内容会在远程持久保存？谁掌握密钥？哪个控制项会停止每一次传输？

如果供应商无法回答这些问题，就应将代理限制在可弃用环境中，直到它能够作答为止。如果答案只依赖于“已加密”，就追问谁能够解密。

所报告的 ZCode Git 历史上传尚未确定每一位用户的暴露情况，也没有证明任何归档被滥用。但它已确立了一种可信的不匹配，需要得到精确回应。

Z.ai 可以通过公开该机制、修正默认设置、提供真正的关闭开关并支持独立验证来缩小这一差距。在此之前，开发者应将 ZCode 可见的工作区视为最小可能的数据收集边界，而不是最大边界。