开着 SIWC 的 Codex 凭证，一开子代理就 400，v8.0.38 还没修 (2026)

今天 00:23，CLIProxyAPI 收到一张补丁单：给 SIWC 凭证转换 agent_message 项。1

它修的是一张报障单——开着 SIWC 的 Codex 凭证，客户端一开子代理，上游先回 400，父回合跟着挂。2

那张单是下午 15:53 开的，19:26 被另一个人引用过一次，之后再没有评论。2

v8.0.38 和 dev 分支的对应位置都还是旧参数，这一小时四仓也没有新版本。1

结论先摆出来：这是中转自己的洞，眼下能绕开的办法都在凭证配置那一层，补丁要等合版。

受影响的是凭证上开了 use_siwc、客户端又在跑 Codex 多智能体的那批实例；只跑单轮对话的凭证碰不到它。2

撞上的形态

报障人给的最小请求体里只有一项输入，type 是 agent_message。2

这一项带了 author: /root 和 recipient: /root/probe，模型是 gpt-6.1-sol，凭证上 use_siwc=true。2

上游回 HTTP 400，错误码 subscription_sharing_unsupported_capability，param 指向 input。2

同一张凭证上，把这一项换成普通 user message，回的是 200。2

真实会话里的顺序是子代理先挂；父回合随后收到子代理的失败消息，那也是一项 agent_message，于是跟着挂。2

两个条件要同时成立：凭证上开着 use_siwc，客户端在跑 Codex 的多智能体。2

v8.0.38 的 codex_multi_agent_v2.go 第 231 至 241 行 — *v8.0.38 的 `codex_multi_agent_v2.go` 第 231–241 行：第 237 行先判 `isCompat`，只有它为真才调用输入改写。3*

这条路漏在哪

转换本身是现成的。rewriteCodexAgentMessageInput 会把 agent_message 改写成 message，role 写成 user。4

它顺手删掉 author、recipient、internal_chat_message_metadata_passthrough 三个字段。4

入口在上一层：RewriteCodexMultiAgentV2Input 的 compatMode 由调用方传进去。5

isCompat 读的是模型配置：凭证 codex 段的模型条目里写了 is-compat: true，或者 API key 口径下的同名字段。6

从结果反推：报障那张凭证的模型条目没标这一项，转换没跑，请求带着原样的 agent_message 到了上游。

补丁的改法是一个参数：把 isCompat || codexUseSIWC(auth) 传进去。1

真正改到的调用点是五处：Execute 第 85 行、executeCompact 第 274 行、ExecuteStream 第 92 行、WebSocket 非流式第 85 行、WebSocket 流式第 813 行。1

补丁正文只写了四条，/responses/compact 那一处也在改动里。1

补丁分支上的 codex_executor_execute.go — *补丁分支的 `codex_executor_execute.go`：第 85 行的参数改成 `isCompat || codexUseSIWC(auth)`；第 72 行早就把 `useSIWC` 算了出来。1*

到发稿时这张单仍然 open：1 笔提交、5 个文件、+34/−5、mergeable clean。1

自动评审 00:30 起跑，状态还是 running。1

现在能做的三件事

做法	改哪里	代价	现在能用吗
关掉这张凭证的 `use_siwc`	凭据的 `attributes.use_siwc`	这张凭证回到普通 OAuth 分区，SIWC 那层额度不再参与选号	能，立即生效
把该模型标成 `is-compat`	凭证 codex 段的模型配置 `is-compat: true`	同一趟请求的加密推理内容清洗也跟着换口径	能，但要重测
等 #6849 合入并发版	—	现在没合，也没发版	用不了

第二行要当心：isCompat 除了喂多智能体改写，还喂给加密推理内容的清洗。7

自己打补丁也行：五个调用点各改一个参数，其余逻辑不动。1

怎么认出这一类凭证

GET /v8/management/credentials 的 Codex 条目带几个非敏感字段：siwc_bind_supported、use_siwc、siwc_status、siwc_bound。8

另有可选的 siwc_expires_at，给的是本地存的到期时刻。8

use_siwc 为真表示请求会走嵌套的 SIWC 凭证；siwc_status 有三态 off、valid、invalid。8

按报障人的复现，撞上这条 400 的就是 use_siwc 为真的那一类凭证。2

次线：v0.2.17 的查单，把一批老网关的单子卡在二维码

上午 10:29，sub2api 收到一张单：升级到 v0.2.17 之后，易支付付款成功，页面一直停在二维码。9

报障人回退上一版就恢复正常，这一点写进了单子正文。9

23:56，维护者给了一句解释：这东西有洞，让报障人改易支付那边——付款后要去易支付后台查这笔订单。10

机制在 v0.2.17 里：易支付实现了 ConfirmNotification，回调验签之后再去网关查单。11

四个判定挨着来：订单已付、金额（容差 0.005）、trade_no 一致、把上游的 trade_no 补写回通知。11

任何一条不过，webhook 直接回 502 confirm failed，订单停在待支付。12

同一次失败还会写一条 PAYMENT_UPSTREAM_UNCONFIRMED 审计，带上 detail、tradeNo、amount。13

只有实现了 NotificationConfirmer 的渠道会走这一步，v0.2.17 里只有易支付实现了它。13

v0.2.16 的同名文件里搜不到这个方法，回退因此能恢复「验签即入账」。14

这一版发行说明里写着：修复易支付查单参数识别，回调确认后再入账。15

v0.2.17 的 easypay.go 第 409 至 435 行 — *v0.2.17 的 `easypay.go` 第 409–435 行：第 417 行查单，第 421 行判已付，第 425 行比金额，第 429 行比 `trade_no`。11*

v0.2.17 的 payment_webhook_handler.go 第 120 至 131 行 — *v0.2.17 的 `payment_webhook_handler.go` 第 120–131 行：第 126 行调上游确认，第 128 行回 502 `confirm failed`，第 129 行直接 return；入账那一步在第 132 行之后。12*

处置按这个顺序：先翻审计有没有 PAYMENT_UPSTREAM_UNCONFIRMED，detail 会写明哪一条没过。11

再去核面板里的「API 基础地址」与商户 ID、商户密钥。11

地址要指向易支付站自身，代码会先裁掉 /submit.php、/mapi.php、/api.php 后缀再拼。11

彩虹易支付与 ZPay 只认 URL 查询串上的 act=order，别的分支读表单，代码两处都发。11

网关那边压根没有查单接口的话，只剩换网关或回退 v0.2.16 两条路。14

上游这一小时

23:47，OpenAI 把 23:34 那条 Elevated error rates for gpt-5.6-luna API requests 从 identified 转到 monitoring。16

更新的原文是「We have applied the mitigation and are monitoring the recovery.」16

组件面上 Chat Completions 与 Responses 仍是 degraded_performance，站点整体还是 Partial System Degradation。17

22:17 那条 FedRAMP（Astra 与 Sol）还停在 identified，之后没有新更新。17

这段时间 5xx 变多，先读错误体：带 servers are currently overloaded 的那类容量让渡，v0.2.17 不给账号上任何状态。18

其余 5xx 仍可能把号打进临时不可调度，这段窗口里先看错误码再动手。18

这一小时的四仓

仓库	当前版本	窗口内动作
CLIProxyAPI	v8.0.38，北京 23:0619	一张补丁单 #6849；dev 头停在 23:0420
sub2api	v0.2.17，10 月 16 日21	#8258 多了一条维护者回复
codex-proxy	v2.1.20-beta.0543eaa22	零条目
codex2api	v3.1.123	零条目

额度与社区

codex-reset 今天（UTC）还没有重置，最近一次已验证的全局重置是 34 小时前。24

换成北京时间是 10 月 20 日 14:33；至今 56 次全局重置、10 张 banked。24

opentherank 记的是 64 次，中位间隔 3.1 天，最长一次 68 天。25

00:38（北京），官方开发者社区 Codex 分区冒出一条帖，把每次重置和 Sub2api 中转抢容量直接连在一起。26

帖里写正常用户撞上的是 Selected model is at capacity。26

上述是发帖人的判断与个人使用情况。26

收尾

这一小时要动的只有凭证配置那一层：use_siwc 为真的实例，先定是关掉 SIWC，还是等 #6849 合入。

跑易支付的站点，先翻审计再看网关。

References

1
PR #6849
github.com
2
#6833
github.com
3
codex_multi_agent_v2.go（v8.0.38）
github.com
4
optimize_multi_agent_v2.go（v8.0.38）
github.com
5
optimize_multi_agent_v2.go（v8.0.38）
github.com
6
codex_executor_auth.go 的 resolveCodexModelIsCompat
github.com
7
codex_executor_execute.go（v8.0.38）
github.com
8
management-api-v8.md（v8.0.38）
github.com
9
#8258
github.com
10
#8258 的回复
github.com
11
easypay.go（v0.2.17）
github.com
12
payment_webhook_handler.go（v0.2.17）
github.com
13
payment_fulfillment.go（v0.2.17）
github.com
14
easypay.go（v0.2.16）
github.com
15
Sub2API 0.2.17
github.com
16
status.openai.com 事件 01M5FHKHPQJMSHCE2B2WDPZW2N
status.openai.com
17
OpenAI 状态页
status.openai.com
18
openai_account_runtime_block_fastpath.go（v0.2.17）
github.com
19
CLIProxyAPI releases
github.com
20
CLIProxyAPI dev 提交
github.com
21
sub2api releases
github.com
22
codex-proxy releases
github.com
23
codex2api releases
github.com
24
codex-reset.com
codex-reset.com
25
opentherank.com/codex-reset
opentherank.com
26
Codex is a product, not a demo
community.openai.com

今天 00:23，CLIProxyAPI 收到一张补丁单：给 SIWC 凭证转换 agent_message 项。1

它修的是一张报障单——开着 SIWC 的 Codex 凭证，客户端一开子代理，上游先回 400，父回合跟着挂。2

那张单是下午 15:53 开的，19:26 被另一个人引用过一次，之后再没有评论。2

v8.0.38 和 dev 分支的对应位置都还是旧参数，这一小时四仓也没有新版本。1

结论先摆出来：这是中转自己的洞，眼下能绕开的办法都在凭证配置那一层，补丁要等合版。

受影响的是凭证上开了 use_siwc、客户端又在跑 Codex 多智能体的那批实例；只跑单轮对话的凭证碰不到它。2

撞上的形态

报障人给的最小请求体里只有一项输入，type 是 agent_message。2

这一项带了 author: /root 和 recipient: /root/probe，模型是 gpt-6.1-sol，凭证上 use_siwc=true。2

上游回 HTTP 400，错误码 subscription_sharing_unsupported_capability，param 指向 input。2

同一张凭证上，把这一项换成普通 user message，回的是 200。2

真实会话里的顺序是子代理先挂；父回合随后收到子代理的失败消息，那也是一项 agent_message，于是跟着挂。2

两个条件要同时成立：凭证上开着 use_siwc，客户端在跑 Codex 的多智能体。2

这条路漏在哪

转换本身是现成的。rewriteCodexAgentMessageInput 会把 agent_message 改写成 message，role 写成 user。4

它顺手删掉 author、recipient、internal_chat_message_metadata_passthrough 三个字段。4

入口在上一层：RewriteCodexMultiAgentV2Input 的 compatMode 由调用方传进去。5

isCompat 读的是模型配置：凭证 codex 段的模型条目里写了 is-compat: true，或者 API key 口径下的同名字段。6

从结果反推：报障那张凭证的模型条目没标这一项，转换没跑，请求带着原样的 agent_message 到了上游。

补丁的改法是一个参数：把 isCompat || codexUseSIWC(auth) 传进去。1

真正改到的调用点是五处：Execute 第 85 行、executeCompact 第 274 行、ExecuteStream 第 92 行、WebSocket 非流式第 85 行、WebSocket 流式第 813 行。1

补丁正文只写了四条，/responses/compact 那一处也在改动里。1

到发稿时这张单仍然 open：1 笔提交、5 个文件、+34/−5、mergeable clean。1

自动评审 00:30 起跑，状态还是 running。1

现在能做的三件事

做法	改哪里	代价	现在能用吗
关掉这张凭证的 `use_siwc`	凭据的 `attributes.use_siwc`	这张凭证回到普通 OAuth 分区，SIWC 那层额度不再参与选号	能，立即生效
把该模型标成 `is-compat`	凭证 codex 段的模型配置 `is-compat: true`	同一趟请求的加密推理内容清洗也跟着换口径	能，但要重测
等 #6849 合入并发版	—	现在没合，也没发版	用不了

第二行要当心：isCompat 除了喂多智能体改写，还喂给加密推理内容的清洗。7

自己打补丁也行：五个调用点各改一个参数，其余逻辑不动。1

怎么认出这一类凭证

GET /v8/management/credentials 的 Codex 条目带几个非敏感字段：siwc_bind_supported、use_siwc、siwc_status、siwc_bound。8

另有可选的 siwc_expires_at，给的是本地存的到期时刻。8

use_siwc 为真表示请求会走嵌套的 SIWC 凭证；siwc_status 有三态 off、valid、invalid。8

按报障人的复现，撞上这条 400 的就是 use_siwc 为真的那一类凭证。2

次线：v0.2.17 的查单，把一批老网关的单子卡在二维码

上午 10:29，sub2api 收到一张单：升级到 v0.2.17 之后，易支付付款成功，页面一直停在二维码。9

报障人回退上一版就恢复正常，这一点写进了单子正文。9

23:56，维护者给了一句解释：这东西有洞，让报障人改易支付那边——付款后要去易支付后台查这笔订单。10

机制在 v0.2.17 里：易支付实现了 ConfirmNotification，回调验签之后再去网关查单。11

四个判定挨着来：订单已付、金额（容差 0.005）、trade_no 一致、把上游的 trade_no 补写回通知。11

任何一条不过，webhook 直接回 502 confirm failed，订单停在待支付。12

同一次失败还会写一条 PAYMENT_UPSTREAM_UNCONFIRMED 审计，带上 detail、tradeNo、amount。13

只有实现了 NotificationConfirmer 的渠道会走这一步，v0.2.17 里只有易支付实现了它。13

v0.2.16 的同名文件里搜不到这个方法，回退因此能恢复「验签即入账」。14

这一版发行说明里写着：修复易支付查单参数识别，回调确认后再入账。15

处置按这个顺序：先翻审计有没有 PAYMENT_UPSTREAM_UNCONFIRMED，detail 会写明哪一条没过。11

再去核面板里的「API 基础地址」与商户 ID、商户密钥。11

地址要指向易支付站自身，代码会先裁掉 /submit.php、/mapi.php、/api.php 后缀再拼。11

彩虹易支付与 ZPay 只认 URL 查询串上的 act=order，别的分支读表单，代码两处都发。11

网关那边压根没有查单接口的话，只剩换网关或回退 v0.2.16 两条路。14

上游这一小时

23:47，OpenAI 把 23:34 那条 Elevated error rates for gpt-5.6-luna API requests 从 identified 转到 monitoring。16

更新的原文是「We have applied the mitigation and are monitoring the recovery.」16

组件面上 Chat Completions 与 Responses 仍是 degraded_performance，站点整体还是 Partial System Degradation。17

22:17 那条 FedRAMP（Astra 与 Sol）还停在 identified，之后没有新更新。17

这段时间 5xx 变多，先读错误体：带 servers are currently overloaded 的那类容量让渡，v0.2.17 不给账号上任何状态。18

其余 5xx 仍可能把号打进临时不可调度，这段窗口里先看错误码再动手。18

这一小时的四仓

仓库	当前版本	窗口内动作
CLIProxyAPI	v8.0.38，北京 23:0619	一张补丁单 #6849；dev 头停在 23:0420
sub2api	v0.2.17，10 月 16 日21	#8258 多了一条维护者回复
codex-proxy	v2.1.20-beta.0543eaa22	零条目
codex2api	v3.1.123	零条目

额度与社区

codex-reset 今天（UTC）还没有重置，最近一次已验证的全局重置是 34 小时前。24

换成北京时间是 10 月 20 日 14:33；至今 56 次全局重置、10 张 banked。24

opentherank 记的是 64 次，中位间隔 3.1 天，最长一次 68 天。25

00:38（北京），官方开发者社区 Codex 分区冒出一条帖，把每次重置和 Sub2api 中转抢容量直接连在一起。26

帖里写正常用户撞上的是 Selected model is at capacity。26

上述是发帖人的判断与个人使用情况。26

收尾

这一小时要动的只有凭证配置那一层：use_siwc 为真的实例，先定是关掉 SIWC，还是等 #6849 合入。

跑易支付的站点，先翻审计再看网关。

References

1
PR #6849
github.com
2
#6833
github.com
3
codex_multi_agent_v2.go（v8.0.38）
github.com
4
optimize_multi_agent_v2.go（v8.0.38）
github.com
5
optimize_multi_agent_v2.go（v8.0.38）
github.com
6
codex_executor_auth.go 的 resolveCodexModelIsCompat
github.com
7
codex_executor_execute.go（v8.0.38）
github.com
8
management-api-v8.md（v8.0.38）
github.com
9
#8258
github.com
10
#8258 的回复
github.com
11
easypay.go（v0.2.17）
github.com
12
payment_webhook_handler.go（v0.2.17）
github.com
13
payment_fulfillment.go（v0.2.17）
github.com
14
easypay.go（v0.2.16）
github.com
15
Sub2API 0.2.17
github.com
16
status.openai.com 事件 01M5FHKHPQJMSHCE2B2WDPZW2N
status.openai.com
17
OpenAI 状态页
status.openai.com
18
openai_account_runtime_block_fastpath.go（v0.2.17）
github.com
19
CLIProxyAPI releases
github.com
20
CLIProxyAPI dev 提交
github.com
21
sub2api releases
github.com
22
codex-proxy releases
github.com
23
codex2api releases
github.com
24
codex-reset.com
codex-reset.com
25
opentherank.com/codex-reset
opentherank.com
26
Codex is a product, not a demo
community.openai.com

开着 SIWC 的 Codex 凭证，一开子代理就 400，v8.0.38 还没修

撞上的形态

这条路漏在哪

现在能做的三件事

怎么认出这一类凭证

次线：v0.2.17 的查单，把一批老网关的单子卡在二维码

上游这一小时

这一小时的四仓

额度与社区

收尾

References

Related content

开着 SIWC 的 Codex 凭证，一开子代理就 400，v8.0.38 还没修

撞上的形态

这条路漏在哪

现在能做的三件事

怎么认出这一类凭证

次线：v0.2.17 的查单，把一批老网关的单子卡在二维码

上游这一小时

这一小时的四仓

额度与社区

收尾

References

Related content