【免费下载链接】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 项目 2026-07-23 的 issue 分诊第二轮Issue Triage R2工作记录系统拆解一次典型的问题快照 → 源码核对 → 分桶归类 → 修复草图完整流程从 15 个开放 issue 中确认 2 个可直接修复的缺陷#315 配额窗口分类错误、#311 影子调用拦截模型失配并将 1 个 Windows 平台 RAM 泄漏#314归因于上游 Bun 运行时。读者可从中掌握 opencodex 的 issue 处置方法论、配额窗口语义模型、影子调用拦截机制以及如何用源码证据替代主观判断。一、R2 分诊的工作范围与流程R2 分诊对应仓库记录 devlog/_fin/260723_issue_triage_r2/000_plan.md处理的是截至 2026-07-23 晚间新积累的一批开放 issue基线为origin/dev af973e54。任务被拆成两条并行工作线主线直接调查 #314Windows 11 上 v2.7.31 的 RAM 泄漏标注bug怀疑是 Windows 侧运行时泄漏Sol 并行线对其余 issue 逐一分类、对照当前dev验证、提出下一步处置建议。流程上有两条硬性纪律值得任何开源项目维护者借鉴GitHub 只读全程用gh issue view读取记录不评论、不打标签、未经批准不关闭任何 issue先源码后结论每个分类都必须给出代码指针作为证据而不是凭 issue 标题推测。最终输出三个单元000_plan.md计划与结论摘要、010_sol_triage_lanes.md逐 issue 分类明细、020_issue314_memleak.md内存泄漏专项调查。二、开放 issue 快照与分桶体系R2 覆盖 15 个开放 issue。分诊的核心产出是把每个 issue 归入四类桶bucket桶决定处置优先级桶含义处置方式A当前dev上可行动actionable直接修复 补测试B信息不足needs-info维持标签等待报告人补充抓取C上游追踪upstream-tracking保持标签等待上游变更D路线图/搁置roadmap/park归入独立设计或后续项目各 issue 的初始快照与最终分桶结论#标题分桶结论315Codex Auth: primary_window 月度被显示为周度A确认配额窗口分类 bug可在dev修复314RAM leakWin11, v2.7.31C偏上游Bun 1.3.14 Windows 运行时泄漏附带可行缓解线311Shadow call 拦截与 Codex 0.145.0 (gpt-5.6-luna) 失配A确认影子源模型匹配器过时可修复294Claude 账户池 parityD项目级功能需专门设计周期290V2 自定义父模型 spawn_agent 参数为空B报告人未回复所需抓取维持 needs-info252Claude Code 子代理占位显示 SonnetD展示型 UX 增强非路由缺陷241路由模型缺失于 Desktop pickerC客户端侧过滤保持 upstream-tracking208原生 /v1/chat/completions 端点D已由 PR #279 跟踪实现201TRAE providerD等待官方契约保持 roadmap178Factory providerD属 agent 执行后端非普通推理177Warp providerD属 agent 执行后端非普通推理95多用户托管 / LiteLLMD租户隔离属项目级保持 roadmap92V2 跨 provider NEW_TASK 丢失CCodex 客户端加密导致保持 upstream-tracking42Session 用量存储页DPhase 1 已落地破坏性清理属后续路线图分桶判定的价值在于可行动的缺陷A 类必须用源码定位到具体行为而非停留在看起来像 bug。下面两节分别展开两个 A 类缺陷的完整证据链。三、A 类缺陷一#315 月度配额窗口被错误分类为周度3.1 报告现象用户报告 Codex Auth 的primary_window主窗口明明应按月度展示界面却按周度渲染。Sol 线对照源码后判定为A 类确认可行动的 bug。3.2 根因按字段位置推断语义而非按窗口时长证据链指向配额解析模块 src/codex/quota.ts该模块对 WHAM 窗口的处理长期只建模used_percent与reset_at上报载荷里的limit_window_seconds窗口时长被类型丢弃codexQuotaWindowForPlan()见 src/codex/quota.ts#L114-L116只通过计划名判断 30 天窗口其余一律按周度处理其结果把 Team 账户 30 天的主窗口值写进weeklyPercent/weeklyResetAt前端 gui/src/components/QuotaBars.tsx 的周/月双渲染路径只是下游受害者。根因假设很明确WHAM 改变了窗口的语义排布而 opencodex 用字段位置 狭窄的计划名例外推断语义没有使用载荷自带的窗口时长。一个 2,628,000 秒约 30 天的primary_window必然被判成周度——因为周/月的分界根本不看时长。有趣的是窗口常量在 src/codex/quota.ts#L38-L55 已经存在MONTHLY_WINDOW_MIN_SECONDS为 28 天、WEEKLY_WINDOW_MIN_SECONDS为 24 小时且代码注释明确警告短于 24 小时的窗口是突发窗口burst window不是周度配额——说明项目对窗口时长的语义判断已有先例只是解析类型没有把时长字段纳入分类依据。这为 #315 的修复提供了现成的阈值常量。3.3 修复草图继承原计划在共享 WHAM 窗口类型上增加可选limit_window_seconds若测试夹具需要可加reset_after_seconds主窗口显式时长 ≥ 28 天时分类为月度时长缺失时保留现有周度回退保证向后兼容若主窗口为月度且存在副窗口则保留副窗口作为周度来源保留现有 tertiary 月度回退并定义两个月度来源同时存在时的确定性优先级补充回归用例604,800 秒主窗口周度、2,628,000 秒主窗口月度、月度主窗口 周度副窗口、legacy tertiary、缺失时长兼容。GUI 无需重写即可正确显示月度条。现有解析器测试覆盖起始于 tests/codex-routing.test.ts 与 tests/rate-limit-reset-credits.test.ts但当前生产类型无法表达报告中的时长需先扩展类型再补测试。四、A 类缺陷二#311 影子调用拦截无法匹配 gpt-5.6-luna4.1 报告现象Codex 0.145.0 将后台辅助调用helper/shadow call的模型切换为gpt-5.6-luna后opencodex 的影子调用拦截不再命中导致这些调用绕过了配置的替代模型。4.2 根因源模型标识被硬编码为过时 slug证据链旧的dev实现原 src/server/responses.ts 的拦截段以parsed.modelId.startsWith(gpt-5.4-mini)作为拦截门槛gpt-5.6-luna/gpt-5.6-terra永远进不了改写路径公开配置契约同样过时——类型文档把该设置描述成单纯的gpt-5.4-mini重定向测试目录中缺少聚焦的影子源模型匹配回归用例。根因假设功能引入时把辅助模型身份以字面量嵌入代码Codex 0.145.0 更换辅助模型家族后opencodex 没有一个集中的源模型集合 兼容谓词来吸收这一变化。4.3 当前仓库已落地修复的印证值得说明的是分诊报告写于旧的文件结构而当前仓库的快照已经完成了该方向的改造可以作为修复草图的落地样例来对照集中式源模型定义位于 src/lib/shadow-call.ts#L10DEFAULT_SHADOW_SOURCE_MODELS [gpt-5.6-luna]注释明确说明 Codex 0.145.0 使用gpt-5.6-luna、0.144.x 及更早使用gpt-5.4-mini并支持通过sourceModels覆盖恢复旧前缀拦截判定isShadowSourceModel()src/lib/shadow-call.ts#L44-L47按前缀匹配且对带/的路由化模型 ID 硬排除——显式路由选择不会被劫持shouldInterceptShadowCall()还叠加了替代目标与源同 provider模型前缀则跳过的防自拦截逻辑请求改写发生在 src/server/responses/request-prepare.ts先经resolveComboId解析替代模型命中 combo 才置shadowCallIntercepted同时记录被改写的源前缀用于日志脱敏类型契约 src/types/config.ts#L740-L752 已同步更新默认拦截gpt-5.6-luna并保留对旧客户端的sourceModels前缀覆盖选项。这正好验证了 Sol 线修复草图的正确性① 集中保守谓词/默认集合保留旧 slug 加入新 sluggpt-5.6-terra需运行时抓包确认为辅助调用才加入② 提供sourceModels配置覆盖③ 更新类型文档并补充请求级回归测试已知辅助 slug 被改写、无关前台模型不被改写、effort 强制为low。4.4 相关机制补充影子调用拦截是 opencodex 的特色能力Codex 后台自动触发的辅助调用如 web search、图像处理旁路会按配置重写到替代模型。仓库中相关证据还包括退役模型迁移逻辑 src/codex/retired-model-migration.ts将存储的gpt-5.4-mini迁移到gpt-5.6-luna避免搜索/视觉 sidecar 与池预热遭遇 404以及适配器侧对gpt-5.6-luna推理 effort 档位的支持如 src/adapters/cursor/effort-map.ts。理解这条调用链有助于排查配置了拦截却不生效类问题——先确认客户端版本对应的辅助模型 slug 是否在sourceModels覆盖集合内。五、C 类偏上游#314 Windows 11 RAM 泄漏专项调查5.1 报告证据报告人 BuSung-dev 在 2026-07-23 提交Windows 11 上运行 ocx 2.7.31单个Bun进程 RSS 高达23,419 MB占 89% 内存CPU 2.1%、网络仍有 2.2 Mbps 活动且正常使用一段时间后就会涨。报告仅有任务管理器截图无日志、无 provider/model 信息、无配置。5.2 应用侧审计排除自研结构调查先对应用侧所有长生命周期内存结构做无界增长排查详见 020_issue314_memleak.md存储结构文件边界requestLog 环形缓冲src/server/request-log.tsMAX_LOG_SIZE200溢出即shift()usage 调试行src/usage/debug.ts200 行responses 状态src/responses/state.ts1h TTL 每次访问触发 prune快照单条 2MiB / 总计 24MiB 上限usage.jsonl 读取src/usage/log.ts窗口式读取启动时不整文件载入模块级 Map/Setconfig/catalog/oauth 等warn-dedupe 集合与静态 allowlist受配置规模约束SSE 中继路径src/server/relay.ts采用基于 pull 的ReadableStream直通 cancel 中止热点路径无TransformStream管道、无整响应体累积GUI 对/api/usage的轮询解析结果不保留、可被 GC。结论应用侧不存在能涨到 23GB 的无界结构。5.3 上游证据Bun 1.3.14 的 Windows 泄漏画像opencodex 当前将 Bun 锁定为1.3.14package.json engines 与全部 CI 工作流。与本次画像吻合的已知上游 Bun issueoven-sh/bun#28035fetch().body流管道背压传播失效代理复现实验中 RSS 达到13.5 GB而客户端仅以 1 MB/s 消费——与 opencodex长生命周期的 localhost 流式代理形态完全一致oven-sh/bun#26321Windows 下Bun.file().stream()RSS 增长被关闭为 #17228 的重复项特征是 JS 堆平稳而原生 RSS 增长 → 原生缓冲问题非 JS GC 可回收oven-sh/bun#18488≥1.1.27 的 fetch 流式泄漏2026-01-13 关闭Bun v1.3.12 修复了 fetch 处理器 Promise 在客户端断开后永不 settle 的Bun.serve()泄漏说明此类 Windows/HTTP 路径 bug 在 Bun 上反复出现Bun v1.4.0 自带数据重复工作负载下 RSS 从 6.7 GB 降至 609 MB对比 1.3.14oven-sh/bun#32585来自 opencodex 用户的既有报告——Bun 1.3.14 在 Windows 11 长跑 opencodex localhost 代理时段错误报告人改用 canary Bun 1.4.0 后代理稳定。这独立佐证了 1.3.14-on-Windows 在相同负载下的运行时不稳定。5.4 分类与缓解建议判定为C 类偏上游Windows 上的 Bun 运行时问题但存在我方可控的缓解线向报告人索取信息process.memoryUsage()的 rss vs heapUsed 随时间曲线heapUsed 平稳 RSS 上升 ⇒ 原生泄漏坐实 Bun 侧以及所用 provider/model、是否与流式密集会话相关可行动的缓解评估将锁定的 Bun 1.3.14 升级到 1.4 稳定版截至 2026-07-23 稳定版最新仍是 1.3.141.4.0 仅在 canary 通道需bun upgrade --canary。由于 Bun 版本固定触及 CI/发布自动化和三平台发布纪律需走 MAINTAINERS.md 规定的安全审查线security-review lane#32585 报告人已验证 1.4.0 canary 稳定了同样的代理负载可选诊断设施新增轻量/api/debug/memoryrss/heapUsed/external端点让 Windows 报告人自行区分原生泄漏与 JS 泄漏。该单元仅做调查不做代码变更后续是否落地 Bun 版本升级由安全审查线决定。六、B/D 类处置逻辑与验证纪律6.1 B 类#290 自定义父模型 spawn_agent 参数为空证据报告人自 2026-07-23 维护者要求提供四边界抓取入站additional_toolsschema、翻译后的 provider schema、原始 provider 参数、发出的 Responses 参数事件后一直未回复。tests/multi-agent-compat.test.ts 已覆盖真实 Desktop 的additional_tools输入形态确认工具定义可达src/bridge.ts#L547-L565 会把每个 providertool_call_delta字节追加进参数缓冲——这支持零字节到达的兼容性结论但无法定位字节在何处丢失。在边界抓取到位前无法区分客户端 schema 缺失、翻译丢失、provider 结构化工具限制或模型自身行为故维持needs-info。6.2 D 类代表性结论#294 Claude 账户池 parity现有代码只有单条 Anthropic OAuth 流src/oauth/anthropic.ts与 provider 注册src/oauth/index.ts多账户池是 Codex 专属src/types/config.ts 与 gui/src/components/CodexAccountPool.tsx 均注明 Codex 池。Claude 侧没有池协调器、亲和存储、配额打分器或仪表盘属于需要专门设计周期的项目级功能不是小补丁#95 多用户托管/LiteLLM传输层在共享部署中可行但租户可信隔离不存在——当前池状态是进程级的src/codex/quota.ts 是进程级账户配额 Map。租户身份、隔离、授权策略、归因、并发保证横跨认证/日志/账户状态/管理 API/GUI应按先租户与安全模型 数据隔离清单启动项目#92 V2 跨 provider NEW_TASK 密文src/responses/parser.ts 将encrypted_content对路由模型视为不透明并以[encrypted content omitted]替代——代理无法解密从未跨越自身边界的纯密文保持upstream-tracking是正确处置README 亦推荐 V1 做可靠的跨 provider 委派#42 存储页只读 Phase 1 已落地src/storage/scanner.ts 以不可变 SQLite 访问避免 WAL/SHM 写入src/server/management-api.ts 暴露GET /api/storage破坏性的清理/删除属 Phase 2 路线图需 preview-first、默认 quarantine、锁安全与专属破坏路径审查。6.3 验证纪律本分诊全程遵守用gh issue view n --json title,body,labels,comments读取全部 13 条活跃 issue确认分支codex/260723-issue-triage-r2及基线提交只做源码检查、不运行测试因未改代码零 GitHub 变更不改 issue、标签、评论。后续获批的工作阶段依次为① #315 修复 测试② #311 修复 测试③ Bun 版本升级 spike在 CI 之后进行。七、总结可复用的分诊方法论回顾本轮 R2可以提炼出一套可复用的维护工作流快照冻结基线提交列出全部开放 issue 与标签分桶用 A可行动/B需信息/C上游追踪/D路线图四桶强制分类防止看起来像 bug混入确认是 bug源码锚定每个分类至少一个代码指针A 类必须给出根因假设与修复草图、测试清单上游归因留痕对疑似运行时/客户端问题引用上游 issue 编号与自测数据避免把外部问题算到应用头上零变更纪律分诊本身不碰 GitHub改动决策留给后续获批的工作阶段。对于 opencodex 的维护者与贡献者而言这两类 A 缺陷的教训同样适用于日常提交语义判定应读取数据本身携带的字段如窗口时长而非依赖字段位置或硬编码 slug跨版本兼容的标识符模型名、协议版本应集中为可配置集合而非散落字面量。相关源码入口配额解析 src/codex/quota.ts、影子调用拦截 src/lib/shadow-call.ts 与 src/server/responses/request-prepare.ts、分诊全记录见 devlog/_fin/260723_issue_triage_r2/。赞分享【免费下载链接】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 三缺陷修复实录315 配额窗口误判、311 影子调用拦截失效、252 子代理占位模型误导opencodex 三缺陷修复实录 315 配额窗口误判、 311 影子调用拦截失效、 252 子代理占位模型误导 opencodex 是一个面向 OpenAopencodex Issue 修复闭环WHAM 配额窗口分类、Shadow-Call 源模型集与子代理占位模型治理opencodex Issue 修复闭环WHAM 配额窗口分类、Shadow Call 源模型集与子代理占位模型治理 本文基于 opencodex 仓库 deopencodex Issue Triage 实战13 个 GitHub Issue 的分级研判、源码定位与处置路径opencodex Issue Triage 实战13 个 GitHub Issue 的分级研判、源码定位与处置路径 导读 本文基于 opencodex 开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
