这是一个面向 Windows 的 OpenCodex 2.7.43 非官方临时修复版，重点修复 OpenAI Responses 兼容模型在长流式响应和工具改写场景下可能出现的“上游已经返回，但 Codex 一直收不到结果或下一轮上下文中断”问题。
我之前在 OpenCodex 2.7.43 版本遇到了记忆中断的问题，现在自行进行了临时修复，希望可以帮助到大家。
本项目基于上游 lidge-jun/opencodex 的 OpenCodex 2.7.43，遵循原项目 MIT License。本仓库不是上游官方版本，也不代表上游维护者立场。
- 修复目标：Windows + Bun 1.3.14 + OpenAI Responses 流式转发中的特定挂起和连续性问题。
- 发布版本：2.7.43-memoryfix.4。
- 安装包：bitkyc08-opencodex-2.7.43-memoryfix.4.tgz。
- 安装包 SHA256：见 SHA256SUMS.txt 和 Release 附件中的校验文件。
- 最新发布目录聚焦回归：98/98 通过，0 失败；早期修复验收节点为 88/88。
- 真实 Codex → OpenCodex → Ark：源码候选 6/6 精确通过；生产验证的 memoryfix.2 TGZ 4/4 精确通过，均无重试。公开版 memoryfix.4 还修复了 Ark 版本化 URL 的错误
/v1插入和 Windows 首次安装误报。 - 90 轮压力测试没有做到 90/90 全绿：个别轮次出现模型没有按要求复述标记，或供应商主动返回不完整响应。连续性状态没有丢失，但这不能被包装成“所有供应商、所有模型都永不失忆”。
问题表面上很像“模型失忆”：请求已经发出，供应商也开始返回，Codex 却一直等不到完整回复；重开任务后，上一轮工具或响应标识还可能接不上。
最终确认，URL、密钥和请求主体都不是这次挂起的根因。真正的问题出现在 Windows 下的一条特殊 Responses 流处理路径：
- 上游 SSE 流需要被检查，以便记录真实响应状态和连续性标识。
- 返回给 Codex 的工具命名空间和 item ID 又需要改写。
- 旧实现把流拆成多个分支，再叠加多层 JavaScript 流包装。
- 在 Bun 1.3.14 的这条组合路径上，上游可以完整返回，但客户端分支可能挂住。
修复后改为统一的 eager 单读取器：
- 每段原始字节先进入 raw inspector。
- 再做面向 Codex 的 client rewrite。
- 连续性缓存始终保存上游原始 alias 和 item ID，不保存改写后的客户端值。
- 协议正常终止、已报告终止、异常失败和客户端取消分别处理。
- 缓冲上限为 8 MiB，取消后继续有限度 drain，避免把上游连接和状态提交留在半截。
完整技术复盘见 docs/FIXMEMORY_POSTMORTEM.md。
这次发布主要验证了：
- Windows x64。
- Node.js 18 或更高版本。
- 包内固定的 Bun 1.3.14。
- OpenCodex 2.7.43。
- OpenAI Responses 兼容提供商。
- Codex Desktop/CLI 经过本地 OpenCodex 代理的真实流式请求。
macOS、Linux、其他 Bun 版本及未来的 OpenCodex 版本没有完成同等强度的生产验收。上游新版本可能已经改变相关实现，不要把本补丁直接覆盖到未验证的新版本。
本 Release 的 TGZ 也是 Windows 安装载荷，不作为 macOS/Linux 通用包发布；Windows 上不会依赖 Unix 可执行权限位。
公开版还移除了上游源码中内嵌的 Google Antigravity OAuth client 凭据。若你确实使用该登录方式，需要自行设置 GOOGLE_ANTIGRAVITY_CLIENT_ID 和 GOOGLE_ANTIGRAVITY_CLIENT_SECRET；Ark、NVIDIA 及普通 API Key 提供商不受这项清理影响。
详细步骤见 Windows 安装说明。
简要流程：
- 从 Releases 下载 Windows 一键安装包并完整解压。
- 完全退出 Codex Desktop，并确认后台的 Codex app-server 已退出。
- 双击发布包中的 安装-OpenCodex修复版.cmd。
- 等待脚本完成备份、安装、启动、健康检查和桌面快捷方式创建。
- 只有在脚本明确显示成功后，再重新打开 Codex。
- 双击桌面上的 OpenCodex FixMemory 配置 快捷方式，或在终端运行：
ocx gui安装器不会内置任何供应商密钥或模型名称。密钥只应在你自己的 OpenCodex 配置界面中填写，不要写进 issue、日志或公开仓库。
普通提供商请按上游 OpenCodex 的方式配置。若使用 Ark 的 OpenAI-compatible Responses 接口，容易踩错的是 URL 拼接：
- Base URL：以 /api/coding/v3 结尾。
- Responses Path：/responses。
- 最终请求地址：Base URL 与 Responses Path 拼接后的 /api/coding/v3/responses。
不要额外添加 /v1。模型名称和 API Key 请使用你自己账号中的真实值，本仓库不提供、记录或示范任何私有值。
配置完成后运行：
ocx health --json
ocx status健康检查通过只代表代理活着，不代表某个模型的完整 SSE 流已经正确结束。最终验收应发送一次真实 Codex 请求，并确认：
- 收到了完整回答。
- SSE 出现了协议终止事件，而不只是 HTTP 200。
- Codex 进程正常退出，没有无限等待。
- 后续一轮仍能接上上一轮上下文。
一键安装器会在当前用户桌面创建 OpenCodex FixMemory 配置 快捷方式。它用于启动或确认本地代理，然后打开 OpenCodex 配置面板。
快捷方式是安装时按当前用户环境动态生成的，发布仓库不会上传任何本机生成的 .lnk 文件，也不会写死用户名或本机路径。
如果快捷方式被删除，可双击 创建-OpenCodex配置快捷方式.cmd，或直接使用：
ocx start
ocx gui如果修复版与你的环境不兼容：
- 完全退出 Codex Desktop。
- 双击发布包中的 回滚-OpenCodex官方版.cmd。
- 选择安装前自动创建的备份，或恢复到上游 OpenCodex 2.7.43。
- 运行 ocx health --json，并重新打开 Codex 验证。
完整说明及手动兜底方式见 docs/ROLLBACK.md。
| 验证项 | 结果 | 怎么理解 |
|---|---|---|
| 修复早期聚焦测试 | 88/88 通过 | 修复实现阶段的验收节点 |
| 发布目录最新聚焦测试 | 98/98 通过，312 个断言 | 补齐公开目录、OAuth 分发保护、Ark URL 与安装器回归后，使用内置 Bun 1.3.14 复跑 |
| 真实源码候选请求 | 6/6 精确通过 | Codex → 代理 → Ark，返回预期标记 |
| 生产验证 TGZ（memoryfix.2） | 4/4 精确通过，无重试 | 真实 Codex → 代理 → Ark |
| 公开 TGZ（memoryfix.4） | 隔离安装、版本、health、stop 通过 | 保留记忆修复，并加入 Ark URL 与安装器修复 |
| 全仓测试 | 5988 通过，4 跳过，6 失败 | 6 个失败是与本修复无关的 Windows 测试脚手架问题 |
| 90 轮连续性压力 | 未完全全绿 | 模型输出不完整或供应商主动 incomplete；未发现连续性状态丢失 |
这些结果说明已经修复复现出的代理挂起与状态提交问题，但不构成对任何第三方模型稳定性的保证。
- “返回 HTTP 200 就说明好了。” 不对。流可能只建立成功，却没有正常发出终止事件。
- “重启 Codex 就会加载修复。” 不对。必须先安装修复包，再重启 Codex。
- “肯定是 Ark URL 写错了。” 这次最终确认 URL 正确；URL 曾是合理怀疑项，但不是本次挂起根因。
- “Base URL 已经以
/v3结尾，OpenCodex 仍可以再补/v1。” 不对。memoryfix.4 会保留显式版本根路径；旧版曾把 Ark/api/plan/v3错拼为/api/plan/v3/v1/responses。 - “小请求通过，生产请求一定通过。” 不对。小请求可能没有触发工具命名空间和 payload rewrite 路径。
- “模型没复述标记就是代理失忆。” 不一定。还要区分模型自身输出、供应商 incomplete 和代理状态丢失。
- “把 eager relay 外面再套几层 rewrite 就行。” 仍可能保留多层流组合风险；本修复把检查、改写和失败收尾放进同一个读取器。
更多排查顺序见 完整复盘。
本项目基于 OpenCodex 2.7.43 修改。上游版权和 MIT License 均予以保留，详见 LICENSE 与 NOTICE.md。
这是社区临时修复，不是上游官方发布。若上游后续版本吸收了等价修复，优先评估迁移回上游版本。