v8.0.38 落版：五张单一起关掉，首包 13 秒那笔没在里面 (2026)

今晚 23:06，CLIProxyAPI 发出 v8.0.38，打包目标是 main。1

这一版含 12 笔提交、44 个文件。2

今天报出的五张单全在里面，关闭时刻挤在 23:06:06 到 23:06:10 这四秒，版本本身 23:06:34 发布。3 4

配置这一侧不用动：config.example.yaml 两版只差注释，键与默认值一个没改。5

还有两条不在这一版里：首包 13 秒那笔、冷却 429 里的重试时刻。文末逐条交代。

五张单的落点

单	报障时的症状	落点	升级后
#6823	Codex 把客户端显式的 `parallel_tool_calls: false` 改成 true	99d1698f	显式 false 原样到达上游，其余取值仍按 true
#6825	Antigravity 并行调用的 index 重复、`tool_choice: none` 丢签名、回放账本串会话	80aa2b1d	流内 index 唯一；NONE 保留工具声明；回放按调用方隔离
#6826	Guardian 自动评审不复用父会话的凭证	2f6f2924	带 `X-Openai-Subagent: guardian` 头的子请求可继承父会话最近一次选择
#6827	单独出现的 `output_config.effort` 被降成 medium	009f8d7a	effort 原样带到 Codex
#6830	SIWC 令牌被发去 alpha search，回 401	0db19025	搜索改走原始 OAuth 分区

升级后会看到的四处变化

客户端设的 `parallel_tool_calls: false` 现在真能到上游

v8.0.37 的两条翻译器都无条件写回：Chat Completions 那条直接 sjson.SetBytes(out, "parallel_tool_calls", true)，Responses 那条走 setCodexRequiredBool(..., true)。6

报障人拿同一份请求体直连 Codex 后端对比过，后端尊重 false，过一遍中转就变成并行调用。3

这一版改成先看类型：只有显式 false 才跳过写回。true、null、字段缺失仍按 true 处理。7

v8.0.38 的 codex_openai-responses_request.go 第 18 至 34 行 — *v8.0.38 的 `codex_openai-responses_request.go` 第 18–34 行：第 27 行判类型，第 28 行才把 `parallel_tool_calls` 写回 true。7*

顺手一提，payload 规则在这件事上帮不了忙：规则跑在翻译之后的请求体上，字段那时已经是 true。3

Antigravity 的工具调用与回放

流式里 tool_calls[].index 现在只用流内计数器，同一个并行组不管拆成几个 chunk，编号都接着往下走。8

tool_choice: none 也不再删掉 request.tools，第二条对话的 thoughtSignature 有了落点。

回放账本的键前面加了一段 caller: 加下游 API key 的 SHA-256，两把 key 的会话不再共用一份 Gemini 推理链。9

这段 caller 由网关自己从下游 API key 算出来，不用配置。10

alpha search 改用自己的原始 OAuth 令牌

故障形态很干净：/v1/responses 正常，/v1/alpha/search 回 401，错误码 rejected_by_access_enforcement / no_matching_rule。4

原因在 PrepareRequest：use_siwc 打开时它取的是嵌套的 SIWC 令牌，而 alpha search 打的是 ChatGPT 后端的搜索端点。4

这一版在入口加了一道四重判断：SIWC 打开、https、主机 chatgpt.com、路径 /backend-api/codex/alpha/search，四样齐了就改用 auth.Metadata["access_token"]。11

原始 access_token 为空时，本地直接回 401，日志原文是 codex executor: original OAuth access_token is required for ChatGPT Alpha Search。

v8.0.38 的 codex_executor_request.go 第 62 至 82 行 — *v8.0.38 的 `codex_executor_request.go` 第 62–82 行：第 67 行起是那道四重判断，第 72 行是原始令牌缺失时的本地 401。11*

有一类实例会稳定撞上这句：绑了 SIWC、又把原始 OAuth 令牌清掉的。升级后它们的 alpha search 一律 401，看日志就能认出来。

Guardian 评审可以继承父会话的凭证

入口在选号器，三条同时成立才进新分支：子请求、subagentAffinity 打开、请求头 X-Openai-Subagent: guardian。12

进分支后先按 provider 过滤候选：调度目标是 mixed 时全放，否则只认同 provider 的凭证。12

父会话那边取 latestSessionAuth：该会话里最新一次仍在有效期内的选择，注释写明不刷新 TTL、不改淘汰顺序。13

v8.0.38 的 selector.go 第 1222 至 1248 行 — *v8.0.38 的 `selector.go` 第 1222–1248 行：第 1225 行是三条进入条件，第 1233 行的 `mixed` 判断决定候选范围，第 1241 行打出 `guardian inherited parent binding`。12*

配置不用改，但这段注释的语义变了

两版的 config.example.yaml 差在注释：原来那句「subagents 继承并绑定父会话凭证，最大化 Prompt/KV 缓存复用」，扩成了四条更细的说明。5

v8.0.38 的 config.example.yaml 第 160 至 181 行 — *v8.0.38 的 `config.example.yaml` 第 160–181 行：第 162 行的 `session-affinity` 默认仍为 false，第 168–171 行是这次新写的四条 guardian 语义。5*

四条新语义分别是：同 provider 上跨模型继承、含 mixed 池、已有的子会话绑定优先、查父会话不延长父 TTL。

routing.session-affinity 默认是 false，这一整套只对已经打开它的实例生效。

值得关掉的情形只有一个：mixed 池里你希望子会话尽量摊到不同凭证上。把 session-affinity-subagents 设成 false，评审请求就回到 fallback 选号器。

不在这一版里的

44 个文件里没有一处碰到上一期两条主线的代码路径。

首包 13 秒（#6846）：openai_compat_executor.go、helps/apply_patch.go、util/responses_tools.go 都不在改动清单里。2开放 PR 的最大编号仍是 6845，这张单到今天还没人提修复。14
冷却 429 补 next_retry_at（#6845）：PR 仍 open，1 笔提交、5 个文件。15
Claude OAuth 下模型丢掉 mcp__<server>__ 前缀、工具名原样下发（#6848）：今天 22:42 新开，零评论、无 label。16
选号阶段的拒绝不进 usage 记录（#6839）：仍 open。17

所以想靠升版解决大工具列表的首包停顿，这一版给不了。工具数上千、上游要走翻译的场景，先按上一期的两个条件（客户端讲 Responses、上游执行器要翻译）确认自己会踩到，再决定要不要先拆工具。

今晚上游在抖

23:34，OpenAI 状态页新开一条 Elevated error rates for gpt-5.6-luna API requests，impact minor、状态 identified。18

组件面上 Chat Completions 与 Responses 都是 degraded_performance，站点整体 Partial System Degradation。19

上一期那条 FedRAMP（Astra 与 Sol）还是 identified，之后没有新更新。18

今晚 5xx 变多时，先看这两个组件，再动号池。

sub2api #8239 里 23:01 和 23:03 有两条跟帖：两个 pro20x 一个好一个坏，五个 200pro 里两个正常三个异常，异常的把并发容量开到 1 也压不住。20

这两条是报障人的观察，时刻比上面那条事件早半小时，解释不了今晚的抖动。要把「号坏了」和「上游在抖」分开，得在同一时刻对照状态页。

这一小时的四仓

仓库	当前版本	这一小时
CLIProxyAPI	v8.0.38，23:061	发版；main 与 dev 都停在 23:04
sub2api	v0.2.17，10 月 16 日21	主干两条：#8275 修 Docker 默认 Go 镜像、#8276 建议接 CodeRabbit
codex-proxy	v2.1.20-beta.0543eaa22	零条目
codex2api	v3.1.123	零条目

sub2api 那条要和自建镜像的人说清楚：主干 backend/go.mod 已经要求 go 1.27.3，根目录 Dockerfile 的默认构建参数仍是 golang:1.27.2-alpine。24 25

不带参数直接从主干构建，编译阶段会停下并报 go.mod requires go >= 1.27.3。#8275 已提未合，临时的办法是 --build-arg GOLANG_IMAGE=golang:1.27.3-alpine。26

今晚的动作只有一条：跑 v8.0.37 的升到 v8.0.38，五个修复一次拿到，配置文件照旧。开着 session-affinity 的实例，顺手确认 guardian 继承是你要的行为。首包那笔继续等。

References

1
CLIProxyAPI v8.0.38
github.com
2
compare v8.0.37...v8.0.38
github.com
3
#6823
github.com
4
#6830
github.com
5
config.example.yaml（v8.0.38）
github.com
6
codex_openai_request.go（v8.0.37）
github.com
7
codex_openai-responses_request.go（v8.0.38）
github.com
8
commit 80aa2b1d
github.com
9
antigravity_reasoning_replay.go（v8.0.38）
github.com
10
handlers.go 的 requestCallerScope
github.com
11
codex_executor_request.go（v8.0.38）
github.com
12
selector.go（v8.0.38）
github.com
13
session_cache.go 的 latestSessionAuth
github.com
14
CLIProxyAPI 开放 PR 列表
github.com
15
PR #6845
github.com
16
#6848
github.com
17
#6839
github.com
18
status.openai.com 事件 01M5FHKHPQJMSHCE2B2WDPZW2N
status.openai.com
19
OpenAI 状态页
status.openai.com
20
sub2api #8239
github.com
21
sub2api releases
github.com
22
codex-proxy releases
github.com
23
codex2api releases
github.com
24
backend/go.mod（main）
github.com
25
Dockerfile（main）
github.com
26
PR #8275
github.com