【免费下载链接】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/260723_grok_build_bridge/041_receipt.mdwp4 生命周期生产加固验收回执撰写围绕「Grok Build 用户以 opencodex 为本地代理时代理生命周期内 Grok 配置如何保持确定性存在」这一核心主题展开。读完本文你将掌握ocx ensure的 live/spawned 双分支 Grok 配置重注入机制、ocx restart往返验证中暴露并修复的 service-manager stop 缺陷、以及response.heartbeat在 chat_completions 桥接中的消费决策与回归测试并能直接对照仓库源码与测试用例复现验证。背景为什么需要「生命周期生产加固」opencodex 作为通用 Provider 代理Universal provider proxy支持 Codex CLI/App/SDK 与 Claude Code 接入任意 LLM。当 Grok Build 用户把 opencodex 当作本地服务器使用时ocx start启动ocx-*模型经 fence 块注入~/.grok/config.toml此前 wp3030_grok_config_autoinject.md已完成 start/stop/eject/uninstall 路径上的配置自动注册与解注册。但ocx ensure幂等收敛命令与ocx restart是生命周期中另外两条关键路径ensure live 分支当代理已在运行时执行ocx ensure原实现src/cli/index.ts 中handleEnsure()的 live 分支只执行syncModelsToCodexinjectSystemEnvGrok 配置只在 start 路径注入——ensure 之后 fence 可能缺失ensure spawned 分支当 ensure 需要拉起子进程时父进程在/healthz响应后立即返回而子进程的 Grok 注入晚于该时刻存在readiness race审计阻塞点 1restart 往返restart 等价于handleStop → handleEnsure一旦 stop 路径在到达 strip 前抛错配置 fence 与代理都会停留在失效状态。041_receipt.md是这一加固工作的验收回执Date 2026-07-23commits8ddeab8f7c521a6c记录了三项核心验证 c1/c2/c3 及其源码与测试证据。对应规划文档为 040_production_hardening.md更早的联动计划见 000_plan.md。c1 — ensure 分支的 Grok 配置重注入live 与 spawned新增统一同步入口syncGrokConfig规划040 §1明确新建 src/grok/sync.ts镜像 src/codex/sync.ts 的依赖注入模式提供export async function syncGrokConfig( port: number, config: OcxConfig, opts: { hostname?: string; grokHome?: string } {}, deps: GrokSyncDeps { fetchAllModels: defaultFetchAllModels, injectGrokConfig }, ): PromiseGrokInjectResult其职责链为fetchAllModels(config)拉取可见模型目录 →projectGrokCatalog()生成 Grok 目录投影 →standaloneCodexRoutingTarget(port, ...)计算代理实际路由目标含 admission token 需求判断→injectGrokConfig()将 fence 块幂等写入~/.grok/config.toml。GrokSyncDeps允许测试注入 mock 的fetchAllModels与injectGrokConfig无需真实代理即可验证。syncGrokConfig返回GrokInjectResult定义于 src/grok/inject.ts字段包括ok、changed、message以及skippedReason取值no-grok-home | orphaned-marker | non-loopback。调用方可在显式ocx ensure中对ok:false以警告形式表面化审计建议 4若模型目录拉取失败则返回ok:false且不改动配置文件。hostname 选择的两个分支live 分支ensure 时代理已在运行必须使用 proxy-liveness 运行时记录的live.hostname作为 hostname 传入——config.hostname可能已漂移指向进程从未绑定的主机wildcard 绑定0.0.0.0或 IPv6::1场景下此差异会真实影响注入内容spawned 分支ensure 刚刚按当前配置拉起子进程因此使用config.hostname。syncGrokConfig内部还会根据requiresAdmissionToken决定传入opts.hostname回退config.hostname还是targetUrl.hostname并透传config.grokExcludedModels排除集与投影信息。这一 hostname 行为在测试 tests/providers/xai/grok-sync.test.ts 中有专门用例「the observed bind hostname reaches injection (ensure live branch)」覆盖分别以0.0.0.0与::1调用断言注入时使用观测到的实际绑定主机。readiness race 的解决父进程直接注入spawned 分支的审计阻塞点 1 是ensure 父进程在/healthz响应后即返回而子进程自身的 Grok 注入晚于此。修复方式是ensure 父进程在waitForProxy()成功之后直接调用syncGrokConfig(port, ...)确定性保证注入完成。由于注入是对同一 fence 块的整块替换幂等与子进程自身的注入不存在冲突。live 验证结果隔离环境 :10190041 回执记录的验证路径live 分支手动 strip fence →ocx ensure→ 日志出现 Grok Build config updatedfence 1 块恢复且live.hostname正确传递proxy-liveness 运行时记录spawned 分支ocx restartstop→ensure后父进程在waitForProxy成功后直接注入readiness race 消除既有门控确认当codexAutoStartfalse时 ensure 提前返回该行为与 Grok 无关属既有逻辑。c2 — restart 往返验证发现并修复 service-manager stop 缺陷首轮 restart 暴露的既有缺陷隔离环境中第一轮 restart 复现了一个既有缺陷非 Grok 新代码引入service-manager stop 因 home-mismatch 抛出异常该异常被升级为stopFailed→process.exit(1)导致 ensure 根本未被执行代理在死亡状态下退出。此缺陷意味着在 service-installed 环境下restart 会丢失 service persistence自动重启/登录启动保证且未托管的 child 死亡后 Grok fence 会无限期指向 dead proxy直到下一次 start/ensure 被调用。修复 commit7c521a6cstopFailed 降级为警告修复策略是保留警告但不再将 stop 失败升级为stopFailed——本地 teardown 与 ensure 与 service manager 相互独立不应因 service-stop 的 home-mismatch 阻断后续收敛。规划文档040 §2确认该缺陷属于既有ocx restart本身的缺陷而非本次新增代码restart 的完整重设计「service-installedocx restart应通过 service manager 重启并在重启后重新保证 fence」作为后续验收标准acceptance criterion另立议题。修复后的两轮往返结果修复后执行连续 2 次 restart 往返均成功旧 pid stop fence strip → 新 pid 启动 fence 1 块重注入pid 56377→57004uptime 重置确认。注意 wp4 的 live 验证前提是non-service 路径service-installed 环境的 live 复现不可行真实 launchd service 占用生产端口 :10100因此 service-installed 的 persistence 损失与 stale-fence 风险作为release-known-limitation记录于 wp5 文档并在 receipt 中明确非 service 路径前提041 回执首段「전제오딧 합의」。c3 — heartbeat 决策bridge 保留 keep-alivechat 路径不透传 raw 帧问题本质Grok 的 strict Responses 解码器遇到未知 variant如response.heartbeat会直接崩溃见 011_receipt.md 的 R2 记录而chat_completions 入站是安全的src/chat/outbound.ts 的responsesSseToChatCompletionsSse会消费response.heartbeat但绝不透传 raw heartbeat 帧——只通过ensureRole()放出「最大有效」的 Chat Completions role chunk见 src/chat/outbound.ts 的ensureRole实现与 src/chat/outbound.ts 的case response.heartbeat分支。由于自动注入路径对全部模型强制api_backendchat_completions见 030_grok_config_autoinject.md 的 fence 块示例strict-解码器崩溃路径不可达。决策与备选方案评估决定对应审计确认 6bridge 保留response.heartbeat理由是它对 codex-rs 的 keep-alive 契约最优——任一事件都会重新武装 idle 计时器、未知事件被忽略。被否决的备选方案SSE comment 形式eventsource 解析器不会将其作为事件上送codex idle 计时器无法续期存在断流风险response.in_progress在 strict 模式下需要携带完整 response 快照 payload代价过高。同时chat 入站「不透传 raw heartbeat」通过ensureRole()只放出有效 role chunkstream 与非 stream fold 均如此审计确认 src/chat/outbound.ts 的相关行。相应动作① 新增 chat 路径 heartbeat 消费回归测试② 对直接使用 responses 后端未走 chat_completions 注入路径的用户在 wp5 文档中记录 known-limitation。回归测试证据回归测试位于 tests/responses/chat-completions-endpoint.test.ts用例名即为「responsesSseToChatCompletionsSse consumes response.heartbeat without forwarding a raw frame」该文件 chat 端点测试 22 项通过断言所有 data 帧均为chat.completion.chunk绝无 raw heartbeat 帧流出。验证矩阵与质量关卡041 回执的 Verifiers 汇总验证项结果typecheckcleanprivacy scanpasstests/providers/xai/grok-sync.test.ts4 passcatalog fold、hostname override、失败表面化、幂等tests/grok-config-inject.test.ts11 passchat 端点测试22 passfull suite3721 pass / 1 fail既有 anthropic-thinking-signature full-run 环境性 flake自 wp1 起一致已 stash 验证与相邻工作包的关系wp3031_receipt.md完成 start/stop/eject/uninstall 的 fence 注入/剥离验收遗留「ensure live-proxy 分支无 Grok 重注入」——正是 wp4 c1 的输入wp5 文档承接 service-installed restart 的 release-known-limitation、responses 直连用户的 known-limitation 记录wp6 冒烟后续工作包的 live 冒烟范围。wp4 明确 out-of-scope 项包括bridge.ts 修改按 c3 决策无需变更、docs归 wp5、smoke归 wp6。关键文件索引文件角色src/grok/sync.tssyncGrokConfig统一同步入口ensure/restart 复用src/grok/inject.tsfence 块注入/剥离、GrokInjectResult、原子写入src/chat/outbound.tsresponse.heartbeat消费与ensureRolerole chunk 放出tests/providers/xai/grok-sync.test.tssync 四用例含 live hostname、幂等tests/responses/chat-completions-endpoint.test.tsheartbeat 不透传回归断言040_production_hardening.mdwp4 规划与审计阻塞点/建议原文041_receipt.md本文骨架c1/c2/c3 验收回执以上实现证据均可直接在仓库对应路径复查实测复现时建议沿用回执中的隔离手法独立GROK_HOME、非 10100 的隔离端口、dummy loopback key避免触碰生产 service 实例。赞分享【免费下载链接】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点击查看免费下载相关推荐ArduPilot EFI HFE 驱动用 Lua 脚本为固定翼接入 HFE International 发动机 CAN ECUArduPilot EFI HFE 驱动用 Lua 脚本为固定翼接入 HFE International 发动机 CAN ECU 本篇指南完整讲解 ArduPEIP-684 深度解读合约创建地址碰撞即回滚守护以太坊代码不可变性EIP 684 深度解读合约创建地址碰撞即回滚守护以太坊代码不可变性 导读 EIP 684Revert creation in case of collipwndbg ignore 命令详解精确控制断点命中次数与执行流pwndbg ignore 命令详解精确控制断点命中次数与执行流 ignore 是 pwndbg 提供的断点管理命令仅适用于 GDB 后端用于为指定编号上一篇cangjie_manifest文件结构逐行解读default.xml与cangjie.xml背后的同步机制下一篇opencodex 证据驱动的 PR 分诊与双轨 Landing 实战从 Cursor 多账号 OAuth 到文档修复的合入全流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考