三张补丁关成已落地、第四张还开着：v8.0.43 的首帧读取仍把取消记成成功 (2026)

昨夜 23:37，CLIProxyAPI 发出 v8.0.43，修掉了「取消与通道关闭同时就绪」时的一处判定。1

今天凌晨 01:12，连开四条流式缺陷单的 eaxeax 又开了一张 #6987：同一处判定，另一条读取路径上还没有改。2

影响落在内部流调用上，也就是插件经 Host 发起的 ExecuteModelStream。普通 HTTP 请求由交付结果兜底，结局按实际交付算；内部流被取消时，插件那一侧会收到 succeeded、状态码 200。

现成的处置只有一个：等 #6980 进版，配置里没有能绕开的开关。跑 codex2api 的实例今晚另有一个动作，在第三节。

同一处判定，只改了一半

v8.0.43 里，读流的正路是 nextStreamChunk。通道关闭、上下文同时已被取消时，它把这一轮判成取消。3

代码截图：nextStreamChunk 的 select 与那句 tie-break

sdk/api/handlers/handlers_interceptors.go 第 231–259 行（标签 v8.0.43）。第 248–251 行是这条路上唯一的 tie-break：通道关掉时若 ctx.Err() 非空，按取消返回；第 249 行那句注释就是上一轮落地时写下的理由。

首帧读取另写了一套。readInitialStreamChunks 自己起了一个 select，两边同时就绪时，运行时随机挑一边。4

代码截图：readInitialStreamChunks 自己的 select，没有 tie-break

同版本 sdk/api/handlers/handlers_stream.go 第 488–512 行。第 494–500 行的 select 没有 tie-break；第 504–505 行一旦拿到「通道已关」，就把 streamClosedBeforeRead 置真。

挑中「通道已关」的那一次，后面顺着错下去。第 669 行把已置真的标志交给 nextStreamChunk，它立刻返回已关闭；循环在第 678 行的 if !ok 分支收工，完成结果停在默认的 succeeded、200。5

只有 streamCanceledBeforeRead 那条会被改写成取消（第 607–612 行）。所以同一秒里的两种结局，取决于运行时先挑中哪一边。

eaxeax 的复现读数很硬：macOS arm64、Go 1.27.3，跑 2000 轮，v8.0.43 十次里挂九次。失败那一轮的完成结果是 Outcome:succeeded StatusCode:200。2

HTTP 请求为什么平安？差别在交付跟踪。streamDeliveryCompletion 只在请求有交付跟踪时按交付错误重判；手上没有跟踪，它原样返回。6

内部流恰好没有跟踪。ExecuteModelStream 一进来就调 usage.WithoutStreamDelivery，WaitStreamDelivery 于是返回 tracked=false。7 8

消费这一头是插件宿主：host.model.execute_stream 经 host_model_stream_callbacks.go 第 33 行调进 ExecuteModelStream。9

自查可以更省事：插件在首字节前取消过嵌套调用，并按完成结果记账、计数或决定重试，这一段就可能被多算。值域是 pluginapi 的 RequestCompletionOutcome。10

修复已经写好，躺在 PR 里。#6980 现在 2 文件 +46/−11、单提交、mergeable clean。11

三张补丁关成「已落地」，第四张重基成单提交

01:12:41，eaxeax 把 #6980 重基成单提交（dc3c5857c → 09f1997da）。他的说明写得很清楚：90fe5b23d 已经带走了这 PR 的第一个提交，分支上只剩剩下那一处改动。11

补丁	关成什么	关闭（北京）	落地提交	首轮自动评审
#6978 aistudio 把中继块里每一帧都译出来	已落地	01:12:55	`307803510`	有未解决发现，关闭评论写明连同那处 deferred close 一起带上
#6982 data 先关时把缓冲错误报出去	已落地	01:12:58	`0fe4cc2cf`	无发现
#6984 两个 websocket 测试的竞态	已落地	01:13:00	`84e834414`	无发现

三条评论都用「Landed in v8.0.43 as …」收尾，三张 PR 的 merged 全是 false。12 13 14

merged=false 说明合并按钮没被按过。维护者把改动重录成自己的提交，然后关单，PR 头提交与落地 SHA 因此对不上。

eaxeax 在同一处向维护者提了两件事。第一件是署名：八条报障（#6843、#6884、#6885、#6886、#6977、#6979、#6981、#6983）在 v8.0.39 到 v8.0.43 之间被修，其中七条带着补丁，都落成维护者署名的提交，GitHub 因此不计他的贡献。11

第二件是安全。他说 10-25 递了一份私有漏洞报告 GHSA-4w5v-m7vx-jpmh，仍在 triage，补丁附在报告里，受影响的代码在 v8.0.43 未变。11

这一条只能当他的自述登记。仓库的安全公告页与该 advisory 的接口都回 404，私有的内容外面读不到，范围与影响也就无从核对。15

跟单的人这样收口：#6978、#6982、#6984 划掉；#6980 继续盯；那份 advisory 公开之后，再判断要不要动配置或换版本。

codex2api：降智检测还在按「所有通道」自动启用

codex2api 的实例上，降智检测开了「新账号默认参与检测」、处置选「切换分组」，再加一个别的通道的账号，保存就会失败。16

报错原话是 intelligence check target group is incompatible: N enabled accounts belong to another channel。页面只给数量，不给是哪个账号。16

根因是两处判定各走各的。建账号时，SQLite 触发器与 PostgreSQL 函数只看 new_accounts_enabled，账号属于哪个通道，它不问。17

代码截图：v3.1.1 的新账号触发器只读 new_accounts_enabled

database/intelligence_check.go 第 114–126 行（标签 v3.1.1）。第 118 行的 SQLite 触发器与第 121 行的 PG 函数都只读 new_accounts_enabled，整句里没有通道条件。

保存时按通道比对。目标分组在 codex 通道，服务端就把已启用、通道与它不一致的账号数出来，数字大于 0 直接报错。18

同文件第 165–181 行。第 171 行按通道比对计数，第 175 行把数量拼进那句 400 原文；这一步发生在写设置之前。

死结就这么成形：账号被自动启用，保存被拒，配置从此改不动。报障人那条冲突账号是 platform: anthropic，目标分组在 codex 通道。16

版本面：v3.1.1 发布于 10-17 05:42（北京），今天仍是发行版。修复提交 3c6adfda 于 00:39 直推 main，还没有版本带上它。19 20

处置按这三步：

先关掉冲突账号的检测。接口是 PATCH /api/v1/intelligence-check/accounts，body 写 {"account_ids":[…],"enabled":false}，一次最多 200 个。21
再回降智检测页保存。仍报同一个数，说明还有别的通道账号被启用，重复第 1 步。
之后才决定要不要恢复「新账号默认参与检测」。在 v3.1.1 上只要还开着它，再加别的通道账号就会再长出一个冲突。

自查一句话：把目标分组的通道和已启用检测的账号通道对一遍，不一致的条数就是报错里那个数字。

main 上的修法在源头解决。新账号默认是否启用，现在带上「switch_group 时目标分组必须同通道」这一条件，SQLite 与 PostgreSQL 两套触发器一起换掉。22

database/intelligence_check.go 第 136–170 行（main 分支）。第 146–149 行的默认值表达式里，switch_group 只有在目标分组通道与账号通道一致时才启用检测；第 153–167 行删掉旧触发器再重建，注释写明 IF NOT EXISTS 会让升级后的实例继续用旧的无条件触发器。

升级后行为会变：switch_group 模式下，只有同通道、且支持检测的新账号才继承「默认参与」；其他通道的账号照常能建，只是不自动启用。保存失败时服务端还会回冲突账号的 ID、名称、通道与目标分组通道，并给批量关闭入口。16

版本面与上游

四仓在这个窗口里零新版本。CLIProxyAPI 的 tag、main、dev 与 HEAD 同为 307803510，v8.0.43 之后主干没有新提交。23

codex2api 的 main 停在 3c6adfda；sub2api 与 codex-proxy 窗口内没有条目更新。

#6715（无头机器用设备码登录 Codex）窗口内只多了一笔把 dev 并进分支的合并（00:47:58）。它现在 52 个提交、21 个文件，仍在评审。24

上游全绿。OpenAI 与 Anthropic 都报 All Systems Operational，Anthropic 的页面在 01:04 更新过。25 26

GCP 最近一条事故仍是 10-22 的 europe-west2，窗口内没有新事件。27

额度侧没有新信号。codex-reset 最新帖停在 10-25 22:38（北京），signal 已标为失效，四条 reset 记录都还是 pending。28

社区两处也是空的。Codex 分区最新一帖是 10-24 19:34，窗口内 0 条；Gemini 分区窗口内只有垃圾帖。29

今晚的三件事

CLIProxyAPI 不改配置。插件把「首字节前取消」的内部流按成功来记账的，先按可能多算处理；等含 #6980 的版本。
codex2api 先关掉跨通道账号的检测，保存成功之后再决定要不要继续开着「新账号默认参与检测」。
跟单：#6978、#6982、#6984 划掉；#6980 与那份 GHSA 继续盯。

References

1
CLIProxyAPI v8.0.43
github.com
2
#6987 首帧读取仍把取消记成成功
github.com
3
handlers_interceptors.go 第 241–252 行
github.com
4
handlers_stream.go 第 490–505 行
github.com
5
handlers_stream.go 第 668–690 行
github.com
6
handlers_stream.go 第 856–871 行
github.com
7
model_execution.go 第 144–150 行
github.com
8
stream_delivery.go 第 30–55 行
github.com
9
host_model_stream_callbacks.go 第 33 行
github.com
10
types.go 第 1227–1235 行
github.com
11
PR #6980
github.com
12
#6978
github.com
13
#6982
github.com
14
#6984
github.com
15
仓库安全公告
github.com
16
issue #830
github.com
17
v3.1.1 intelligence_check.go 第 114–124 行
github.com
18
同文件第 165–180 行
github.com
19
v3.1.1 发行页
github.com
20
提交 3c6adfda
github.com
21
v3.1.1 admin/intelligence_check.go 第 113–133 行
github.com
22
main 分支第 136–170 行
github.com
23
CLIProxyAPI 主干提交
github.com
24
PR #6715
github.com
25
OpenAI 状态页
status.openai.com
26
Claude 状态页
status.claude.com
27
GCP 事故页
status.cloud.google.com
28
codex-reset
codex-reset.com
29
Codex 分区 RSS
community.openai.com