10/19 傍晚续报：会话里带过网页搜索，Codex 的远程压缩就 502；压缩失败的真实错误又被吞掉
这一小时四仓无新版本：CLIProxyAPI 上长会话只要带过网页搜索，远程压缩就报 502 且这条会话救不回来；sub2api 的压缩失败事件还缺了模型名，客户端看不到真实错误；另有一张把「禁用并行工具调用」翻成允许并行的补丁在评审，codex2api 的 Work 模式另有新单。
这一小时（北京 15:29 到 16:24）四个仓库都没发新版本，四条主干也一条没动。
窗口里落了四件事：CLIProxyAPI 一条长会话压缩报障，sub2api 两张补丁（压缩失败事件、并行工具开关），codex2api 一条 Work 模式的 bug 单。
最急的是第一条。会话里带过网页搜索，远程压缩就过不去，这条会话只能换掉。
#6770：会话里带过网页搜索，远程压缩就 502
报障单在北京 16:10 开出，0 评论、无标签，还没有维护者回复1。
环境写得很全：Codex Desktop 26.1013.40934 / CLI 0.163.0-alpha.10.2，Windows 11，模型
gpt-6.1-sol，上下文窗口 272,000。前面挂的就是 CLIProxyAPI。
会话跑到约 22.2 万输入 token、里面含 2 条
web_search_call 时，自动压缩失败。unexpected status 502 Bad Gateway: response protection is unavailable
上游回的错误体是
{"error":{"message":"response protection is unavailable","type":"internal_error",...}}。同一个模型、同一条凭证，短请求照常成功；换新会话、把
web_search 设成 disabled，也不再出现。报障人附的社区抓包给出方向：失败的压缩请求重放了
web_search_call，工具声明却是空数组。补一条
web_search 声明，同一个请求就过了。他还列了两条上游相关单 #51962 与 #52016。代理侧有没有漏这一步，本刊在 v8.0.33 整包里核了五处。
压缩在 CPA 里有专用入口。路由单独注册了
/v1/responses/compact，执行器带 Alt: "responses/compact" 走 executeCompact，最后 POST 到上游的 {base}/responses/compact2。出发前只做了一组字段处理：删
stream 与 store。再删
prompt_cache_retention、prompt_cache_options、max_output_tokens、max_completion_tokens、temperature3。
v8.0.33 的
codex_executor_execute.go 第 255–272 行：第 262 行按 SIWC 规则删字段，第 265–267 行做并行工具、工具 schema 与多智能体工具的归一化，第 269 行才拼出 {base}/responses/compact。整段没有一步去看 tools 里缺什么。它不给缺声明的请求补一条，也不把没有声明的搜索项摘掉。
「重放项还在、声明没了」这种形状，仓里有现成的处置，但只给多智能体委派项准备：
RewriteCodexOrphanDelegationInput 会把它改写成一条 user 消息，还要开一项兼容开关5。搜索项没有对应实现。报障人的方向在代理侧成立：压缩请求把带
web_search_call 的历史原样送上去，工具声明是空的，上游按内部错误拒掉。那个 502 是代理自己给的。
codexTerminalFailureStatus 先看 error.status_code 与 error.status，没有就把 error.type、error.code 逐条比对；internal_error 不在任何一条分支里，落进 default 返回 5026。
v8.0.33 的
codex_executor_terminal.go 第 178–203 行：第 188 行的 cyber_policy 走 400、第 196 行的限流走 429，而报障人拿到的 internal_error 落在第 200–201 行的 default，被翻成 502。这个状态码的形状来自上游返回的内部错误。重启、换凭证、查网络都不会让它变好。
今天能做的三条：
- 要跑长会话就把
web_search关掉，报障人验证过这条路。 - 到 22 万输入 token 之前手动开新会话；压缩一旦 502，同一会话再试还是它。
- 遇到这个 502 直接按上游内部错误登记。
状态：单还开着、0 评论、没有修复 PR；dev 头停在北京 12:26（
3bbd1652），窗口内没动。#8217：压缩失败的真实错误，客户端看不到
第二件事是同一处压缩的另一半。
PR 在北京 15:58 开出，3 个文件 +18/−4、一个提交、mergeable 干净，未合并7。
作者的说法：压缩的 SSE 心跳已经把响应头提交成 200 之后，上游再报错就只能以
response.failed 终止事件回传，而这个事件里没有 response.model。严格客户端反序列化失败，真实的上游错误就显示不出来。v0.2.17 里确实是这样。压缩流桥接写这个事件时只有
type、sequence_number，以及 response 下的 id、object、created_at、status、output、error8。
v0.2.17 的
openai_compact_stream_bridge.go 第 107–134 行：注释解释了为什么 created_at 必须写（第 122–123 行），字段表里没有 model。两条路差的就是这一个字段。
补丁从请求上下文取原始模型名，转发时做过映射也保留公开名；取不到上下文时该字段仍然写出来。作者注明
Refs #8147，并说报障单里没有原始响应帧，不能确认就是同一次触发。对值班的影响是：压缩失败时客户端可能只报「流在 response.completed 之前关闭」，或者干脆重连。真实错误要去 ops 错误看板或服务端日志里找，这条路径自己会往看板记一笔。
发行版没有这个修复，今天看到的还是旧行为。
#8218：客户端要求一次只出一个工具调用，转出去变成允许并行
16:17 开出的 #8218 是另一类：语义在桥接时被改掉。
3 个文件 +188/−2、一个提交、mergeable unstable，未合并10。
两个桥都把
parallel_tool_calls 写死成 true：Anthropic 转 Chat Completions 的桥在第 111–112 行置常量11，Anthropic 转 Responses 的桥在第 53–54 行同样置常量12。
v0.2.17 的
chatcompletions_anthropic_bridge.go 第 106–115 行：第 111 行把 parallelToolCalls 直接赋 true、第 112 行写进请求，函数结尾没有任何读取客户端开关的分支。整个 backend 搜不到
disable_parallel_tool_use，这个标志进来就丢了。后果分两层。客户端按单个调用准备的后续步骤会一次拿到多个结果。
有副作用的工具会执行多遍——写文件、发请求、下单这类，重复执行就是事故。
影响面只在这两条桥上：Anthropic 格式的请求被转到 OpenAI 兼容上游或 Responses 上游。走原生 Anthropic 上游的请求不经过它。
修法是加一个共享 helper，
auto、any、具名 tool 三种选择都保留这个限制，省略或写 false 维持现状。今天没有配置能绕。真要单调用语义，只能把这类请求留在原生 Anthropic 上游。
#808：ChatGPT 客户端切到 Work 模式就报错
15:56 开出的 #808 是 codex2api 的 bug 单，带
type/bug 标签，0 评论14。环境写的是 v3.1.1、Docker、Windows 上的 ChatGPT 客户端。
切到 Work 模式后提交消息报错：
Work browser access requires an authenticated account
作者补了一句：部分聊天会自动切到 work，问能不能兼容。
单里没有复现步骤，也没有日志，没有对应 PR。在有人跟进之前，先别让对话进 Work 模式。
版本与主干
| 仓库 | 当前发行版 | 主干 / dev 头（北京） |
|---|---|---|
| sub2api | 0.2.17（10-16 12:41）15 | main 10-16 12:42 |
| CLIProxyAPI | v8.0.33（10-18 21:06）16 | main 10-18 21:05，dev 10-19 12:26（3bbd1652） |
| codex-proxy | v2.1.18（预发布 v2.1.19-beta.f824033）17 | main 10-16 01:16，dev 10-18 18:46 |
| codex2api | v3.1.1（10-17 05:42）18 | main 10-17 05:35 |
上游与额度
OpenAI 状态页回到 All Systems Operational，0 个活动事件，没有降级组件19。
最近一条事件仍是 Compliance API 的成本数据延迟，10-14 开出、10-16 结束。
Anthropic 全绿，10 月 19 日 No incidents reported today20。
Google Cloud 的 incidents.json 仍是 7 条，最近一条是 10-08 到 10-09 的 Cloud Storage21。
Codex 重置这一天（UTC）还没发生。最近一次已验证的全局重置在北京 10-18 04:41，约 36 小时前22。
站上记着 55 次全局重置、10 次 banked，节奏约为每 3 天一次，model 口径 24 小时 21%、48 小时 37%。
opentherank 仍记 63 次重置、中位间隔 3.1 天、最长 68 天23。
官方社区 Codex 分区窗口内有一条新帖，北京 16:17 发出：在 VS Code 里把一份 pytest 文件迁到 TypeScript，被「This content can't be shown」拦下，正文引了 GitHub #55202，没写版本号24。
Reddit 窗口内有一条额度帖：r/OpenAI 在北京 16:16 称 ASTRA 五分钟吃光整个五小时额度、任务还没做完25。
这条只附了截图、没有日志，也不是第一个这么说的人，先记成信号。
r/GeminiAI 另一条（北京 15:42）说 AI Studio 里 Argon 的 medium 档几乎不出思考摘要，没写环境，未收26。
未收与登记
sub2api #8134 窗口内只多了一条报障人的猜测（怀疑混合分组没配路由），没有维护者结论，属旧单被顶起27。
codex-proxy 窗口内 0 条。
References
- 1CLIProxyAPI #6770
github.com
- 2executeCompact
github.com
- 3applyCodexSIWCCompactBodyRules
github.com
- 4normalizeCodexBuiltinToolType
github.com
- 5orphan_delegation.go
github.com
- 6codexTerminalFailureStatus
github.com
- 7sub2api #8217
github.com
- 8writeOpenAICompactSSEFailureMessage
github.com
- 9stream_error_event.go 第 61 行起
github.com
- 10sub2api #8218
github.com
- 11chatcompletions_anthropic_bridge.go
github.com
- 12anthropic_to_responses.go
github.com
- 13convertAnthropicToolChoiceToChat
github.com
- 14codex2api #808
github.com
- 15sub2api releases
github.com
- 16CLIProxyAPI releases
github.com
- 17codex-proxy releases
github.com
- 18codex2api releases
github.com
- 19OpenAI Status
status.openai.com
- 20Anthropic Status
status.anthropic.com
- 21Google Cloud Status
status.cloud.google.com
- 22codex-reset
codex-reset.com
- 23OpenTheRank
opentherank.com
- 24OpenAI 开发者社区
community.openai.com
- 25r/OpenAI
reddit.com
- 26r/GeminiAI
reddit.com
- 27sub2api #8134
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.