OpenCodex OpenAI Provider 三层硬化收尾审计：18 个 Cycle 的合并终局、13 命令门禁与 `_plan`→`_fin` 归档

OpenCodex OpenAI Provider 三层硬化收尾审计18 个 Cycle 的合并终局、13 命令门禁与_plan→_fin归档【免费下载链接】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 仓库中 OpenAI 硬化单元OpenAI Hardening的最终实现审计展开。该审计以VERDICT: PASS收尾将原本铺开为 060–180 的 18 个循环收缩为 A/B/C 三个依赖有序的收尾循环并用一套 13 命令的最终门禁、隔离运行时证明与证据隐私扫描完成闭环。读完本文你将掌握这个多层 Provider 代理项目在大范围多循环硬化工作上的收口方法论契约缺口闭合、零公网 E2E 骨架、隔离冷启动运行时证明、单一事实来源SoT同步以及可追溯的归档与门禁验收流程。审计背景为什么需要一个最终实现审计OpenCodex 是一个面向 OpenAI Codex 与 Claude Code 的通用 Provider 代理Universal provider proxy其核心能力之一是围绕 OpenAI 的 Codex 接入做多层 Provider 体系——即文档中反复出现的Direct / Multi / API 三层模型bare Direct ids、namespaced Multi/API ids。在 2026-07 的硬化周期中该单元最初被规划成000_plan.md里的 18 个循环Cycle 040–180但随后的合并审计发现提交42e958fd实际上已经实现了后来被拆成 Cycle 060–180 的绝大部分工作这 13 份文档里有 10 份是ALREADY_DONE行为已实现且有激活测试覆盖、3 份是PARTIAL070虚拟模型验证器、090max-input 校验、160路由 max-input 降低、0 份NOT_STARTED大量文档仍挂着## Status pending属于实现先于文档的历史欠账。因此190_consolidated_finish_plan.md将剩余工作合并为三个依赖有序的循环Cycle A契约缺口闭合→ Cycle B集成与隔离运行时证明→ Cycle C文档/状态/归档就绪。051_audit_wp050_implementation.md正是对这三个循环落地结果的独立最终审计审计基座为ae485f4b判定为PASS。审计范围它审的是什么、不审什么审计文档明确限定了边界051_audit_wp050_implementation.md审查对象是 190_consolidated_finish_plan.md 定义的已完成 Cycle A/B/C对照的判据账本criterion ledger在 050_integration_verification.md 中额外检查 13 命令门禁的收据evidence/050_gate_summary.txt与归档清单archive manifest关键原则不把历史规划文本重新归类为新的实现历史——也就是说审计只认落地证据不认计划里的愿望清单。这种判据→证据的一一映射是整篇审计的骨架后面会看到它如何落到每个子循环。Cycle A — 契约缺口闭合三处 PARTIAL 的真实收口审计对 Cycle A 的三项提交逐条确认核心是修正 190 文档识别出的三处文档契约与代码实现不一致070 自引用验证器激活提交df740d84激活了虚拟模型定义中的自引用用例wireModelId selectedModelId并证明畸形校验后PROVIDER_REGISTRY注册表保持不变。这对应源码 src/providers/openai-virtual-models.ts 中的validateOpenAiVirtualModelDefinition——该校验器是纯函数、fail-closed其中raw.wireModelId selectedModelId会被判定为非法并抛出InvalidOpenAiVirtualModelRegistryError因此生产代码本身早已拒绝自引用缺口只在于测试没有激活这个分支。090 max-input 所有权文档对齐max-input 的所有权文档被更新为与已落地的 safe-DTO 脱敏契约一致。所谓 safe-DTOsafeConfigDTO在 Cycle 040 的安全评审中刻意把modelMaxInputTokens从管理 API 的返回白名单里移除——max-input 仍然磁盘持久化 配置校验 路由消费但不再经/api/config回传。文档最终选择了较新的安全契约而不是把该字段重新暴露。160 路由 min-wins 边界修正审计特别强调这次闭合只限定在 routed-config 契约而不是宣称覆盖了无关的 effective-compaction 路径。API 的 context/max-input 继续采用 min-wins取注册表与配置中较小者而非 API 的注册表 Provider 保留用户覆盖与注册表填充语义。同时070、090、160三份文档各自保留了对应的 Cycle A 证据章节没有混入其他循环的结论。Cycle B — 集成与隔离运行时证明零公网 零用户状态变更Cycle B 是整场审计的技术核心提交ae485f4b落地的内容包括deny-by-default 三层 E2E 骨架tests/openai-three-tier-e2e.test.ts迁移子进程tests/fixtures/openai-three-tier-migration-child.ts真实 Codex 历史激活临时CODEX_HOME下跑真实codex exec隔离冷启动运行时冒烟scripts/openai-three-tier-runtime-smoke.ts 子进程scripts/openai-three-tier-runtime-child.ts脱敏后的证据所有者。零公网回退的拦截器设计E2E 骨架在动态 import 之前先创建全新的临时OPENCODEX_HOME、CODEX_HOME、CLAUDE_CONFIG_DIR并安装 saved-fetch拦截器。拦截器使用元组白名单精确的 loopback origin /healthz、/api/*、/v1/responses、/v1/responses/compact委托给 saved fetch精确的 ChatGPT canonical 路径/backend-api/codex/responses与/backend-api/codex/responses/compact返回合成响应精确的 OpenAI API 路径/v1/responses与/v1/responses/compact返回合成响应任何未匹配的 scheme、host、path、method 一律 throw——不存在公网回退。由于globalThis.fetch不拥有 WebSocket 握手测试使用 test-owned WebSocket factory只接受当前 loopback server 的 origin 与/v1/responses路径其余 URL 在构造前即被拒绝。E2E 覆盖矩阵来自evidence/050_e2e.json与 050 文档的执行收据场景结果Direct / Multi / API HTTP 三个 Pro 别名PASS — 6 个 HTTP case顺序真实 WSDirect → Multi → API → DirectPASS — 4 个 turnpool registry 所有权按预期进入/退出Direct / Multi / API / 代表 Pro compactPASS — 4 个 casePro 解析为 base 且所有 compact body 省略 reasoningMulti main 资格 追加账户 cooldown/failoverPASS — preseeded 配额选中追加账户mock 429 冷却后 main 接管下一 turnselected-id 管理往返PASS — disabled/subagent/injection API 均保留openai-apikey/gpt-5.6-sol-pro请求日志与持久化 usage 身份PASS — selected 的model/requestedModel保留resolvedModel为gpt-5.6-sol反向 Provider 插入顺序PASS — sidecar candidates 仍为 Direct → Multi其中的反向插入用例是对既有实现的一次审计回折fold-backsrc/providers/openai-sidecar.ts硬编码了 Direct 先于 Multi 的顺序但没有任何既有测试在反向配置 API/Multi/Direct的情况下证明它。E2E 补上了这个回归。迁移子进程备份、真实恢复、幂等迁移在独立子进程中运行与主 spine 不共享CODEX_HOME常量或进程级缓存先创建未标记的 legacy fixture含隐藏的chatgpt与一个 pool 账户启动迁移两次返回一个仅含脱敏 JSON 的结果。断言包括恰好一个no-replace备份${configPath}.pre-openai-tiers-v1.bakmode-0600真实恢复把备份复制回迁移后的临时配置断言字节一致 legacy parse/default/provider 状态还原重新迁移证明备份复用与再迁移成功二次启动幂等性。隔离运行时冒烟不碰 10100不改用户状态审计特别点名了Port 10100 未被处理——这是有意为之真实代理 PID 正承载当前会话流量重启它是自毁行为因此在 050 中被明令禁止。替代方案是两个隔离冷启动子进程子进程先清洗继承的OPENAI_API_KEY、CODEX_API_KEY、OPENCODEX_HOME、CODEX_HOME再装入临时 home 与拦截写入 mode-0600 的临时auth.json仅含 fake Codex token启动startServer后等待syncModelsToCodex验证生成的 catalog 包含openai-apikey/gpt-5.6-sol-pro合成上游发出完整的 Codex 兼容 Responses 生命周期response.created→response.output_item.added→response.content_part.added→response.output_text.delta→.done→response.completed因为src/bridge.ts的既有行为表明 Codex 在没有.done事件时不会提交消息内容输出一行 PID/version/port 就绪行后等待父进程信号关闭从不 import 或读取用户真实 home。父脚本在两个不同进程中各启动一次子进程验证/healthz、不同 PID、version、port然后异步执行真实 CLI 激活 turncodex exec --skip-git-repo-check --ignore-rules \ -C temporary-working-directory \ --model openai-apikey/gpt-5.6-sol-pro --sandbox read-only --json \ Reply exactly OCX_PROBE_OK断言turn_context.payload.model为openai-apikey/gpt-5.6-sol-pro、session_meta.payload.model_provider为openai、上游 JSON 使用gpt-5.6-solreasoning.mode: pro且没有 prompt、凭据或完整 rollout 被复制进证据。从 evidence/050_runtime_smoke.json 可以看到实际收据两个实例 version2.7.23、distinct PIDs、临时 loopback 端口Direct 以 caller 所有权解析、Multi 走 main fixture 账户、API Pro 解析为gpt-5.6-sol且reasoningMode: pro真实配置/凭据存储路径在运行前后的 SHA-256 完全一致codex-cli 0.144.4完成一次临时 home 激活 turnevidence/050_client_history.json 记录rolloutCount: 1, attempts: 1。环境净化与 live-key 三态所有 spawn 共享一个净化环境移除所有继承的OPENAI_*、CODEX_*、OPENCODEX_*变量只加入临时 home、fake fixture 凭据、OCX_SHIM_BYPASS1与非机密 fixture 准入值同时移除大写/小写HTTP_PROXY/HTTPS_PROXY/ALL_PROXY并把NO_PROXY/no_proxy精确设为127.0.0.1,localhost,::1。Live-key 检查是只读三态AVAILABLE、NOT RUN (credential unavailable)、NOT RUN (live spend not authorized)三者非 live 状态均以 exit 0 通过真实 OpenAI live 调用需要解析出 key 且显式设置OCX_ALLOW_LIVE_OPENAI_SMOKE1。本次执行是NOT RUN (credential unavailable)、零 live 调用——这是唯一的凭据门禁缺口且被锁定的计划明确允许。Cycle C — 文档、状态与归档就绪SoT 一致性与状态清扫审计确认 Cycle C 完成了三件收尾单一事实来源SoT一致README.md、docs-site 维护的模型指南与结构文档在以下事实上完全一致——bare Direct ids、namespaced Multi/API ids、精确八个 API catalog、1,050,000 context / 922,000 max input、Pro selected 与 base wire 身份、compact base-only 行为、迁移恢复、隐藏 legacychatgpt。状态清扫无残留190 判定为ALREADY_DONE的十份文档统一打上done — verified by consolidated Cycle A/B sweep, see 190 050 evidence三份 PARTIAL 文档070/090/160指向各自 Cycle A 闭合证据060–180 区间没有任何## Status仍处于 pending010–050包含终态 closeout 指针000_plan.md把 start-state 指令与 18-cycle 地图标记为历史并指向合并后的收尾计划。归档安全两个归档安全脚本接受显式 unit/evidence 路径默认先探测_plan再探测_fin历史_plan提及以归档注记呈现不重写执行历史。13 命令最终门禁逐条 exit 0门禁所有者在全部 Step-i 编辑完成后对_planunit 显式运行并原子性重新生成evidence/050_gate_summary.txt对应文件见 evidence/050_gate_summary.txtschemaVersion1verdictPASS#GateExitResult0openai-three-tier-e2e01 pass, 0 fail1cycle-020-focused0404 pass, 0 fail2cycle-030-040-tooling0232 pass, 0 fail3isolated-runtime-smoke0PASS4live-key-status0permitted unavailable state, zero calls5typescript0PASS6full-isolated-tests02,758 pass, 0 fail7privacy-scan0PASS8gui-i18n0PASS9gui-build0PASS10docs-install0PASS11docs-build0PASS12scoped-diff-check0PASS两点值得注意的诚实性处理审计文本051记录的三个计数门禁行总通过数为3,393而050_gate_summary.txt的明细为 404 / 234 / 2,760合计 3,398零失败。两处记录存在轻微出入读者应以 evidence 明细050_gate_summary.txt为准。所有构建门禁与非测试命令均 exit 0。注意full-isolated-tests使用bun test --isolate tests作为门禁命令——plainbun test基线2,734 pass / 14 个预先存在的失败11 个 OAuth-refresh 用例加 provider discovery、OAuth-status privacy、Claude passthrough logging被记录为非门禁基线这些失败先于本单元、不由 Cycle B 引起。证据工件与隐私扫描脱敏是硬约束审计确认证据区分了三类mock 集成合成上游、隔离真实客户端/运行时证明临时 home 真实codex exec、凭据不可用的 live 子门禁。四个生成工件050_e2e.json、050_client_history.json、050_runtime_smoke.json、050_gate_summary.txt加上本 PASS 审计共同满足证据扫描器的 schema。scripts/openai-hardening-evidence-scan.ts专有扫描器补充而非替代privacy:scan校验预期 JSON/text schema并拒绝绝对 home 路径、邮箱地址、bearer/API/token 形态的值、prompt 文本与未知键缺失或空输入即失败。这解释了为什么所有工件都是redacted JSON——比如050_e2e.json只保留 canonical URL 列表与 PASS 状态050_runtime_smoke.json只保留 PID/version/port 与状态哈希。GUI 运行时相关源码与 Cycle 040 字节一致git diff --quiet 9bba3605 -- gui/src src/server/auth-cors.ts src/server/management-api.ts通过因此复用 Cycle 040 的四张截图及其 SHA-256 校验值未重新打开真实用户 GUI。终态安全审查与归档决策审计的终态判定包括050 ledger 中所有非凭据门禁判据均为MET如三层公开展开与凭据隔离、Direct 不触碰 pool 状态、API 精确八 id 1.05M/922K、Pro selected/base wire 身份跨 HTTP/SSE/WS/compact/logs/usage、迁移隐藏 legacychatgpt且备份可恢复、sidecar 顺序与插入顺序无关、隔离冷启动不触碰 10100、live 状态显式、GUI 契约已验证、13 命令全过且证据脱敏无任何 live 代理重启、部署、release、tag、push 或 live 花费发生工作树中无关的删除与改动不在归档清单内必须保持排除在归档提交之外。归档决策是该 unit 作为一个目录整体从_plan移动到_fin即现在所在的devlog/_fin/260717_openai_hardening/归档提交必须包含完整 unit、对被 ignore 的 unit/evidence 文件的强制添加devlog/被 gitignore需显式git add -f以及仅限指定的 out-of-unit Cycle C 编辑移动后的 link/path 检查、focused 测试、typecheck、GUI 门禁、diff check 与 scoped status 均为强制项。源码级印证审计结论落地的实际代码审计中反复出现的几个核心机制都能在当前仓库源码中直接找到对应实现src/providers/openai-virtual-models.tsvalidateOpenAiVirtualModelDefinition是纯函数校验器对非对象、非字符串/带空白/含//自引用/非pro的reasoningMode一律抛InvalidOpenAiVirtualModelRegistryErrorapplyOpenAiVirtualModel在路由后立即把 wire model 与reasoning.mode: pro写入原始 body并把 selected id 记入logCtx.model、base id 记入logCtx.resolvedModel——这正是selected 与 wire 双身份的实现载体。src/providers/openai-tiers.ts携带OPENAI_PROVIDER_TIER_VERSION与 Direct/Multi/API 的 provider id 常量、OpenAiTierMigrationProjection迁移投影与OpenAiTierMigrationCollisionError冲突类型是三层 tier 本体与迁移逻辑的所在地也是 190 审计判定绝大多数行为早已实现的直接依据之一。文档中引用的其他实现锚点来自 190 的审计记录可循路径深入compact 身份/路由与 32 MiB 缓冲中继在src/server/responses.tsexact-eight catalog 重建与 warning 去重在src/codex/catalog.ts路由 max-input 分支在src/router.tsAPI 注册表精确八 id 与 GPT-5.6 元数据在src/providers/registry.tsusage 按 provider selectedentry.model分组、显式排除resolvedModel在src/usage/summary.ts。需要说明的是050 文档中命名的tests/openai-three-tier-e2e.test.ts、tests/fixtures/openai-three-tier-migration-child.ts、scripts/openai-three-tier-runtime-smoke.ts等文件在当前工作树中已随归档/重构演化scripts/下现存openai-hardening-live-policy.ts、openai-hardening-runtime-env.ts等同类脚本因此不应把文档中列出的文件名当作当前仍在原路径存在其权威执行证据以归档后的 evidence 工件为准。结语一次可复用的多循环硬化收口范式051审计展示的并不是某个炫技特性而是一套可复用的多循环硬化收口方法论先做合并审计把已实现但文档欠账与真缺口分开再用依赖有序的 A/B/C 三循环分别解决契约、证明与归档门禁必须逐条 exit 0 且区分 mock/real/credential-unavailable 三类证据所有证据强制脱敏并由专用扫描器把关最后以独立审计VERDICT: PASS 完整判据账本为归档放行条件。这套流程的关键收益在于任何后来的维护者都能从000_plan.md→190_consolidated_finish_plan.md→050_integration_verification.md→051_audit_wp050_implementation.md→evidence/这条链路精确还原每个目标由哪个提交、哪个测试、哪份证据闭合而不会被历史规划文本误导。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考