【免費(fèi)下載鏈接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code項(xiàng)目地址https://gitcode.com/gh_mirrors/ope/opencodex點(diǎn)擊查看免費(fèi)下載本文以 審計(jì)第三輪合成報(bào)告 為核心骨架完整還原 opencodex 項(xiàng)目中一次真實(shí)的多輪代碼審計(jì)閉環(huán)針對(duì) Cursor 適配器的三個(gè)線上缺陷會(huì)話上下文連續(xù)性丟失、resource_exhausted過(guò)度映射為 400、實(shí)時(shí)傳輸層兩個(gè)穩(wěn)定性缺口由同一審查者連續(xù)三輪審查FAIL → FAIL → GO-WITH-FIXES最終以 2 個(gè) Medium 阻塞項(xiàng)的具名修正收尾。讀完本文你將掌握審計(jì)循環(huán)AUDIT-LOOP的判定與折疊修正機(jī)制、連續(xù)上下文傳播的store:false強(qiáng)制保留方案、gRPC 錯(cuò)誤碼的 400/429 拆分語(yǔ)義以及 HTTP/2 實(shí)時(shí)傳輸?shù)膯我唤K態(tài)守衛(wèi) 兜底銷毀 有界重試加固范式并能在當(dāng)前倉(cāng)庫(kù)源碼中逐行驗(yàn)證每一項(xiàng)落地實(shí)現(xiàn)。一、背景三個(gè)根因與一次審計(jì)閉環(huán)的起因2026-07-23opencodex 從線上運(yùn)行數(shù)據(jù)~/.opencodex下的usage.jsonl、service.log、responses-state.json中定位到 Cursor 適配器的三個(gè)真實(shí)缺陷全部記錄在 000_plan.md 中根因現(xiàn)象線上證據(jù)影響面RC1 — 會(huì)話連續(xù)性在store:false下失效totalTokens呈現(xiàn) 51676 → 107 → 78 → 111177 → 3455 … 的交錯(cuò)跳變而非單調(diào)遞增的絕對(duì)上下文responses-state.json中0條含 cursor 續(xù)接狀態(tài)Codex 每個(gè)請(qǐng)求都拿到全新的conversationId攜帶前向緩存永遠(yuǎn)命中不了最終done.usage.totalTokens只剩輸出增量RC2 —resource_exhausted過(guò)度映射為 400連續(xù) 6 條 400 記錄~2s 間隔upstreamErrorCursor resource limit exceeded: Cursor Connect error resource limit exceeded: ErrorCodex 盲目重試重試預(yù)算 5 → 6 條真正的配額/速率耗盡被當(dāng)成客戶端可修復(fù)錯(cuò)誤客戶端不退避反而猛打重試RC3 — 傳輸層缺口一條 504Cursor request timed out: Cursor transport timed out before first responseservice.log中Cursor model discovery ... failed [timeout]: No response within 8000ms與 HTTP/2 會(huì)話失敗日志會(huì)話級(jí) error 無(wú)監(jiān)聽(tīng)器、超時(shí)清理只有close()沒(méi)有destroy()兜底、模型發(fā)現(xiàn)對(duì)瞬態(tài)失敗無(wú)有界重試修復(fù)被拆成依賴有序的三個(gè)階段PHASE-SPLIT-01010_phase1_conversation_continuity.mdRC1、020_phase2_resource_exhausted_classification.mdRC2、030_phase3_transport_hardening.mdRC3。而每個(gè)階段的文檔產(chǎn)出都要過(guò)同一審查者的多輪審查這就是本次合成報(bào)告的核心語(yǔ)境。二、審計(jì)循環(huán)r1 FAIL(8) → r2 FAIL(6) → r3 GO-WITH-FIXES(2)003_audit_r3_synthesis.md 記錄的判定演進(jìn)本身就是工程方法論的濃縮Round history: r1 FAIL (8) → r2 FAIL (6) → r3 GO-WITH-FIXES (2, both folded) Main-agent judgment: near-pass — all High blockers resolved by r3; the two Medium residuals are folded as concrete doc amendments above. Exit A→B per AUDIT-LOOP-01.三輪審查逐輪收斂第一輪 8 個(gè)阻塞項(xiàng)High 5 / Med 2 / Low 1集中在測(cè)試打不到真實(shí)路徑如Cursor 永遠(yuǎn)走runTurn分支通用站點(diǎn) 1824/1859 是死代碼謂詞測(cè)試?yán)@過(guò)了真實(shí)策略屬于同義反復(fù)、無(wú)終態(tài)守衛(wèi)、字節(jié)上限缺失第二輪 6 個(gè)阻塞項(xiàng)進(jìn)一步要求字節(jié)記賬必須扛住加載/重置/替換、配額提示詞必須先行拒絕、真實(shí) h2 集成測(cè)試不能數(shù)私有回調(diào)。到第三輪全部 High 阻塞項(xiàng)已解決只剩 2 個(gè) Medium 項(xiàng)被折疊為具體文檔修正詳見(jiàn)下文第三節(jié)判定達(dá)到 GO-WITH-FIXES 并按 AUDIT-LOOP-01 退出 A→B。兩個(gè)有價(jià)值的審查紀(jì)律值得單獨(dú)強(qiáng)調(diào)分別出自 001_audit_r1_synthesis.md 與 002_audit_r2_synthesis.md激活落地原則C-ACTIVATION-GROUNDING-01任何修改/測(cè)試都必須能通過(guò)真實(shí)可達(dá)的調(diào)用鏈激活杜絕為永遠(yuǎn)不會(huì)到達(dá)的分支寫死代碼。測(cè)試必須走真實(shí)策略不得繞道例如強(qiáng)制保留謂詞必須導(dǎo)出后做單元測(cè)試 服務(wù)器級(jí)真實(shí)路由鏈測(cè)試而不是用一個(gè)自定義假實(shí)現(xiàn)自己測(cè)自己。三、第三輪的兩個(gè) Medium 阻塞項(xiàng)修正方案的完整細(xì)節(jié)r3 僅剩的兩個(gè)阻塞項(xiàng)都與修正本身是否可驗(yàn)證/是否真正生效有關(guān)也是本文最值得展開(kāi)的實(shí)戰(zhàn)內(nèi)容。3.1 阻塞項(xiàng) 1Cursor 分支繞過(guò)了模型發(fā)現(xiàn)失敗冷卻窗口審查發(fā)現(xiàn)Med, ACCEPTmarkModelsFetchFailure只記錄一個(gè)時(shí)間戳src/codex/model-cache.ts當(dāng)前實(shí)現(xiàn)見(jiàn)下文而唯一的讀取方isModelsFetchCoolingDown位于 Cursor 分支之下原文定位catalog.ts:1562——Cursor 分支早已提前 return冷卻判斷對(duì)它永遠(yuǎn)不生效。后果是模型發(fā)現(xiàn)連續(xù)失敗時(shí)每一次/v1/models輪詢都要重新支付一次完整的發(fā)現(xiàn)超時(shí)最壞約 11.5 秒而不是冷卻期內(nèi)直接走 stale/靜態(tài)目錄降級(jí)。修正方案兩處對(duì)稱修改GUARD讀側(cè)在 fresh-cache 檢查之后、fetchCursorUsableModels之前加入if (isModelsFetchCoolingDown(name))判斷命中即返回與失敗后一致的 stale/configured 降級(jí)結(jié)果MARK寫側(cè)發(fā)現(xiàn)失敗路徑上調(diào)用markModelsFetchFailure(name)。激活場(chǎng)景連續(xù)兩次目錄刷新且發(fā)現(xiàn) stub 失敗——第二次不得觸發(fā)發(fā)現(xiàn)stub 調(diào)用次數(shù)保持 1。當(dāng)前倉(cāng)庫(kù)中的落地證據(jù)該邏輯在后續(xù)目錄重構(gòu)后位于 provider-models.ts。其 Cursor 分支順序?yàn)閒resh-cache 命中g(shù)etFreshCached→ 冷卻檢查isModelsFetchCoolingDown(name, undefined, undefined, authorityIdentity)命中則返回getStaleCached或 configured 的degraded結(jié)果→fetchCursorUsableModels實(shí)時(shí)發(fā)現(xiàn) → 失敗時(shí)markModelsFetchFailuremarkProviderDiscoveryFailed并回落到degraded。而 model-cache.ts 的isModelsFetchCoolingDown實(shí)現(xiàn)了審查中強(qiáng)調(diào)的authorityIdentity 按憑證隔離一個(gè)賬號(hào)的 401/404 不能決定另一個(gè)賬號(hào)沒(méi)有目錄未帶身份記錄的失敗則保持全局抑制。3.2 阻塞項(xiàng) 2假 CursorTransport 繞過(guò)實(shí)時(shí)傳輸跟蹤器rekey 無(wú)法驗(yàn)證審查發(fā)現(xiàn)Med, ACCEPT第三輪要補(bǔ)的外部模型 tool-result 輪換場(chǎng)景續(xù)接時(shí)主動(dòng)鑄造新conversationId并重排 usage 緩存在服務(wù)器級(jí) E2E 里無(wú)法通過(guò)假 transport 驗(yàn)證——因?yàn)?rekey 調(diào)用發(fā)生在 live-transport 模塊私有的跟蹤器里假 transport 根本觀察不到。修正方案最小的誠(chéng)實(shí)接縫服務(wù)器 E2E只斷言輪換 持久化鏈?zhǔn)秸?qǐng)求中 transport 收到的是新的conversationId且持久化的續(xù)接狀態(tài)存的就是這個(gè)新 IDrekey 的調(diào)用驗(yàn)證下沉到適配器層createCursorAdapter的 deps 增加可選rekeyContextUsage參數(shù)默認(rèn)綁定真實(shí)的rekeyCursorContextUsage適配器單元測(cè)試注入 spy斷言輪換路徑上它以(oldId, newId)被調(diào)用。這條修正還隱含了對(duì) 010 文檔的約束同 ID 連續(xù)只適用于 NATIVE / 非輪換請(qǐng)求外部模型 tool-result 的輪換是刻意保留的行為src/adapters/cursor/request-builder.ts鑄造新 ID連續(xù)性在那里意味著新鑄造的 ID 被持久化給下一輪。從當(dāng)前源碼看rekeyCursorContextUsage已作為導(dǎo)出函數(shù)存在live-transport.ts由cursorContextUsageTracker.rekey支撐。3.3 minor 項(xiàng)測(cè)試觀測(cè)點(diǎn)的措辭修正審查還順帶修正了一處觀測(cè)口徑集成冒煙觀察的是LiveCursorTransport.run()async iterable以恰好一次拋出的傳輸錯(cuò)誤終止而createCursorAdapter.runTurn()發(fā)射的是error 事件而非拋出——測(cè)試應(yīng)錨定傳輸層而非適配器層避免斷言錯(cuò)位。四、第三輪修正背后的傳輸加固全貌Phase 3兩個(gè) Medium 阻塞項(xiàng)實(shí)際折疊進(jìn)了 030_phase3_transport_hardening.md 的三項(xiàng)有界修改中。結(jié)合當(dāng)前 live-transport.ts 源碼其落地形態(tài)如下。4.1 單一終態(tài)守衛(wèi)createTerminalSettleropen()原本沒(méi)有settled 守衛(wèi)failAndClear直接調(diào)fail、流end獨(dú)立調(diào)finish一旦補(bǔ)上會(huì)話級(jí) error 監(jiān)聽(tīng)器就會(huì)出現(xiàn)end 遲到 session error、timeout session error雙重終態(tài)變更。審查 r2 blocker 4 進(jìn)一步指出私有回調(diào)無(wú)法從公開(kāi) API 觸達(dá)必須提取并導(dǎo)出才能單測(cè)。當(dāng)前源碼已按此落地live-transport.ts語(yǔ)義與文檔一致fail/finish 誰(shuí)先到誰(shuí)擁有終態(tài)后到者只做clearTimer安全空操作export function createTerminalSettler(hooks: { fail: (error: Error) void; finish: () void; clearTimer: () void; }): { settleFail: (error: Error) void; settleFinish: () void; settled: () boolean } { let settled false; return { settleFail(error) { if (settled) return; settled true; hooks.clearTimer(); hooks.fail(error); }, settleFinish() { if (settled) return; settled true; hooks.clearTimer(); hooks.finish(); }, settled: () settled, }; }4.2 會(huì)話級(jí) error 監(jiān)聽(tīng)與冪等終結(jié)實(shí)時(shí) transport 原先只在session.on(connect)上注冊(cè)TLS/socket/GOAWAY 會(huì)話錯(cuò)誤可能繞過(guò)失敗路徑Node 語(yǔ)義下ClientHttp2Session未處理的error甚至可能直接拋異常。修正為在failAndClear聲明后注冊(cè)this.session.on(error, ...)統(tǒng)一走settleFail。冪等性由 4.1 的守衛(wèi)保證會(huì)話錯(cuò)誤在流 end 之后到達(dá)只會(huì)記日志不會(huì)觸發(fā)第二次終態(tài)回調(diào)。4.3 首幀超時(shí)的強(qiáng)制冪等清理armTimeoutDestroyFallbackclose()會(huì)等待在途幀而死 socket 可能無(wú)視它。修正方案close()之后立即武裝一個(gè)可注入寬限期的銷毀兜底定時(shí)器默認(rèn)CURSOR_TIMEOUT_DESTROY_GRACE_MS 1_000測(cè)試可注入timeoutDestroyGraceMs縮短定時(shí)器 unref 不阻塞進(jìn)程退出。當(dāng)前源碼live-transport.tsexport function armTimeoutDestroyFallback( stream: { destroyed: boolean; destroy: () void }, session: { destroyed: boolean; destroy: () void }, graceMs: number, ): ReturnTypetypeof setTimeout { const timer setTimeout(() { try { if (!stream.destroyed) stream.destroy(); } catch { /* gone */ } try { if (!session.destroyed) session.destroy(); } catch { /* gone */ } }, graceMs); timer.unref?.(); return timer; }從當(dāng)前源碼調(diào)用點(diǎn)看超時(shí)路徑已統(tǒng)一settleFail首幀超時(shí)、Connect 幀錯(cuò)誤、意外 EOF 等均走 live-transport.ts 附近的守衛(wèi)destroy 兜底隨之冪等。4.4 有界發(fā)現(xiàn)重試先拆分transport/http再重試審查 r1 blocker 6 的洞察已完成的非 2xx 響應(yīng)此前也被歸為http若凡 http 皆重試會(huì)重試確定性的 404/503。修正分兩步拆分錯(cuò)誤類別CursorUsableModelsResult的失敗分支增加transport會(huì)話錯(cuò)誤、請(qǐng)求設(shè)置失敗、流錯(cuò)誤、連接設(shè)置失敗均在響應(yīng)前與http已完成的非 2xx確定性、不重試并列只重試瞬態(tài)RETRYABLE_DISCOVERY_ERRORS new Set([timeout, transport])每次重試都用全新HTTP/2 會(huì)話每次調(diào)用自帶http2.connect不引入連接池第二次嘗試超時(shí)上限D(zhuǎn)ISCOVERY_RETRY_TIMEOUT_MS 3_000中間加 250~500ms 隨機(jī)抖動(dòng)。當(dāng)前 live-models.ts 已完整落地結(jié)果聯(lián)合類型含transport | http等分支fetchCursorUsableModels外殼 內(nèi)部fetchCursorUsableModelsOnce當(dāng)前函數(shù)體重命名實(shí)現(xiàn)單次有界重試。延遲預(yù)算文檔顯式接受的權(quán)衡緩存未命中時(shí)最壞 ≈ 8000ms首次 ~500ms 抖動(dòng) 3000ms封頂重試≈ 11.5s已有舊目錄降級(jí)緩存吸收重復(fù)輪詢。五、前兩輪審查沉淀Phase 1 與 Phase 2 的關(guān)鍵決策r3 的通過(guò)建立在 r1/r2 的 14 個(gè)阻塞項(xiàng)全部收斂之上其中有三個(gè)決策值得隨文保留。5.1 強(qiáng)制續(xù)接只給 kiro/cursoradapterNeedsForcedContinuationrememberResponseState()在請(qǐng)求帶store:false時(shí)跳過(guò)持久化除非force:true而 Codex 對(duì)每個(gè)非 Azure HTTP 請(qǐng)求都發(fā)store:false。審查 r1 blocker 1 糾正了關(guān)鍵事實(shí)Cursor 永遠(yuǎn)走runTurn分支src/server/responses.ts:1483通用適配器站點(diǎn)1824/1859永遠(yuǎn)看不到 cursor在那里強(qiáng)制續(xù)接是死代碼。修正只替換兩個(gè)可達(dá)三元組:1537 / :1574并導(dǎo)出一個(gè)可單測(cè)謂詞export function adapterNeedsForcedContinuation(name: string): boolean { return name kiro || name cursor; }同時(shí)為強(qiáng)制保留引入字節(jié)高水位MAX_STORED_RESPONSE_BYTES 64MBmeasuredEntry唯一計(jì)算尺寸、deleteEntry唯一刪除、ensureLoaded重算尺寸、setResponseStateByteCapForTests測(cè)試接縫因?yàn)槊看卫m(xù)接擴(kuò)展都會(huì)把前序條目完整復(fù)制進(jìn)下一請(qǐng)求鏈路字節(jié)數(shù)近似平方級(jí)增長(zhǎng)——這個(gè)風(fēng)險(xiǎn) kiro 早已存在字節(jié)上限一并修復(fù)。5.2resource_exhausted的 400/429 拆分配額提示詞先行g(shù)RPCRESOURCE_EXHAUSTED通常是配額/速率耗盡只有顯式工具目錄/注冊(cè)過(guò)大文本才應(yīng)映射為 400tool_catalog_too_large。審查 r2 blocker 3 明確拒絕自由提示詞配對(duì)配額/速率提示詞必須最先拒絕然后才匹配短語(yǔ)級(jí)尺寸模式。當(dāng)前 cursor-errors.ts 已實(shí)現(xiàn)isCursorRequestTooLargeDetail配額提示詞[too many requests, quota, rate limit, rate-limit, throttl]先行拒絕classifyCursorError的分支too-large 細(xì)節(jié) →Cursor resource limit exceeded400其余resource_exhausted含裸Error尾巴、quota、limit reached→Cursor rate limit exceeded429Codex 退避、combo failover 視為瞬態(tài)。判定表如下消息樣本分類結(jié)果映射resource_exhausted: tool registration too largeresource limit exceeded400tool_catalog_too_largeresource_exhausted: request exceeds maximum allowed sizeresource limit exceeded400resource_exhausted: too many requestsrate limit exceeded429resource_exhausted while loading tool catalog: quota exhaustedrate limit exceeded429resource_exhausted: Error裸rate limit exceeded4295.3 測(cè)試接縫策略能導(dǎo)出就導(dǎo)出真實(shí) h2 只做冒煙r2 blocker 4 的結(jié)論貫穿三個(gè) PhasecreateTerminalSettler/armTimeoutDestroyFallback直接從源碼導(dǎo)出并用 fakes 做確定性單測(cè)真實(shí)本地http2.createServer()只承擔(dān)集成冒煙斷言 public 表面不做回調(diào)計(jì)數(shù)發(fā)現(xiàn)重試用同一本地服務(wù)器驗(yàn)證首擊 stall 超時(shí) → 二擊 200 → 服務(wù)器觀察到 2 個(gè)請(qǐng)求401 場(chǎng)景則只有 1 個(gè)請(qǐng)求。六、驗(yàn)證命令與可復(fù)現(xiàn)的驗(yàn)收標(biāo)準(zhǔn)整套工作的驗(yàn)證入口來(lái)自三個(gè) Phase 文檔與 000_plan.md 的 Loop specbun run typecheck bun test tests/responses-state.test.ts tests/cursor-request-builder.test.ts \ tests/cursor-protobuf-events.test.ts tests/server-combo-failover-e2e.test.ts bun test tests/cursor-errors.test.ts tests/adapter-error-inline.test.ts \ tests/request-log.test.ts tests/errors-adapter-failure.test.ts bun test tests/cursor-hardening.test.ts tests/cursor-live-transport.test.ts bun run test # 全量按 C-ACTIVATION-GROUNDING-01 整理的驗(yàn)收要點(diǎn)store:false的 Cursor 請(qǐng)求完成后previousResponseProviderState(id)?.cursor?.conversationId等于適配器實(shí)際使用的會(huì)話 ID帶previous_response_id的后續(xù)請(qǐng)求恢復(fù)同一 IDsettler 單測(cè)覆蓋 fail-then-fail / fail-then-finish / finish-then-fail / finish-then-finish鉤子恰好觸發(fā)一次clearTimer恰好調(diào)用一次destroy 兜底在destroyedfalse時(shí)對(duì) stream 與 session 都調(diào)用destroy()已銷毀則跳過(guò)發(fā)現(xiàn)重試僅對(duì)timeout/transport生效auth401與已完成的 404http不重試?yán)鋮s窗口內(nèi)第二次目錄刷新不觸發(fā)發(fā)現(xiàn)stub 調(diào)用次數(shù)為 1字節(jié)上限最舊條目被逐出、最新鏈節(jié)存活重啟重算后上限仍生效同 ID 重復(fù)記憶不重復(fù)計(jì)數(shù)。七、方法論小結(jié)什么讓這個(gè)審計(jì)閉環(huán)真正收斂從 r1 的 8 個(gè)阻塞項(xiàng)到 r3 的 2 個(gè) Medium 折疊修正收斂的本質(zhì)是三條紀(jì)律事實(shí)錨點(diǎn)不斷刷新r1 Low blocker 8所有文件/行號(hào)引用在每輪審查中重新核對(duì)例如發(fā)現(xiàn)真實(shí)調(diào)用者從discovery.ts修正為catalog.ts:1538測(cè)試接縫在文檔期就定死而非構(gòu)建期臨場(chǎng)發(fā)揮r1 blocker 7可導(dǎo)出的純函數(shù)、可注入的依賴參數(shù)、可替換的測(cè)試工廠全部先寫進(jìn)規(guī)格誠(chéng)實(shí)的最小接縫r3 blocker 2服務(wù)器 E2E 只斷言能被假 transport 觀察到的行為輪換 持久化觀察不到的 rekey 調(diào)用下沉到適配器層用 spy 覆蓋——不為可測(cè)性扭曲測(cè)試觀測(cè)點(diǎn)。這套 AUDIT-LOOP-01 模式與上述全部階段文檔、源碼落地、測(cè)試命令均可直接在倉(cāng)庫(kù)中復(fù)核階段計(jì)劃見(jiàn) 000_plan.md三輪合成見(jiàn) 001、002、003實(shí)現(xiàn)代碼可對(duì)照 live-transport.ts、live-models.ts、cursor-errors.ts、model-cache.ts 與 provider-models.ts 逐行驗(yàn)證。贊分享【免費(fèi)下載鏈接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code項(xiàng)目地址https://gitcode.com/gh_mirrors/ope/opencodex點(diǎn)擊查看免費(fèi)下載相關(guān)推薦OpenCodex Cursor 適配器修復(fù)實(shí)錄store:false 下的會(huì)話上下文延續(xù)、resource_exhausted 錯(cuò)誤分級(jí)與 HTTP/2 傳輸加固OpenCodex Cursor 適配器修復(fù)實(shí)錄store:false 下的會(huì)話上下文延續(xù)、resource_exhausted 錯(cuò)誤分級(jí)與 HTTP/2 傳opencodex PR 73 Cherry-Pick 與傳輸加固Codex/Cursor 橋接層的錯(cuò)誤分類與取消語(yǔ)義修復(fù)opencodex PR 73 Cherry Pick 與傳輸加固Codex/Cursor 橋接層的錯(cuò)誤分類與取消語(yǔ)義修復(fù) 導(dǎo)讀 本文基于 opencodexOpenCodex Cursor 適配器上下文連續(xù)性修復(fù)對(duì)抗式審計(jì) 8 大 Blocker 的裁決與源碼級(jí)修復(fù)全解OpenCodex Cursor 適配器上下文連續(xù)性修復(fù)對(duì)抗式審計(jì) 8 大 Blocker 的裁決與源碼級(jí)修復(fù)全解 本篇基于 OpenCodex 倉(cāng)庫(kù) dev創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考