【免费下载链接】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/260627_windows-80-nine-cycle/00_cycle_map.md为核心骨架完整还原一次针对 Windows 平台稳定性问题的九周期实际十个工作切片PABCDPlan → Act → Build → Commit → Document渐进式硬化作战计划。该计划把庞大的Windows 80 稳定性目标拆解为十个彼此独立、可单独验证、原子提交的补丁切片覆盖/v1/responses超时控制、passthrough 原生中继、传输生命周期日志、Windows 服务包装器、任务计划程序加固、Bun 运行时覆盖与 CLI 诊断等多个维度。读完本文你将掌握 opencodex 在 Windows 上排查代理静默停止SSE 中途卡死服务无法自愈类问题的完整方法论以及每一周期对应的源码落点、验证命令与提交粒度规范。一、计划背景与基线约束1.1 目标定义周期地图开篇明确了总目标在dev分支上执行至少九个小型、可独立验证的 PABCD 工作周期把既有的 Windows 80 稳定性计划源自 devlog/80_windows-codex-path-hardening/15_final_gpt_pro_plan.md转化为可合入的硬化补丁。每个周期必须同时产出文档证据plan 文件实现证据源码 diff验证证据测试与类型检查通过涉及源码变更的周期必须原子提交一个周期一个 commit禁止合并提交。1.2 基线状态与硬性约束计划记录了三项不能逾越的约束体现了对回归风险的显式管理不得在本目标内复活 Cursor provider 工作——避免扩大变更面保留 ChatGPT forward/pool 认证行为——认证链路是敏感路径不容破坏Windows 变更必须能从 macOS/Linux 通过静态检查与单元测试验证——开发环境与目标平台分离要求所有补丁都是平台无关的可测逻辑未经用户明确批准不得 push / reset / force。1.3 基线审计Cycle 0配套的 01_baseline_audit.md 记录了 Cycle 0 的验证方式确认计划涉及的源码与测试面真实存在。从当前仓库结构看计划中提及的src/server.ts、src/service.ts已随后续重构演进为 src/server/、src/service/ 目录但核心函数面仍可一一对应详见各周期小节。基线验证命令可在任意周期开始前复跑git status --short --branch bun test tests/oauth-status-privacy.test.ts tests/cli-help.test.ts tests/config.test.ts bun x tsc --noEmit计划明确注明若devlog/目录被 git 忽略则 Cycle 0 无需源码提交仅记录cli-jaw goal update证据即可。二、九个源码/文档变更周期的完整切片Cycle 1 —/v1/responses请求超时禁用钩子问题Bun 服务器默认对请求设有超时Windows 上安静的 SSE 长连接容易因超时被中途掐断。方案仅对 HTTP POST/v1/responses显式禁用请求超时/api/*、/healthz、静态 GUI、/v1/models与 WebSocket 升级路径一概不动。计划给出的核心辅助函数如下export function disableResponsesRequestTimeout(req: Request, server: PickServer, timeout | undefined): boolean { try { server?.timeout(req, 0); return !!server; } catch { return false; } }要点有三借助fetch(req, server)的第二个请求级 server 参数拿到timeout能力fail closed当运行时不存在该 API 或调用抛错时返回false且不向上抛异常避免在不支持的运行时上连带崩溃仅在url.pathname /v1/responses且非 WebSocket 升级时调用。验证bun test tests/server-auth.test.ts tests/bridge-lifecycle.test.tsbun x tsc --noEmit建议提交fix(windows): disable responses request timeout。接受标准长连接工作开始前有超时禁用钩子管理/静态/模型/WebSocket 行为零变化。Cycle 2 — Passthrough 原生中继包装器防护问题原生 ChatGPT/OpenAI Responses passthrough 的 SSE 响应体被trackStreamLifetime(nativeBody, turnAc)再次包装而该包装本身是一个 async-pull 生命周期流在 Windows 热路径上引入了不必要的二次拉取层。方案在relaySseWithHeartbeat(...)上增加可选生命周期参数把包装替换为注册/回调options?: { onStart?: () void; onDone?: () void }passthrough 分支从const trackedNative trackStreamLifetime(nativeBody, turnAc); return new Response(trackedNative, ...)改为registerTurn(turnAc); const nativeRelay relaySseWithHeartbeat(nativeBody, upstream, 15_000, terminalRecorder, { onDone: () unregisterTurn(turnAc), }); return new Response(nativeRelay, ...)最终形态可用onStart代替预注册但必须避免在 passthrough SSE 分支使用trackStreamLifetime。非 passthrough 的桥接流仍保持 track 语义。从源码佐证看当前仓库 src/server/responses/passthrough-delivery.ts 的 passthrough 交付路径中仍存在trackStreamLifetime包装如 L340、L901而 src/server/chat-native.ts 的注释也明确警惕再加一层 trackStreamLifetime 包装在 bundled Bun#32111 上不安全——这印证了该周期要解决的真实风险。registerTurn/unregisterTurn/trackStreamLifetime的实现位于 src/server/lifecycle.ts。验证bun test tests/passthrough-abort.test.ts tests/shutdown-drain.test.ts tests/server-auth.test.ts typecheck。要求onStart 读入时调用一次、onDone 在正常 EOF 与 cancel 时各调用一次、cancel 仍能中止上游。Cycle 3 — 传输关闭日志Transport Close Logging问题Windows 用户报代理停了但请求日志无法区分是流正常结束、失败、不完整还是被客户端取消。方案扩展RequestLogEntry新增两个字段terminalStatus?: ResponsesTerminalStatus; closeReason?: terminal | client_cancel | non_stream;在addFinalRequestLog(...)与responseWithDeferredRequestLog(...)中非流响应记录{ closeReason: non_stream }SSE 正常终止记录{ closeReason: terminal, terminalStatus: status }客户端取消记录{ closeReason: client_cancel }并以 HTTP 499 返回。红线日志中不得出现 prompt 内容、工具参数、API Key、token 或 Authorization 头请求 id、provider、model、流开始、首个上游字节、终止状态、客户端中止、上游中止、关闭分类是允许项。该周期是token-safe 生命周期证据原则的第一次系统化落地。验证bun test tests/request-log.test.ts tests/server-auth.test.ts tests/passthrough-abort.test.ts typecheck并在/api/logs中可区分 SSE 终止与客户端取消。Cycle 4 — Windows 服务日志路径与包装器启动证据问题通过任务计划程序Task Scheduler启动的服务没有任何持久化的启动/运行时身份日志出问题无从查起。方案本周期刻意只做包装器启动身份不做调度器 XML 与子进程退出策略在 src/service/ 相关实现中导出确定性的 Windows 服务日志路径辅助函数计划中命名为serviceLogPath()并在buildWindowsServiceScript(...)生成的包装器中写入OCX_SERVICE_LOG变量启动 Bun 之前先追加以下 token-safe 启动行时间戳、Bun 路径、CLI 路径、OPENCODEX_HOME、CODEX_HOME、配置目录/日志路径子进程 stdout/stderr 重定向到同一日志文件只允许输出 token 文件路径绝不输出 token 内容本身。验证tests/service.test.ts断言包装脚本包含OCX_SERVICE_LOG赋值、启动标记、Bun/CLI/CODEX_HOME/OPENCODEX_HOME 标签、子命令追加日志、且无原始OPENCODEX_API_AUTH_TOKEN值。Cycle 5 — Windows 子进程退出与状态诊断目标捕获子进程退出/重启决策并把服务日志路径暴露到ocx service status/ocx status。要点子进程 stdout/stderr 或退出码追加进服务日志ocx service status无需管理员命令即可显示日志路径通过serviceStatusSummary()与既有ocx status流程暴露诊断信息不改动服务生命周期语义。验证bun test tests/service.test.ts tests/cli-help.test.ts typecheck建议提交fix(windows): expose service diagnostics。Cycle 6 — 任务计划程序设置加固Scheduler XML / 参数问题裸的schtasks /create标志存在默认执行时限与电池策略风险代理可能在笔记本上被意外停止。方案用显式的 Windows 任务设置替换裸标志。当前仓库 src/service/windows-taskxml.ts 的buildWindowsTaskXml已落地该方向的完整形态计划中称为若 XML 或 PowerShell 任务定义比 schtasks 标志更稳定则采用之关键 XML 片段RunLevelLeastPrivilege/RunLevel MultipleInstancesPolicyIgnoreNew/MultipleInstancesPolicy DisallowStartIfOnBatteriesfalse/DisallowStartIfOnBatteries StopIfGoingOnBatteriesfalse/StopIfGoingOnBatteries ExecutionTimeLimitPT0S/ExecutionTimeLimit RestartOnFailure.../RestartOnFailure即ExecutionTimeLimit设为PT0S无限执行时限重启间隔与次数成对设置电池策略放开不在电池状态下停止实例策略IgnoreNew防止重复拉起保留ocx service stop的语义显式停止后不得被调度器立即复活权限保持LeastPrivilegeLIMITED不做提权。该文件同时提供taskXmlRunLevelAcceptable等健康检查函数windowsTaskRegistrationHealthy会验证 XML 中是否确实包含MultipleInstancesPolicyIgnoreNew与ExecutionTimeLimitPT0S为注册状态提供可编程校验。验证tests/service.test.ts断言生成的参数含加固标志、仍保持 LIMITED 权限、路径带引号且 shell-safetypecheck 通过。Cycle 7 — Bun 运行时覆盖与身份Runtime Override问题Windows 用户可能因 bundled Bun 损坏而无法启动需要一条逃生通道。方案支持OPENCODEX_BUN_PATH或命名清晰的对等变量作为覆盖路径对无效覆盖路径大声拒绝fail loudly记录 bundled 与 override 运行时选择。当前仓库 src/lib/bun-runtime.ts 已把该能力实现为单一事实来源模块durableBunPath()/durableBunRuntime()解析 bundled Bun经bunnpm 依赖 oven/bun-*平台包 postinstallinstall.js并定义了运行时来源枚举override | bundled | process与来源标记环境变量OCX_BUN_RUNTIME_SOURCE/OCX_BUN_RUNTIME_PATH。二进制真实性校验依赖 src/lib/bun-binary-validator.mjs 的isRealBunBinary(...)。值得强调的是标记成对校验逻辑reportedBunRuntimeSource()只有同时满足来源值在允许清单内且记录路径与process.execPath一致时才返回来源否则诚实报告 unknown——避免在服务重启后给出自信的错误答案。验证bun test tests/bun-runtime.test.ts tests/service.test.ts typecheck建议提交fix(windows): support bun runtime override。Cycle 8 — PID 清理健壮性问题Windows 上 PID 身份检查命令行校验失败时显式 stop/uninstall 可能无法清理。方案状态/报告仍保持严格身份校验但清理走宽松路径对 status/reporting 保留严格身份校验防止误杀同名进程对显式 stop/uninstall若 PID 文件存在但命令行检查失败执行安全的 best-effort 清理并在日志中记录不确定性仅当需要分离 PID 读取辅助函数时才改 src/config/如 src/config/process-state.ts 中的getPidPath/readPid。验证bun test tests/process-control.test.ts tests/service.test.ts tests/uninstall.test.ts typecheck建议提交fix(windows): make explicit pid cleanup resilient。Cycle 9 — Clone GUI 开发体验与 CLI 现势化Currentization问题bun run dev只起后端代理、不提供/的 GUI 页面且 CLI 缺少年份/状态面板造成用户困惑。要点版本命令新增ocx -v、ocx --version、ocx version且不产生任何配置变更。当前仓库 src/cli/root.ts 已实现--version/-v/version的统一解析入口能力声明位于 src/cli/capabilities.ts。脚本/文案拆分package.json中把后端代理与 GUI 开发/构建语义分开README 说明bun run dev暴露/healthz、/v1/responses、/api/*GUI 用ocx gui打包版或cd gui bun dev前端开发。根路径回退GET /在没有内置 GUI 时应给出精确的 clone/dev 指引。状态现势化状态面板应安全标记过期的、不支持的 OAuth 配置计划提到c560b54之后的既有能力并结合 Cycle 7/8 输出运行时与 PID 信息——当前 src/cli/status.ts 已展示Runtime:与 PID 文件相关输出能力如pidFile、readPid()、运行时解析印证了该周期的验收形态。建议提交本周期允许拆两个原子提交git commit -m feat(cli): add version diagnostics git commit -m docs(dev): clarify clone gui workflow验证bun test tests/cli-help.test.ts tests/server-auth.test.ts tests/oauth-status-privacy.test.ts typecheck并可用rg -n bun run dev|cd gui|proxy API README.md README.ko.md README.zh-CN.md docs-site/src/content/docs/getting-started/installation.md复核文档改动范围仅当公开快速上手文案变化时才改 README 系列。三、每个周期之后的强制停机规则Stop Rules周期地图最后给出了所有源码变更周期的统一出口纪律这是该计划与普通任务清单的本质区别运行聚焦测试与类型检查bun x tsc --noEmit以cli-jaw goal update记录文档、实现、验证三份证据原子提交重新进入 PPlan阶段开始下一周期。同时明确两条禁止项未经显式请求不得 push不得把多个周期折叠进一个宽泛提交——这正是每个周期可独立验证的提交粒度保障。四、九个切片背后的共同设计原则把十个周期放在一起看可以提炼出 opencodex 平台硬化方法论的四条主线原则体现周期关键落点最小爆炸半径C1、C2仅动/v1/responses路径管理/静态/模型/WebSocket 零变化fail closed / fail loudlyC1、C7超时 API 缺失时静默降级返回 falseBun 覆盖路径无效时大声拒绝token-safe 可观测性C3、C4日志只含身份/生命周期字段绝不含密钥与正文状态与动作分离C5、C7、C8诊断面板只读不启动代理显式清理与严格身份校验分层五、局限与后续参考计划明确记录了一次审计限制cli-jaw dispatch --agent Backend因Not logged in失败Cycle 0 仅采用本地静态审计作为兜底证据——说明计划对证据类型是诚实标注的。本文引用的源码文件如 src/server/lifecycle.ts、src/service/windows-taskxml.ts、src/lib/bun-runtime.ts、src/cli/status.ts、src/server/responses/passthrough-delivery.ts均为当前仓库实际存在的实现是验证各周期验收标准的最佳阅读材料配套周期计划文档位于 devlog/_fin/260627_windows-80-nine-cycle/上游完整计划见 devlog/80_windows-codex-path-hardening/15_final_gpt_pro_plan.md。赞分享【免费下载链接】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 Kiro 网关对齐硬化路线图从 P0 流终止到 P2 可观测性的完整加固指南opencodex Kiro 网关对齐硬化路线图从 P0 流终止到 P2 可观测性的完整加固指南 导读 本文基于 opencodex 仓库中 KiroAWSSlate v2 的 ScrubberApi 硬切从全局可变诊断钩子到内部 formatDebugValue 格式化器Slate v2 的 ScrubberApi 硬切从全局可变诊断钩子到内部 formatDebugValue 格式化器 本文围绕 Plate 所依赖的 Sla前端富文本UI组件opencodex 跨平台部署稳定性加固生命周期、活跃探测与运行中更新的闭环实践opencodex 跨平台部署稳定性加固生命周期、活跃探测与运行中更新的闭环实践 本篇技术指南围绕 opencodexUniversal provider创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/23 11:36:59 · 阅读 1.2k opencodex Windows 稳定性硬化九周期 PABCD 实战路线图：从 Responses 超时钩子到 CLI 诊断的渐进式加固
【免费下载链接】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/260627_windows-80-nine-cycle/00_cycle_map.md为核心骨架完整还原一次针对 Windows 平台稳定性问题的九周期实际十个工作切片PABCDPlan → Act → Build → Commit → Document渐进式硬化作战计划。该计划把庞大的Windows 80 稳定性目标拆解为十个彼此独立、可单独验证、原子提交的补丁切片覆盖/v1/responses超时控制、passthrough 原生中继、传输生命周期日志、Windows 服务包装器、任务计划程序加固、Bun 运行时覆盖与 CLI 诊断等多个维度。读完本文你将掌握 opencodex 在 Windows 上排查代理静默停止SSE 中途卡死服务无法自愈类问题的完整方法论以及每一周期对应的源码落点、验证命令与提交粒度规范。一、计划背景与基线约束1.1 目标定义周期地图开篇明确了总目标在dev分支上执行至少九个小型、可独立验证的 PABCD 工作周期把既有的 Windows 80 稳定性计划源自 devlog/80_windows-codex-path-hardening/15_final_gpt_pro_plan.md转化为可合入的硬化补丁。每个周期必须同时产出文档证据plan 文件实现证据源码 diff验证证据测试与类型检查通过涉及源码变更的周期必须原子提交一个周期一个 commit禁止合并提交。1.2 基线状态与硬性约束计划记录了三项不能逾越的约束体现了对回归风险的显式管理不得在本目标内复活 Cursor provider 工作——避免扩大变更面保留 ChatGPT forward/pool 认证行为——认证链路是敏感路径不容破坏Windows 变更必须能从 macOS/Linux 通过静态检查与单元测试验证——开发环境与目标平台分离要求所有补丁都是平台无关的可测逻辑未经用户明确批准不得 push / reset / force。1.3 基线审计Cycle 0配套的 01_baseline_audit.md 记录了 Cycle 0 的验证方式确认计划涉及的源码与测试面真实存在。从当前仓库结构看计划中提及的src/server.ts、src/service.ts已随后续重构演进为 src/server/、src/service/ 目录但核心函数面仍可一一对应详见各周期小节。基线验证命令可在任意周期开始前复跑git status --short --branch bun test tests/oauth-status-privacy.test.ts tests/cli-help.test.ts tests/config.test.ts bun x tsc --noEmit计划明确注明若devlog/目录被 git 忽略则 Cycle 0 无需源码提交仅记录cli-jaw goal update证据即可。二、九个源码/文档变更周期的完整切片Cycle 1 —/v1/responses请求超时禁用钩子问题Bun 服务器默认对请求设有超时Windows 上安静的 SSE 长连接容易因超时被中途掐断。方案仅对 HTTP POST/v1/responses显式禁用请求超时/api/*、/healthz、静态 GUI、/v1/models与 WebSocket 升级路径一概不动。计划给出的核心辅助函数如下export function disableResponsesRequestTimeout(req: Request, server: PickServer, timeout | undefined): boolean { try { server?.timeout(req, 0); return !!server; } catch { return false; } }要点有三借助fetch(req, server)的第二个请求级 server 参数拿到timeout能力fail closed当运行时不存在该 API 或调用抛错时返回false且不向上抛异常避免在不支持的运行时上连带崩溃仅在url.pathname /v1/responses且非 WebSocket 升级时调用。验证bun test tests/server-auth.test.ts tests/bridge-lifecycle.test.tsbun x tsc --noEmit建议提交fix(windows): disable responses request timeout。接受标准长连接工作开始前有超时禁用钩子管理/静态/模型/WebSocket 行为零变化。Cycle 2 — Passthrough 原生中继包装器防护问题原生 ChatGPT/OpenAI Responses passthrough 的 SSE 响应体被trackStreamLifetime(nativeBody, turnAc)再次包装而该包装本身是一个 async-pull 生命周期流在 Windows 热路径上引入了不必要的二次拉取层。方案在relaySseWithHeartbeat(...)上增加可选生命周期参数把包装替换为注册/回调options?: { onStart?: () void; onDone?: () void }passthrough 分支从const trackedNative trackStreamLifetime(nativeBody, turnAc); return new Response(trackedNative, ...)改为registerTurn(turnAc); const nativeRelay relaySseWithHeartbeat(nativeBody, upstream, 15_000, terminalRecorder, { onDone: () unregisterTurn(turnAc), }); return new Response(nativeRelay, ...)最终形态可用onStart代替预注册但必须避免在 passthrough SSE 分支使用trackStreamLifetime。非 passthrough 的桥接流仍保持 track 语义。从源码佐证看当前仓库 src/server/responses/passthrough-delivery.ts 的 passthrough 交付路径中仍存在trackStreamLifetime包装如 L340、L901而 src/server/chat-native.ts 的注释也明确警惕再加一层 trackStreamLifetime 包装在 bundled Bun#32111 上不安全——这印证了该周期要解决的真实风险。registerTurn/unregisterTurn/trackStreamLifetime的实现位于 src/server/lifecycle.ts。验证bun test tests/passthrough-abort.test.ts tests/shutdown-drain.test.ts tests/server-auth.test.ts typecheck。要求onStart 读入时调用一次、onDone 在正常 EOF 与 cancel 时各调用一次、cancel 仍能中止上游。Cycle 3 — 传输关闭日志Transport Close Logging问题Windows 用户报代理停了但请求日志无法区分是流正常结束、失败、不完整还是被客户端取消。方案扩展RequestLogEntry新增两个字段terminalStatus?: ResponsesTerminalStatus; closeReason?: terminal | client_cancel | non_stream;在addFinalRequestLog(...)与responseWithDeferredRequestLog(...)中非流响应记录{ closeReason: non_stream }SSE 正常终止记录{ closeReason: terminal, terminalStatus: status }客户端取消记录{ closeReason: client_cancel }并以 HTTP 499 返回。红线日志中不得出现 prompt 内容、工具参数、API Key、token 或 Authorization 头请求 id、provider、model、流开始、首个上游字节、终止状态、客户端中止、上游中止、关闭分类是允许项。该周期是token-safe 生命周期证据原则的第一次系统化落地。验证bun test tests/request-log.test.ts tests/server-auth.test.ts tests/passthrough-abort.test.ts typecheck并在/api/logs中可区分 SSE 终止与客户端取消。Cycle 4 — Windows 服务日志路径与包装器启动证据问题通过任务计划程序Task Scheduler启动的服务没有任何持久化的启动/运行时身份日志出问题无从查起。方案本周期刻意只做包装器启动身份不做调度器 XML 与子进程退出策略在 src/service/ 相关实现中导出确定性的 Windows 服务日志路径辅助函数计划中命名为serviceLogPath()并在buildWindowsServiceScript(...)生成的包装器中写入OCX_SERVICE_LOG变量启动 Bun 之前先追加以下 token-safe 启动行时间戳、Bun 路径、CLI 路径、OPENCODEX_HOME、CODEX_HOME、配置目录/日志路径子进程 stdout/stderr 重定向到同一日志文件只允许输出 token 文件路径绝不输出 token 内容本身。验证tests/service.test.ts断言包装脚本包含OCX_SERVICE_LOG赋值、启动标记、Bun/CLI/CODEX_HOME/OPENCODEX_HOME 标签、子命令追加日志、且无原始OPENCODEX_API_AUTH_TOKEN值。Cycle 5 — Windows 子进程退出与状态诊断目标捕获子进程退出/重启决策并把服务日志路径暴露到ocx service status/ocx status。要点子进程 stdout/stderr 或退出码追加进服务日志ocx service status无需管理员命令即可显示日志路径通过serviceStatusSummary()与既有ocx status流程暴露诊断信息不改动服务生命周期语义。验证bun test tests/service.test.ts tests/cli-help.test.ts typecheck建议提交fix(windows): expose service diagnostics。Cycle 6 — 任务计划程序设置加固Scheduler XML / 参数问题裸的schtasks /create标志存在默认执行时限与电池策略风险代理可能在笔记本上被意外停止。方案用显式的 Windows 任务设置替换裸标志。当前仓库 src/service/windows-taskxml.ts 的buildWindowsTaskXml已落地该方向的完整形态计划中称为若 XML 或 PowerShell 任务定义比 schtasks 标志更稳定则采用之关键 XML 片段RunLevelLeastPrivilege/RunLevel MultipleInstancesPolicyIgnoreNew/MultipleInstancesPolicy DisallowStartIfOnBatteriesfalse/DisallowStartIfOnBatteries StopIfGoingOnBatteriesfalse/StopIfGoingOnBatteries ExecutionTimeLimitPT0S/ExecutionTimeLimit RestartOnFailure.../RestartOnFailure即ExecutionTimeLimit设为PT0S无限执行时限重启间隔与次数成对设置电池策略放开不在电池状态下停止实例策略IgnoreNew防止重复拉起保留ocx service stop的语义显式停止后不得被调度器立即复活权限保持LeastPrivilegeLIMITED不做提权。该文件同时提供taskXmlRunLevelAcceptable等健康检查函数windowsTaskRegistrationHealthy会验证 XML 中是否确实包含MultipleInstancesPolicyIgnoreNew与ExecutionTimeLimitPT0S为注册状态提供可编程校验。验证tests/service.test.ts断言生成的参数含加固标志、仍保持 LIMITED 权限、路径带引号且 shell-safetypecheck 通过。Cycle 7 — Bun 运行时覆盖与身份Runtime Override问题Windows 用户可能因 bundled Bun 损坏而无法启动需要一条逃生通道。方案支持OPENCODEX_BUN_PATH或命名清晰的对等变量作为覆盖路径对无效覆盖路径大声拒绝fail loudly记录 bundled 与 override 运行时选择。当前仓库 src/lib/bun-runtime.ts 已把该能力实现为单一事实来源模块durableBunPath()/durableBunRuntime()解析 bundled Bun经bunnpm 依赖 oven/bun-*平台包 postinstallinstall.js并定义了运行时来源枚举override | bundled | process与来源标记环境变量OCX_BUN_RUNTIME_SOURCE/OCX_BUN_RUNTIME_PATH。二进制真实性校验依赖 src/lib/bun-binary-validator.mjs 的isRealBunBinary(...)。值得强调的是标记成对校验逻辑reportedBunRuntimeSource()只有同时满足来源值在允许清单内且记录路径与process.execPath一致时才返回来源否则诚实报告 unknown——避免在服务重启后给出自信的错误答案。验证bun test tests/bun-runtime.test.ts tests/service.test.ts typecheck建议提交fix(windows): support bun runtime override。Cycle 8 — PID 清理健壮性问题Windows 上 PID 身份检查命令行校验失败时显式 stop/uninstall 可能无法清理。方案状态/报告仍保持严格身份校验但清理走宽松路径对 status/reporting 保留严格身份校验防止误杀同名进程对显式 stop/uninstall若 PID 文件存在但命令行检查失败执行安全的 best-effort 清理并在日志中记录不确定性仅当需要分离 PID 读取辅助函数时才改 src/config/如 src/config/process-state.ts 中的getPidPath/readPid。验证bun test tests/process-control.test.ts tests/service.test.ts tests/uninstall.test.ts typecheck建议提交fix(windows): make explicit pid cleanup resilient。Cycle 9 — Clone GUI 开发体验与 CLI 现势化Currentization问题bun run dev只起后端代理、不提供/的 GUI 页面且 CLI 缺少年份/状态面板造成用户困惑。要点版本命令新增ocx -v、ocx --version、ocx version且不产生任何配置变更。当前仓库 src/cli/root.ts 已实现--version/-v/version的统一解析入口能力声明位于 src/cli/capabilities.ts。脚本/文案拆分package.json中把后端代理与 GUI 开发/构建语义分开README 说明bun run dev暴露/healthz、/v1/responses、/api/*GUI 用ocx gui打包版或cd gui bun dev前端开发。根路径回退GET /在没有内置 GUI 时应给出精确的 clone/dev 指引。状态现势化状态面板应安全标记过期的、不支持的 OAuth 配置计划提到c560b54之后的既有能力并结合 Cycle 7/8 输出运行时与 PID 信息——当前 src/cli/status.ts 已展示Runtime:与 PID 文件相关输出能力如pidFile、readPid()、运行时解析印证了该周期的验收形态。建议提交本周期允许拆两个原子提交git commit -m feat(cli): add version diagnostics git commit -m docs(dev): clarify clone gui workflow验证bun test tests/cli-help.test.ts tests/server-auth.test.ts tests/oauth-status-privacy.test.ts typecheck并可用rg -n bun run dev|cd gui|proxy API README.md README.ko.md README.zh-CN.md docs-site/src/content/docs/getting-started/installation.md复核文档改动范围仅当公开快速上手文案变化时才改 README 系列。三、每个周期之后的强制停机规则Stop Rules周期地图最后给出了所有源码变更周期的统一出口纪律这是该计划与普通任务清单的本质区别运行聚焦测试与类型检查bun x tsc --noEmit以cli-jaw goal update记录文档、实现、验证三份证据原子提交重新进入 PPlan阶段开始下一周期。同时明确两条禁止项未经显式请求不得 push不得把多个周期折叠进一个宽泛提交——这正是每个周期可独立验证的提交粒度保障。四、九个切片背后的共同设计原则把十个周期放在一起看可以提炼出 opencodex 平台硬化方法论的四条主线原则体现周期关键落点最小爆炸半径C1、C2仅动/v1/responses路径管理/静态/模型/WebSocket 零变化fail closed / fail loudlyC1、C7超时 API 缺失时静默降级返回 falseBun 覆盖路径无效时大声拒绝token-safe 可观测性C3、C4日志只含身份/生命周期字段绝不含密钥与正文状态与动作分离C5、C7、C8诊断面板只读不启动代理显式清理与严格身份校验分层五、局限与后续参考计划明确记录了一次审计限制cli-jaw dispatch --agent Backend因Not logged in失败Cycle 0 仅采用本地静态审计作为兜底证据——说明计划对证据类型是诚实标注的。本文引用的源码文件如 src/server/lifecycle.ts、src/service/windows-taskxml.ts、src/lib/bun-runtime.ts、src/cli/status.ts、src/server/responses/passthrough-delivery.ts均为当前仓库实际存在的实现是验证各周期验收标准的最佳阅读材料配套周期计划文档位于 devlog/_fin/260627_windows-80-nine-cycle/上游完整计划见 devlog/80_windows-codex-path-hardening/15_final_gpt_pro_plan.md。赞分享【免费下载链接】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 Kiro 网关对齐硬化路线图从 P0 流终止到 P2 可观测性的完整加固指南opencodex Kiro 网关对齐硬化路线图从 P0 流终止到 P2 可观测性的完整加固指南 导读 本文基于 opencodex 仓库中 KiroAWSSlate v2 的 ScrubberApi 硬切从全局可变诊断钩子到内部 formatDebugValue 格式化器Slate v2 的 ScrubberApi 硬切从全局可变诊断钩子到内部 formatDebugValue 格式化器 本文围绕 Plate 所依赖的 Sla前端富文本UI组件opencodex 跨平台部署稳定性加固生命周期、活跃探测与运行中更新的闭环实践opencodex 跨平台部署稳定性加固生命周期、活跃探测与运行中更新的闭环实践 本篇技术指南围绕 opencodexUniversal provider创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考