opencodex 合并就绪评审实战：6 个补丁的判定矩阵与 Vertex 目录回退、Anthropic 刷新防重放的源码级复盘

【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载本文基于 opencodex 仓库中devlog/_fin/260722_issue_bug_sweep/040_merge_readiness_review.md这一篇合并就绪merge readiness评审记录展开。评审对象是 2026-07-22 进入 dev 分支的 6 个实现补丁覆盖 OpenAI Codex / Claude Code 的通用 provider 代理支持 Claude、Gemini、Grok、DeepSeek、Ollama 等任意 LLM 接入 Codex CLI、App、SDK 与 Claude Code。读者将掌握该仓库的评审方法论、bun run test的确定性执行约束以及两个被判定为 BLOCKER 的功能缺陷Vertex 模型目录回退缺失、Anthropic 刷新重放风险从根因、触发条件到修复与回归验证的完整链路。评审方法双 reviewer 并行 main 交叉验证 全量测试套件评审记录明确交代了本次判定的执行框架范围仅对 dev 上 6 个实现提交做合并判定新提交的 issue / PR 不在本次范围内用户指示。方法两个 sol reviewer 按集群并行独立判定main主负责人以代码交叉验证复核最后运行正式全量测试套件兜底。产物每个 issue 得到一个明确结论——✅ yes就绪、 yes-with-nits就绪但带非阻塞意见、❌ no (BLOCKER)必须进入后续修复周期。这套人机双轨评审的好处在于reviewer 判定的是该 issue 是否真正被解决这一功能缺口而非仅仅分支能否构建通过两者是独立的评价维度——这正是后文#202、#209两个补丁虽然构建绿色仍被判定为 BLOCKER 的原因。测试基线--isolate 是确定性执行的关键评审记录给出了决定性的测试基线bun run test等价于bun test --isolate ./tests/→3344 pass / 0 fail284 files78.6stscbun x tsc --noEmitexit 0。并特别标注了一个易踩的执行陷阱不使用--isolate直接运行bun test会因共享状态污染产生58 个 fail这是执行方式造成的运行产物artifact并非代码缺陷使用正式脚本bun run test则完全 green。从仓库根目录的 package.json 与 bunfig.toml 可以看出测试入口被封装为bun run test--isolate正是为了在每个测试文件之间隔离进程/模块状态避免 OAuth store、配置捕获 generationcaptureConfigGeneration等全局单例跨用例串扰。因此复现或验证该仓库测试结论时必须走bun run test这一约束对后续回归验证修复后 3353 pass同样适用。判定矩阵4 个就绪 2 个条件就绪 2 个 BLOCKER6 个提交的判定结果汇总如下完整继承原评审表Issue提交合并就绪判定依据#216fbd96c12✅ yes\b1060\b区域无关匹配在 pt-BR / Bun 下复现并解决其余路径保持 fail-closed#199fbd96c12✅ yesstatus 36 与本地化 1060 的处理lifecycle 守卫能安全区分 unknown 与 absence#212f2fa0c20✅ yesbuilt-in preset 改为 opt-in 暴露保留 reserved openai 排除、默认 false、metadata 阻断安全审查通过#1830d7fd985✅ yespending-flow 端点仅委托共享的submitManualLoginCodePKCE / state 与 raw-import 403 门禁不变#18687be0d84 yes-with-nitsmid-stream reset→failed502、cancel 无惩罚、union 不变——但存在 scope-drift nit#17987501f10 yes-with-nitseffort 可空 capability-aware 解决实效路径广泛稳定性因无法复现而防御性延期#20287501f10❌ no (BLOCKER)仅新增诊断日志实际症状未解决#209a626a5b7❌ no (BLOCKER)stale refresh-lock 存在旧 token 重发风险两个条件就绪的 nit 已在原评审的 Nit 章节点明#186的 scope-drift 是指src/server/responses.ts中属于 021 组合 effort 主管范围的supportedLadderFor混入了 030 提交虽无功能回归但建议按职责拆分为独立提交。BLOCKER B1Vertex 模型目录缺少 defaultModel 回退触发条件与影响评审记录将问题定位在快照时src/codex/catalog.ts:1243configured只由prov.models ?? []生成没有 defaultModel 回退。当 Vertex provider 只配置了defaultModel而缺少models数组时模型发现/v1/models失败后configured为空默认 Gemini 模型始终不出现在仪表盘与/v1/models响应中已有测试tests/vertex-catalog.test.ts显式传入models: [publisher-model-a]因此没有复现真实症状。源码级现状从当前仓库源码结构看该逻辑已迁移/重组至 src/codex/catalog/provider-models.ts。当前实现围绕配置的默认模型是一个真实可调用的选择器必须在兼容 provider 的实时 /models 请求失败时保持可发现这一原则注释直接关联 issue #308构建了双层兜底// configured 只来自 prov.models ?? []显式模型列表缺失时用 defaultModel 补位 const failedDiscoveryConfigured configured.length 0 || !prov.defaultModel || prov.adapter ! anthropic ? configured : [{ id: prov.defaultModel, provider: name, ...catalogHintsFromProviderConfig(...), }]; const vertexDefaultSeed seedVertexDefault ? configured[0] : undefined; const withVertexDefaultSeed (models: CatalogModel[]): CatalogModel[] ( vertexDefaultSeed !models.some(model model.id vertexDefaultSeed.id) ? [...models, vertexDefaultSeed] : models );withVertexDefaultSeed被注入所有cache 回退分支——fresh 命中、cooldown 中的 stale、非 2xx 失败后的 stale 降级provider-models.ts#L447-L499并遵循authoritative-empty 分支配对保留的语义只要结果里不存在种子模型就补入确保目录永不为空。修复与回归验证WP-fix-1评审记录记载修复提交为2e07c8bc在catalog.ts fetchProviderModels中当adaptergoogle、googleModevertex、models缺失、defaultModel存在四个条件同时满足时将defaultModel播种到configuredwithVertexDefaultSeed()覆盖 fresh / cooldown / non-2xx / malformed / thrown 五类 cache fallback并保留 authoritative-empty 分支回归测试defaultModel-only 空缓存 fresh/stale在修复前为 RED评审两轮 FAIL→PASSbun test tests/vertex-catalog.test.ts10 passtsc 0。当前仓库的 provider 注册侧也能交叉印证该模型选择策略tests/adapters/google/google-hardening.test.ts断言google-vertexprovider 的defaultModel为gemini-3-progoogle-hardening.test.ts#L772-L779说明 Vertex 默认模型是真实参与调度的选择器其目录可见性直接影响路由正确性。BLOCKER B2Anthropic stale-lock 重发已轮换 token触发条件与影响评审记录将根因锁定在src/oauth/index.ts:320附近与锁原语src/oauth/store.ts:79-85Anthropic 已消耗轮换refresh token但在mergeAccountCredential持久化之前进程退出或 120s 锁过期后续进程移除 stale 锁后重新提交旧 token→ 上游返回invalid_grant→ 账户永久进入needsReauth这既复现了 issue又违反了仓库的no-blind-replay禁止盲目重放安全不变量——因为 refresh intent 此前仅以可删除的文件锁表达缺少对已消耗/不确定 generation的 durable 记录。源码级现状generation 绑定的 durable refresh-intent从当前仓库源码看修复已在 src/oauth/store.ts 中落地为一套完整的生成期generation绑定刷新意图机制路径构造store.ts#L60-L71auth.refresh.provider.hash.lock.json其中hash是 accountId 的 SHA-256 前 24 位侧车文件不存储 token符合零泄漏设计写入store.ts#L185-L208writeOAuthRefreshIntent在配置变更锁内执行atomicWriteFile且拒绝覆盖已存在的 intentrefusing to overwrite its replay guard意图对象携带version: 1、generation64 位十六进制、attemptIdrandomUUID、可选flightId读取store.ts#L163-L173readOAuthRefreshIntent对ENOENT视为不存在其余读取/解析失败一律返回uncertain意图fail-closed解析校验store.ts#L114-L161对 generation 格式、attemptId 长度、staleOwner/uncertain/cleanupPending取值组合逐项校验不合法即降级为 uncertain。修复后的执行路径refreshAnthropicAccountWithLocksrc/oauth/index.ts#L881-L959展示了修复后的判定流程先取writerGeneration captureConfigGeneration()获取 intent 文件锁读取磁盘凭据newerClaudeCredential若已存在更新的 Claude 凭据则直接mergeAccountCredential合并并 best-effort 清理 intent——磁盘凭据已 durable清理失败不得掩盖已提交的凭据若存在同 generation 的pendingIntentcleanupPending则先恢复清理流程staleOwner直接抛OAuthTokenRefreshStaleError被替换的 stale flight 已 dispatch 则标记 staleOwner 并抛错未 dispatch 则清除 intent 后继续uncertain或同 generation 的意图 → 标记needsReauth并抛OAuthLoginRequiredError不重发 token进入真正刷新前才writeOAuthRefreshIntent并把refreshMayHaveReachedProvider true作为此后即使同步客户端错误也保守视为已 post-dispatch的分水岭刷新成功后mergeAccountCredential合并随后清理 intent。核心不变量是同一 generation 的刷新意图存在时绝不重放——要么采纳新 Claude 凭据要么要求恢复/重新登录recovery 路径中 intent 被保留以阻断重入 replay。回归验证WP-fix-2评审记录记载修复提交为0de138aa回归测试覆盖两类场景修复前均为 RED连续 2 次同 generation 刷新 →refreshCalls 0corrupt-sidecar损坏侧车→refreshCalls 0。当前仓库的 tests/oauth/oauth-refresh.test.ts 中存在多组expect(refreshCalls).toBe(0)断言且刷新函数以throw new Error(must not replay)兜底从测试侧证实了 no-blind-replay 已被固化为契约同时Nous refresh-intent pre-dispatch write failure is non-terminal等用例验证了意图写入失败时账户保持有效、不误触发刷新的降级语义。xAI 路径经非回归验证oauth 全量 45 passtsc 0。修复收尾push、CI 与剩余决策两个 BLOCKER 修复后评审记录完成了 push 与 CI 收尾项提交状态#202 Vertex defaultModel 目录回退2e07c8bc✅ 解决reviewer 2 轮 FAIL→PASS#209 Anthropic durable refresh-intent no-blind-replay0de138aa✅ 解决reviewer 2 轮 FAIL 2 项→PASSGUI lint021/022 残留i18n effort-none ref-in-render49d8062c✅ push 门禁通过storage-scanner Windows CI flaky5134ms5000ms与本次改动无关6d4cf859✅ 15s timeout 稳定化全量bun run test--isolate3353 pass / 0 failtsc exit 0push 到 origin dev49d8062c、6d4cf859pre-push 门禁lint tsc test privacy doctor全部通过CI greenCross-platform CI run 29854799555 success6/6 作业ubuntu/windows/macos npm-global ×3Service lifecycle successdev origin/dev 已同步。遗留决策dev → main / preview 的合并需等待用户批准本次范围外当前 dev 领先 origin/main 36 个提交、领先 origin/preview 38 个提交。结语评审的两种绿色本次评审最有价值的经验在于把构建绿色与issue 真正关闭分开度量#202、#209两个补丁所在分支通过了 3344 项测试与 tsc却仍因症状未解决 / 存在重放风险被判定 BLOCKER并各自走向独立的修复周期。最终修复均采用durable 状态 fail-closed 解析 回归测试先 RED 后 GREEN的模式——Vertex 侧用defaultModel播种目录、Anthropic 侧用 generation 绑定的 refresh-intent 阻断盲重放。对于同样运行多 provider 代理、多账号 OAuth 轮换与模型目录发现的读者这两条修复路径可以直接作为同构问题的参考实现。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐OmX 0.12.1 发布就绪Release Readiness全解读补丁列车范围、验证矩阵与 GO 判定依据OmX 0.12.1 发布就绪Release Readiness全解读补丁列车范围、验证矩阵与 GO 判定依据 OmXOh My codeX是面向 O人工智能AI AgentAgent 编排Agent 工作流CLI开发工具AI 技能PR Babysitter Loop 实战指南用 loop-engineering 模式自动化 PR 审查、CI 修复与合并就绪判定PR Babysitter Loop 实战指南用 loop engineering 模式自动化 PR 审查、CI 修复与合并就绪判定 导读 本文基于 pat人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务opencodex 代码评审实录Codex 自启动 ocx ensure 端口回退机制的设计与审查opencodex 代码评审实录Codex 自启动 ocx ensure 端口回退机制的设计与审查 本文基于仓库内 devlog/_fin/210_pr8 a上一篇如何利用HSTracker成为炉石传说数据驱动的大师macOS玩家的终极指南下一篇读懂 KubeSphere 依赖中的 Huff0 熵压缩zstd 压缩管线里的低层 Huffman 编解码块创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考