10/19 清晨速报：Claude 经 /v1/responses 时，自己搜到的页面下一轮就成空结果，v8.0.33 也一样
这一小时四个仓库没发版，CLIProxyAPI 上一条报障把 Claude 经 /v1/responses 丢掉自己搜索结果的链条讲清了：回放只重建空结果，v8.0.32 与 v8.0.33 在这段代码上逐字节相同，升级修不掉。
北京时间 04:16 到 05:15 这一个小时，四个仓库没有新版本，主干也没有新提交。
CLIProxyAPI 上落了两条，作者是同一个人：一条报障，说 Claude 模型经
/v1/responses 时，自己搜到的页面在下一轮就变成空结果；一条测试修复，只动测试文件。先说会影响动作的那条。它不报错，不进日志，也不会触发任何熔断。
四步之后，搜索结果就没了
报障单把链条写得完整。1
接下来是客户端。报障人观察到，Codex 存历史时只留
id、status、action，results 不在里面，助手消息的 annotations 同样不留。上游收下这个空结果，返回 200。模型于是认定，上一轮那次搜索什么都没搜到。
internal/translator/claude/openai/responses/claude_openai-responses_web_search.go 第 94–129 行，原始文件。上半段是出站：第 101 行那句 if len(results) > 0 决定了没有命中就不写 results；下半段是回站：第 123 行的模板已经把 content 写成空数组，第 125 行只有在重建成功时才覆盖它。补不回来的那一份
结果块里带
encrypted_content，是 Anthropic 自己签的，回放时它要逐条校验，伪造的值会让整单被拒。4
encrypted_content 的条目用不了，空结果列表是唯一安全的降级方式；第 161–162 行就是照着这句话写的早退。可回放的块只存在过两个地方：当初那次响应，和客户端的存储。客户端没留，服务端也没留，中间这一层就再也补不回来。
怎么确认自己的流量踩了
报障人给了一套三轮复现，环境写得很具体：干净 v8.0.33、无插件、Claude OAuth、
claude-opus-5-5。1第一轮让 Claude 搜一次、再调一个函数，出站能看到
web_search_call 带着 10 条 results。第二轮按 Codex 的存法把历史发回去，返回 200，函数调用照常继续。
第三轮换个新问题：「你刚才那次搜索返回了几条，答 RESULTS=<n>」。它答
RESULTS=0。不带函数工具的变体里，它还会说上一轮那个答案是错的，因为「搜索没有返回结果」。日常里更容易撞见的信号有两个：长任务里反复搜同一个东西，或者模型主动说上一轮没搜到。
升级解决不了
它也不是 v8.0.33 带进来的。这笔转换 8 月 26 日进主干，从 v8.0.0 到 v8.0.33，每个标签下都能找到这个文件。6
报障人自己的用法是在本地挂一个插件，把原始的 Claude 块缓存下来、回放时换回去。他们说，维护者认可这个方向就做成 PR。这张单现在 open、0 评论。
今天能选的三条路
换入口。 这套转换只活在 responses 与 claude 两个协议之间。7 Claude 的搜索如果从
/v1/messages 进来，那一对块原样来回，不经过重建。代价是客户端得说 Anthropic 的格式，Codex CLI 这种只会说 Responses 的做不到。
claude_openai-responses_request.go 第 476–486 行，原始文件。第 479 行的 case "web_search_call" 说明这条重建在请求侧真的会被走到，不是留着没用的死代码。关掉这项工具。 客户端不再发
web_search，历史里就不会有 server_tool_use，也就没有回放这一步。代价是这条流量上 Claude 不再搜索。在配置层删。
payload.filter 能按目标协议、来源协议、模型三者同时限定，按 JSON 路径删字段。89 但规则作用在翻译之后的 Claude 请求体上，历史里重建出来的 server_tool_use 块仍然在，上游会不会因为「带了搜索块却没声明这个工具」拒单，本刊没有验证。把它当实验，别当止血步骤。三条都不选也行，前提是你知道这条流量上的搜索结果是不可信的。
次条：dev 上的红不是产品回归
同一分钟之后，还是这位作者，开了一张只改测试的补丁。10
失败有两种签名。客户端写请求时连接已经被服务端关掉，报
use of closed network connection；带会话的变体里执行器重连后第二次调钩子，close(inWriteHook) 直接 panic，整个测试二进制退出。起因是假服务端在 pong 之后立刻发终局帧并关连接，不等客户端把请求写出来。补丁新增
startKeepaliveTestReader，读到客户端第一帧数据再发终局帧；只动两个 _test.go，+70/−37，没有产品码。所以它对现网是零，只影响你怎么读 dev 的 CI：这几个 keepalive 测试红了，先查测试自己的竞态。
这一小时其余
四仓版本都没动：CLIProxyAPI v8.0.33、sub2api v0.2.17、codex-proxy v2.1.18（预发布 v2.1.19-beta.f824033 未动）、codex2api v3.1.1。12131415
主干也没动：CLIProxyAPI 的 dev 头停在 19 日 02:35（北京）的
904ec710，main 停在 18 日 21:05。16 sub2api 的 main 停在 16 日 12:42，codex-proxy 的 dev 停在 18 日 18:46，codex2api 的 main 停在 17 日 05:35。上游三段都安静。OpenAI 状态页全绿，活动事件 0 条。17 Anthropic 全绿，UTC 的 10 月 18 日没有事件。18 Google Cloud 的事故列表仍是 7 条，最近一条是 10 月 8 日到 9 日的 Cloud Storage。19
Codex 的全局重置今天（UTC）仍未发生，最近一次是 17 日 20:41 UTC，约 25 小时前；累计 55 次全局重置、10 次 banked，节奏约每 3 天。20
北京 04:34，
@thsottiaux 发了一条玩笑：有人跑到街上向他要重置，他打算做几张卡片发。21 追踪站把这条归为 tease，不算重置承诺；页面上仍并列两套口径，模型 21% / 37%，计入提示后 45% / 70%，并注明计入值是显示下限、帖出 60 小时后失效。20长期统计在另一站：自 2025 年 9 月起 63 次，中位间隔 3.1 天，最长一次 68 天。22
官方社区 Codex 分区这一小时没有新话题，最新一条还是 18 日 23:55（北京）。23
这一小时怎么动
- 先判有没有踩到：Claude 的流量里，有没有
/v1/responses入口并且开着web_search。 - 有就按上面三条路选一条；没有就什么都不用做。
- 别把「等下一版」当方案：v8.0.32 到 v8.0.33 在这段代码上没有区别。
- dev 上那五个 keepalive 测试红了，先查测试竞态，别当产品回归。
References
- 1#6753
github.com
- 2
- 3
- 4
- 5v8.0.32 的同名文件
github.com
- 6提交 4fa1de2f9b
github.com
- 7
- 8config.example.yaml 第 299–313 行（v8.0.33）
github.com
- 9config_types.go 第 544–562 行（v8.0.33）
github.com
- 10#6754
github.com
- 11dev 提交 904ec710
github.com
- 12CLIProxyAPI v8.0.33
github.com
- 13sub2api v0.2.17
github.com
- 14codex-proxy 发行版
github.com
- 15codex2api 发行版
github.com
- 16CLIProxyAPI 的 dev 提交时间轴
github.com
- 17OpenAI Status
status.openai.com
- 18Anthropic Status
status.anthropic.com
- 19Google Cloud 事故列表
status.cloud.google.com
- 20codex-reset.com
codex-reset.com
- 21这条帖
x.com
- 22OpenTheRank Codex Reset Tracker
opentherank.com
- 23OpenAI 开发者社区 Codex 分区
community.openai.com
- 24r/ClaudeAI 帖子
reddit.com
- 25r/OpenAI 帖子
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.