10/19 早间速报：Claude 丢搜索结果那条报障 49 分钟后有了补丁，可它只活在单进程内存里，v8.0.33 仍没接
这一小时四仓无新版本：上一期那条 Claude 丢失搜索结果的报障，49 分钟后被报障人自己用「按会话存原始结果」的补丁接住，但补丁只活在单进程内存里、v8.0.33 仍取不到；同一分钟另有流式日志竞态、默认图像模型切换与依赖安全三张 PR。
这一小时四个仓库仍然没发版。CLIProxyAPI 的主干也停在 2026-10-18T18:35:21Z（北京 02:35）。
本期覆盖北京时间 10-19 05:17 到 06:16，共 59 分钟。
动静全在 PR 上。上一期头条那条「Claude 经 /v1/responses 丢掉自己搜索结果」的报障，报障人自己交了补丁。
补丁是 #6758，从开单到开 PR 隔了 49 分钟。
先说结论：升级到 v8.0.33 修不掉上一期那个问题，这一小时也没有版本可升。
补丁做了什么：把原始结果按会话存起来，回程再放回去
问题的老链路上期已经讲清。Codex 存历史时只留
web_search_call 的 id、status、action，results 被丢掉。回程重建
web_search_tool_result 时只能发 content: []，Claude 于是认为自己的搜索什么都没搜到。而 Anthropic 要求重放的每条结果都带原始
encrypted_content，伪造的值会被拒。唯一可用的来源，就是 Claude 当初那份响应。补丁的做法是把那份内容留下来。新增
internal/cache/claude_web_search_result_cache.go，125 行。它按「会话 +
server_tool_use id」存 web_search_tool_result 的原文。键是
sessionKey + "\x00" + toolUseID 的 SHA-256，长度固定。会话键直接复用思考回放那对函数：
codexReasoningReplaySessionKey 与 xaiReasoningReplayIsolateSessionKey。不同调用方、不同会话之间因此不会串。
五个边界都在这段里：24 小时 TTL（每次读刷新）、64 MiB 预算、最多 16384 条、单条内容超过 4 MiB 不存、每条另计 256 字节固定开销。
淘汰按最近最少使用走。单条超限直接跳过，不截断——截断过的
encrypted_content 上游一定不认。什么时候会命中：源格式必须是 Responses，而且带会话身份
补丁的生效条件写得很窄。只有
sourceFormatEqual(from, sdktranslator.FormatOpenAIResponse) 为真时，才会算会话键。也就是说，请求得是从 OpenAI Responses 形状翻译过来的。
Claude 原生客户端、以及没有会话身份的请求，
sessionKey 留空，整条链路原样不动。恢复点的位置也值得记。它在请求翻译与思考处理之后、其余请求准备与 payload 规则之前执行。
PR 专门写了一条测试，验证 payload
filter 删掉的结果不会被恢复回来。配置层仍握最后一道闸。
记录则发生在拿到上游响应之后。非流式在
restoreResponseModel 之后读完整响应体。流式按翻译后的每一行读
content_block_start。空结果不存。命中不到时（过期、重启、另一个实例）回落到今天的行为：
content: []，不比现在更糟。落到运维头上：这条修复今晚帮不到你的单实例之外
判断要不要动手，只需要三个事实。
第二，dev 分支的头仍停在 904ec710（2026-10-18T18:35:21Z，北京 02:35），早于这张 PR。
第三，缓存是进程内的全局 map，没有落盘，也不跨实例共享。多副本部署里，下一轮被另一个实例接走就取不到。
报障人给的实测：干净 v8.0.33 上问「你刚才搜到几条」，Claude 答
RESULTS=0。用这张分支编出来的镜像，同样两种场景都答
RESULTS=10，工具循环照常 200。他在原单里也写明，自己现在跑的是本地插件——缓存原始 Claude 块再换回去。补丁只是把这件事搬进执行器。
次条：#6755 流式日志先关通道再置空，worker 可能读不到、也可能永久卡住
同一个作者 Don-Yin 在 21:25:00Z（北京 05:25）开的这张 PR，修的是
Finalize 里的次序问题。等到
<-w.streamDone 那句，worker 可能早就看错了字段。
而 worker 在
processStreamingChunks 里先判 w.chunkChannel == nil，再 range w.chunkChannel。两步之间字段被清掉，worker 就永远阻塞在 nil 通道上，
Finalize 跟着等下去。后果分两种。轻的是流式响应体没进请求日志（worker 起来晚、看到 nil 直接返回），重的是
Finalize 挂住。PR 给的读数：dev 上
go test -race ./internal/api/middleware/ 直接失败，报 DATA RACE（读取在 :257、写入在 :309）。600 万次连续
WriteHeader/Write/Finalize 循环里，dev 有 99.65% 的流式日志缺块，补丁是 0%。-race 下 20 个进程跑 20 次，dev 有 19 次 Finalize 挂住，补丁 0 次。修法只有三行：把置
nil 挪到 <-w.streamDone 之后。这与同文件里
FileStreamingLogWriter.Close、homeStreamingLogWriter.Close 已有的「关、join、再清」次序一致。生产上的窗口很窄，通常是响应头之后立刻收尾、或者 CPU 紧张时。要不要现在处理，取决于你的流式日志是不是排障依据。
次条：#6757 未指定模型的图像请求，默认从 gpt-image-2 换成 gpt-image-2.5
这是行为变化，不是修 bug。
POST /v1/images/generations 与 /v1/images/edits 受影响，JSON 与 multipart 都算。这两条路在没写
model 时，从 gpt-image-2 改用 gpt-image-2.5。Codex 执行器的两处兜底也一起换。
一处是 Images 到 Responses 的桥接工具模型，另一处是 Responses 请求里
image_generation 工具没写模型时记录的名字。v8.0.33 里这两个常量都还是旧值。
openai_images_handlers.go 第 31 行是 defaultImagesToolModel = "gpt-image-2"。codex_executor_request.go 第 30 行是 codexDefaultImageToolModel = "gpt-image-2"。gpt-image-2.5 本身早就在同一段常量里（第 34 行），也一直在支持模型名单里。这张 PR 改的只是「没写 model 时挑哪个」。要保住旧模型，调用方显式传
"model": "gpt-image-2" 即可。显式写了 model 的请求、注册表、/v1/models、配置都不动。生产改动只有 3 个文件 +7/−5。
次条：#6756 依赖安全升级，10 个可达漏洞清零
同一分钟开的这张 PR 把五个模块升到修复版。
清单是 go-git v6 alpha.5、x/net v0.60.0、x/crypto v0.57.0、x/text v0.42.0、klauspost/compress v1.18.7。
govulncheck 在 dev 上报 10 个第三方可达漏洞，升级后为 0。另有 2 个只在被导入的包里，还剩 1 个没有修复版且未被导入（x/crypto/openpgp）。四条可达链值得知道在哪。
x/net 的五个 HTTP/2 修复走 uTLS 客户端的
http2.ClientConn.Close 与 Transport.NewClientConn。go-git 走
GitTokenStore 的 clone 与 Repository.Head。x/crypto 走同一处的
Worktree.PullContext → ssh.NewClientConn。x/text 走
NewPostgresStore → sql.Open → precis.Profile.String。这条不用今晚动手：没有发版，也没有正在被利用的迹象。它只是提示——如果你的部署把 Git 令牌存储或 Postgres 交给不可信输入，等这版落地。
短条：#6729 那单 499 仍是 NOT_PLANNED，报障人补了逐条 token 对照
上上期报过：openai-compatibility 流式请求在完整收尾后，上游却记 499。
这单在 2026-10-18T09:59:40Z（北京 17:59）被维护者 luispater 以 not planned 关闭。
理由是「下游客户端取消，就跟着断上游，这是设计」，并建议去报给客户端。
窗口末尾 22:11:44Z（北京 06:11），报障人 ai-obsessed 补了一条反驳（comment）。
七条请求在 CPA 侧都是 Success，输出 token 与上游 499 那侧逐条对得上（414 / 102 / 790 / 211 / 56 / 173 / 620）。
他的论点是：真被客户端中断的请求，两侧不会对得上 token 数。他请求加一个 100–250 ms 的尾部 drain，再取消上游上下文。
截至发稿，维护者没有回复，状态仍是关闭。
上游与额度这一小时
四个仓库的版本没动。CLIProxyAPI v8.0.33、sub2api v0.2.17、codex2api v3.1.1。
codex-proxy 稳定版仍是 v2.1.18，预发布 v2.1.19-beta.f824033 也没动。
主干同样没动。sub2api main 停在 10-16T04:42:02Z，codex2api main 停在 10-16T21:35:26Z。
codex-proxy dev 停在 10-18T10:46:30Z。
三家上游全绿。status.openai.com 为 All Systems Operational，最近三条事件都已 resolved。
那三条是：10-14 的 Compliance API 成本数据延迟（收在 10-16T10:44:58Z）、10-15 的广泛降级、10-14 的两个图像模型可用性。
status.anthropic.com 同样全绿，今日无事件。
status.cloud.google.com 仍是 7 条，最近一条是 10-08 到 10-09 的 Cloud Storage。
额度侧没有新信号。codex-reset.com 记今日 UTC 尚未重置。
最近一次已验证的全局重置是 2026-10-17 20:41 UTC（北京 10-18 04:41，约 25 小时前）。累计 55 次全局、10 次 banked。
把提示计入后，24 小时 45%、48 小时 70%。opentherank.com/codex-reset/ 仍记 63 次、中位间隔 3.1 天、最长 68 天。
@thsottiaux 最新一条仍是 2026-10-18T20:34:06Z（2111918768733753664），在窗口之前。
社区侧窗口内只有一条。OpenAI 开发者社区 Codex 分区 21:27:55Z（北京 05:27）的安全研究员准入审核帖，与额度风控无关。
Reddit 三个板块窗口内没有可收的。
r/OpenAI 22:03:58Z 是作品展示，r/GeminiAI 22:02:24Z 是抱怨首 token 慢，r/ClaudeAI 最新一条停在窗口前。
还没落地的东西
- #6758 什么时候合、会不会被要求改成可落盘或按凭证分片。
- #6755 合入后，流式日志缺块是否还有其它路径。
- #6757 合入后，省略 model 的调用方是否需要跟着改计费口径。
- #6729 报障人的对照表会不会让维护者重新打开。
四个仓库这一小时都没有新版本，所以上面每一项都还没有进任何人的发行版。
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.