当上游连夜改名：codex-app-mirror 如何顶住 Codex 并入 ChatGPT 品牌合并的 P0 故障复盘

当上游连夜改名：codex-app-mirror 如何顶住 Codex 并入 ChatGPT 品牌合并的 P0 故障复盘

【免费下载链接】codex-app-mirror原样镜像官方 Codex 桌面应用:每 15 分钟探测、SHA256 可校验、国内直连下载、 Mac 可增量更新 | Verbatim, verifiable mirror of the official Codex desktop app — probed every 15 min, with a Sparkle delta-update feed.项目地址: https://gitcode.com/gh_mirrors/co/codex-app-mirror

codex-app-mirror 是官方 Codex 桌面应用的"原样镜像站"：每 15 分钟探测一次上游、SHA256 可校验、国内直连下载，并为 macOS 提供 Sparkle 增量自动更新源。2026 年 7 月 9 日，OpenAI 把 Codex 桌面应用原地并入 ChatGPT 品牌——文件名、显示名、包内入口全变了，但产品没变。这次"上游连夜改名"让镜像管道一夜 404 中断，本文完整复盘 codex-app-mirror 如何用三天时间定位根因、实施 Stable P0 修复，并把这次事故沉淀为可复用的防改名纪律。

一、故障现场：上游改的是"皮"，不是"骨"

2026-07-09 起，上游将 Codex 桌面应用原地并入 ChatGPT 品牌：

也就是说：发行名称、包名、可执行文件都变了，产品身份一个字节都没变。这对用户无感，对"按文件名工作"的镜像管道却是 P0。

二、根因定位：镜像站为什么会 404

故障点很快锁定：探测脚本 probe-release.sh 是按规则拼接上游文件名（Codex-${ver}-{arch}.dmg）来构造下载 URL 的。上游把前缀改成ChatGPT之后，拼出来的 URL 直接 404，整条"探测 → 比对 → 发布"链路在第一步就停摆。

更麻烦的是，这类"按规则重建上游文件名"的代码散落在管道各处，逐一排查后形成了一份改动清单（见 chatgpt-rebrand-recovery.md 的"改动位置索引"）：

• read-macos-metadata.sh：写死了$volume/Codex.app/Contents/Info.plist，修完 probe 后必现的下一处失败点；
• download-macos.sh / build-appcast.sh：各自重建 zip 保存名与 enclosure URL；
• store-link/Program.cs：ProductPrefix常量写死为OpenAI.Codex_；
• prepare-windows-portable.sh：启动器写死Codex.exe，而清单入口已是ChatGPT.exe。

教训一句话：文件名不是产品身份，任何"猜文件名"的代码都是定时炸弹。

三、修复决策 1：只认身份，不认名字

P0 契约确立了核心纪律（chatgpt-rebrand-recovery.md）：

只管理 Codex 产品血统；允许其发行名称、包名、可执行文件随合并改变；绝不纳管 ChatGPT Classic（com.openai.chat）。

身份矩阵（全部实测于 2026-07-10）：

配套落地 macOS身份门禁：镜像介质中必须恰有一个顶层.app（不再要求它叫Codex.app），且CFBundleIdentifier == com.openai.codex、Team ID 为2DC432GLL2、Sparkle EdDSA 公钥与固定值一致；com.openai.chat即使签名团队匹配也明确拒绝。这些校验逻辑就落在 read-macos-metadata.sh 中。

四、修复决策 2：manifest 双字段，源名动态读、镜像名稳住 ABI

这是本次修复最核心的架构改动：ingress 和 egress 用两套名字，各读各的权威来源。

• ingress（探测 / 下载）：只使用sourceUrl/sourceBasename，一律从权威源读取——DMG 与 zip 的文件名来自 appcast 的enclosure标签，MSIX 入口来自AppxManifest.xml的Application@Executable，包名来自 DisplayCatalog / FE3。所有"按规则重建上游文件名"的代码被删除，改造见 probe-release.sh 的 enclosure 解析段。
• egress（落盘、校验和、Release、appcast、R2 key、副镜像同步）：统一读取mirrorEnclosureBasename，保持Codex-前缀不变，避免下游短链、Release 命名一夜之间全部断裂。

manifest 中的实际形态如下：

{ "sourceBasename": "ChatGPT-darwin-arm64-26.707.31428.zip", "mirrorEnclosureBasename": "Codex-darwin-arm64-26.707.31428.zip" }

为什么镜像端敢"改名"？因为EdDSA 只签归档字节本身，不签 URL 和文件名——只要镜像与官方字节级一致，原始签名依然有效，镜像站不会也无法伪造签名。镜像名保持Codex-前缀是独立的产品决策（稳定对外 ABI），与本次故障修复解耦。

五、修复决策 3：sharedlatest是一致性单元，不许拆开切

发布侧的共享 key（latest/manifest、latest/checksums、latest/win-*、macOS appcast）会被客户端同时读取，而 R2/S3 不提供多对象事务。如果按平台各切各的，客户端可能读到"新 manifest + 旧包"的组合。因此契约 3 规定了受控切换顺序：

1. 先上传不可变对象（versioned release / 候选 manifest），不动 sharedlatest；
2. 下游客户端完成真机验证（增量更新、完整包回退、全新安装、Classic 排除等）；
3. 维护窗口内由同一次发布作业协调推进全部latestkey，完成后立即从外部逐项验证；
4. 回滚同样协调回退，不可变资产不覆盖、不删除。

副镜像同步 worker 里"重建 basename"的代码（secondary-sync/core.js）也同步改为从 manifest 读取，避免切换时两套镜像出现名字漂移。

六、复盘清单：镜像项目如何防"上游改名"

这次 P0 沉淀下来的五条通用经验，任何做"上游原样镜像"的项目都适用：

1. 用身份锚定，不用文件名锚定：bundle ID、ProductId、AppxManifest入口、签名 Team ID 才是稳定锚点（身份矩阵见 chatgpt-rebrand-recovery.md）。
2. 删掉所有"猜文件名"的代码：上游名字必须从权威源（appcast enclosure、商店元数据、清单文件）动态读取。
3. 双字段 manifest 隔离内外命名：源名随上游变，镜像名守住对外 ABI，两侧互不牵连。
4. 发布前设身份门禁：一个包能通过签名但 bundle ID 不对（如 ChatGPT Classic），照样拒绝——签名正确 ≠ 产品正确。
5. 共享可变更 key 按一致性单元切换：客户端会并发读取的多个 mutable key 必须同一次作业推进，不可变资产与可移动指针分离。

如今 codex-app-mirror 已按此契约完成 Stable P0 实施：上游再改显示名，探测端从 appcast 读到新 basename 即可照常工作，而Codex-mac-*.dmg、latest/*短链与 Sparkle 更新源对下游用户零感知。上游可以连夜改名，镜像站只认血统、不认皮。

【免费下载链接】codex-app-mirror原样镜像官方 Codex 桌面应用:每 15 分钟探测、SHA256 可校验、国内直连下载、 Mac 可增量更新 | Verbatim, verifiable mirror of the official Codex desktop app — probed every 15 min, with a Sparkle delta-update feed.项目地址: https://gitcode.com/gh_mirrors/co/codex-app-mirror