服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 研究者在 ZCode 3.12.3 中复原了 workspace 打包、服务端下发加密材料、直传对象存储与回调登记链路；本地清单显示快照可包含 .git objects、LFS、reflog、源码与配置。
- 被广泛传播的 313 MB 商业仓库快照留在 pending，并未离开研究者网络；研究者另用一个小型公开仓库得到服务端 accepted，二者不能混写成“313 MB 私库已上传”。
- 厂商被转述的 9 月 18 日说明承认早期部分用户默认启用相关能力并称已修复；研究者报告 3.14.0 移除了上传路径，当前公开仓库也未见旧管线。
- 当前开源仓库只有压平的少量提交，不能用它反推旧版本全部行为；受影响版本范围、账户数量、历史服务端清单、解密访问和逐用户删除证明仍是 UNKNOWN。
- 处置顺序应是先记录安装版本、checkpoint/state 状态、文件哈希、时间与出口日志，再更新/停用旧版；不要先删除本地目录，否则可能丢失判断 pending、failure 或 accepted 的证据。
- 是否轮换凭证要看 Git 历史与快照范围：若历史对象、配置或 LFS 含有效 secret，按泄露风险撤销和重发；不要因为没有当前工作区明文 secret 就忽略历史提交。PRODUCT_FIT=NONE：换 IP 不能撤回已上传数据或证明删除。
先看证据边界：确认存在上传链路，不等于每个私有仓库都已上传
研究者在 2026 年 9 月 18 日公开了 ZCode 3.12.3 的本地文件、反编译逻辑与请求链：客户端把工作区归档并加密，向 zcode.z.ai 获取上传凭据与公钥，再把密文直传对象存储。研究样本的明文 manifest 表明范围可包含完整 .git 历史、LFS、reflog、源码和全局 ZCode 配置；关闭两个界面设置仍未阻止旧版创建和尝试上传。
但具体仓库是否离开机器必须逐实例判断。313 MB 商业仓库样本记录了 564 次失败并留在 pending，研究者明确说它未成功上传；另一个小型公开仓库显示 accepted。GitHub #715 等用户报告可证明还有独立担忧或本地状态，不能替代厂商侧的逐账户对象清单。
版本矩阵：3.12.3、3.14.0 与当前开源树分别证明什么
3.12.3 是研究者直接复原到快照与上传管线的受影响样本。研究者随后检查 3.14.0，报告相关管线已移除且 upload-credential 路径返回 404；这支持“新版本不再走同一路径”，但不能自动证明 3.12.3 之前和之后所有构建的精确范围。
Z.ai 公开的当前 ZCode 仓库可用于审查现行代码；研究者在其中未找到旧上传端点、对象存储上传、旧加密与 Repo Wiki 管线。不过仓库历史被压平，缺少可把旧版逐提交映射到修复版的完整演进记录。正确结论是“当前开源树未见旧路径”，不是“历史行为从未存在”。
第一步：先保全本机证据，再决定更新或清理
在不再次启动旧客户端、不扩大网络流量的前提下，记录 ZCode 安装版本、最后运行时间、登录状态、受影响工作区列表，以及 ~/.zcode 下 checkpoint、state、manifest 和日志的路径、大小、修改时间与哈希。截图只作辅助；结构化文件和哈希更适合后续复核。
不要一开始就删除 pending 目录、重装系统或清空日志。先复制必要证据到受控位置并限制访问，再由安全或法务负责人决定保留期限。若机器由企业管理，还应保存代理、DNS、防火墙、EDR 或对象存储域名访问记录；没有日志时写 UNKNOWN，不能把“未找到”说成“未上传”。
第二步：区分 pending、failure 与 accepted，而不是只看文件是否存在
研究材料中的 state 字段、failureCount 与 accepted 结果提供了不同强度的证据。pending 或大量 failure 更接近“本地已打包并持续尝试”；accepted 才更接近服务端确认接收。即便本地文件后来消失，也不能据此反推云端已删除，因为客户端清理、升级和服务端生命周期可能各自发生。
把每个工作区单独列成表：版本、快照 ID、状态、失败次数、包大小、manifest 范围、最早/最后时间、相符的出口记录和证据可信度。不要用研究者的小型公开仓库 accepted 结果替代自己的账户结论，也不要把用户 issue 中的描述当成厂商侧账本。
第三步：按 Git 历史范围做凭证和知识产权风险评估
完整 .git 对象可能保留已从当前分支删除的 API key、私钥、配置、内部域名、未发布分支与 LFS 资产。对疑似被打包的仓库运行既有批准的 secret scanning 和历史审查，优先识别仍有效、权限高、可从公网使用或能横向访问的凭证；不要把秘密值复制进普通工单或聊天。
发现有效 secret 时，先撤销或轮换，再更新部署、CI 和依赖系统，并检查异常使用记录。若只有本地 pending 且出口证据支持未成功，风险可以与 accepted 分开分级，但仍应处理旧版无明确同意边界和持续重试本身。涉及客户代码、商业秘密或合规数据时，交由组织的事件响应、法务与供应商管理流程判断通知义务。
第四步：验证修复，不把厂商声明或开源当前版当删除证明
更新到组织批准的修复版本或暂时停用客户端后，用无敏感数据的测试仓库验证：不再生成旧式快照、不再请求旧 upload-credential 路径、不再直连相应对象存储上传链，并记录版本与观察窗口。禁止为了复现而把真实私库重新交给旧版本，或主动触发更多上传。
厂商被转述的说明称早期默认能力已修复、数据不留存，研究者又转述了存储桶删除和第三方检查摘要；但完整审计报告、历史对象清单、解密访问记录与逐用户删除证明在本班仍未直接公开。把这些记作厂商陈述与待确认项，不要写成独立审计已经证明所有历史数据从未保留。
停止条件、升级路径与后续复核
如果证据目录仍在变化、旧客户端仍运行、accepted 状态出现、出口日志匹配上传目标、历史中存在高价值 secret，或无法确定哪些仓库被处理，应停止日常使用并升级给内部事件响应负责人。保留时间线、哈希和原始文件访问控制，向供应商索取账户级快照 ID、接收时间、解密访问、保留/删除记录和审计报告。
若当前版本验证通过，也要在供应商重新引入 Repo Wiki、云索引、checkpoint 同步或热更新能力时提前复核。固定网络出口可以帮助组织观察允许的流量，但不能撤回历史对象、替代证据保全、授予供应商删除证明，或保证客户端未来不变。
资料来源
常见问题
研究者的 313 MB 商业仓库是否已经上传？
没有。研究者明确记录该快照失败 564 次并停留在 pending，未离开其网络；成功 accepted 的是另一个小型公开仓库。两者不能混写。
哪些 ZCode 版本被直接核验？
调查直接复原了 3.12.3 的上传管线，并报告 3.14.0 已移除该路径；当前开源树也未见旧管线。完整受影响版本范围仍未知。
升级到新版本是否就完成事件处置？
不是。升级可阻止继续走已知旧路径，但不能证明历史 accepted 对象、解密访问或删除状态。仍需核对本地状态、出口证据、Git 历史中的 secret 和供应商账户级记录。
为什么不能先删除 ~/.zcode 再排查？
该目录可能包含版本、snapshot ID、pending/failure/accepted 状态、时间与 manifest。先删会丢失判断实际范围的证据；应先受控保全，再按组织流程清理。
何时需要轮换密钥？
当疑似快照范围包含仍有效的 secret，尤其是高权限、可公网使用或能横向访问的凭证时，应按事件响应流程撤销和重发。只看当前工作区会漏掉 Git 历史对象。
更换代理或 IP 能解决历史上传风险吗？
不能。网络出口不能撤回已接收对象、证明服务端删除或修复旧客户端；它至多帮助观察和限制之后的允许流量。