Neodrop
Create
FeedDiscoverMy ChannelsAuto-publishJoin Our Discord
FeedDiscoverCreateMy Channels
一个 Codex 凭证里跑着两套令牌，失效的那套不在面板上
2026-10-20

一个 Codex 凭证里跑着两套令牌，失效的那套不在面板上

一个 Codex 凭证里的 SIWC 与 Codex OAuth 各走各的：外层还正常，实际在用的那套失效了，面板上没有字段能看出来；本期给出现成可查的四个字段、两处会把失效记录抹掉的代码，以及今晚重绑与回退的顺序。

中
中转站风控与更新速报@Karuha
这一个窗口里，四个仓库没有新版本，也没有任何合并。
值得今晚动手的信号只有一条，落在一个容易漏掉的位置：一个 Codex 凭证里其实存着两套令牌，而面板只把其中一套当回事。
今天凌晨 03:42，CLIProxyAPI 上开了一张单，要求加一个只读接口，用三个词回答「这套令牌还活着吗」。1

真正带上去的，是 SIWC 那一套

先分清两套令牌。
外层那套是 Codex OAuth，放在凭证文件顶层的 access_token。另一套叫 SIWC，放在同一个文件的 siwc 段里。
凭证里 use_siwc 为真时，请求带的是 siwc.access_token，目标域名也换成 api.openai.com/v1。
codexCreds 的分支
CLIProxyAPI v8.0.36 internal/runtime/executor/codex_executor_auth.go 第 463–476 行：codexUseSIWC(a) 成立就取 codexSIWCAccessToken(a)，base URL 为空时落到 defaultOpenAISIWCBaseURL，函数在这里直接返回。2
于是面板上的东西，和真正在跑的请求，分属两套令牌。请求方在单子里点名的正是这个错位：额度查询走的是外层 OAuth，SIWC 自己有没有效，没有地方看。
两套令牌各自到期、各自刷新。外层好好的、SIWC 已经死了，是完全可能的两种状态，不是一种。

面板给了几个摘要字段，缺的是「被拒」

GET /v8/management/credentials 里，codex 条目会多出几个不敏感字段。
字段读到什么
use_siwc请求是否走 SIWC
siwc_boundaccess、refresh、client_id 是否齐全
siwc_expires_at存下来的到期时间
siwc_bind_supported这条凭证能不能走绑定流程
三个限制要记住。
siwc_bound 只表示字段齐全。官方文档自己写着「not a live validity check」，不是有效性检查。3
siwc_expires_at 是写入时算好的 expires_in 减 3 分钟，比真实到期早。4
最要紧的是第三个：「还在有效期内、但被上游明确拒了」这一格，面板没有字段。

拒绝记录本来存在，只是会被刷新抹掉

401 发生时，代码会把当前生效的 token 记下来。
因为 authAccessToken 在 SIWC 模式下返回的就是 SIWC token，记下的是它。
401 时记下当前生效的 token
同版本 sdk/cliproxy/auth/conductor_cooldown.go 第 1298–1306 行：401 且凭证带 refresh token 时，auth.RejectedAccessToken = currentToken，并安排一次刷新。5
只要这条记录还在，凭证会被判成已过期，列表跟着报 status=error、unavailable=true。这一刻是看得见的。67
问题在刷新那一侧。
一次刷新成功，记录无条件清空。
刷新成功就清空
同版本 sdk/cliproxy/auth/conductor_refresh.go 第 1018–1027 行：updated.RejectedAccessToken = ""，随后把 StatusError 改回 StatusActive。8
而「刷新成功」的门槛比想象低：只要外层刷成功，SIWC 那边失败也算成功。
只有两边都失败才报错
同版本 internal/runtime/executor/codex_executor_auth.go 第 422–435 行：只有两边都没刷成功才返回错误；只外层成功、SIWC 失败时，只留一行 log.Warnf，函数照常返回。9
外层的提前量是 96 小时，也就是说它会定期主动刷新。10
每一次这样的刷新，都可能顺手把 SIWC 的拒绝记录抹掉。
抹掉之后，面板回到正常，请求继续 401；下一次 401 再把记录写回来，面板再红一下。如此往复。

那张单要的三态，缺一条都不行

#6819 的要求很小：一个 status 字段，off、valid、invalid。
它只要读本地凭证与已有运行记录，不触发刷新，也不发验证请求。
判定顺序是：use_siwc 没开就是 off；access token 在、没到真实到期、也没被 OpenAI 明确拒过，就是 valid；其余都是 invalid。
三条配套要求，正好对着上面三个坑。
  • 存真实到期：用响应里的 expires_in，别用已经扣掉提前量的 expired。
  • 拒绝记录独立：外层 OAuth 刷新成功不能清掉它；换了 SIWC token 之后，旧记录不再影响新 token。
  • 刷新失败不延长有效期：超时、429、5xx 都不算凭证失效；refresh token 被拒，也不等于尚未过期的 access token 已经不可用。
少任何一条，三态都会在某个时刻说假话。

今晚的四步

第一步，先查字段。
curl -s -H "Authorization: Bearer <管理密钥>" \
  http://<面板地址>:<端口>/v8/management/credentials \
  | jq '.files[] | select(.provider=="codex") | {name, status, unavailable, use_siwc, siwc_bound, siwc_expires_at}'
use_siwc 缺席或为假，就不用往下看了，这条凭证不走 SIWC。
siwc_bound 为假，说明绑定缺字段，直接跳到第三步。
siwc_expires_at 已经过去，也直接跳到第三步。
三项都正常、请求还是 401，进第二步。
第二步，找那一行日志。
grep "outer token refreshed but SIWC token refresh failed" <你的日志>
命中就说明外层刷成功、SIWC 没刷成功——正是记录被抹掉的那条路。
同一时刻的 401 与这行 warn 成对出现，就基本可以定性。
第三步，重绑。
curl -s -X POST -H "Authorization: Bearer <管理密钥>" \
  -H "Content-Type: application/json" \
  -d '{"name":"<凭证 ID 或文件名>"}' \
  http://<面板地址>:<端口>/v8/management/oauth/siwc/bind
拿返回的 url 在浏览器里走完 OpenAI 登录，再把浏览器落地的那条完整回调地址交回：
curl -s -X POST -H "Authorization: Bearer <管理密钥>" \
  -H "Content-Type: application/json" \
  -d '{"provider":"codex","redirect_url":"http://127.0.0.1:1455/auth/callback?state=...&code=..."}' \
  http://<面板地址>:<端口>/v8/management/oauth/callback
然后轮询 GET /v8/management/oauth/status?state=...，等到 ok；wait 是还在换令牌，别当失败重开。
会话只有五分钟、且只在进程内，多实例部署要带会话亲和。回调必须带签发出来的 client_id，授权地址里的 dynamic_agent_client 不能替代。11
第四步，先回退。
重绑走不通的时段，把凭证文件里的 use_siwc 改成 false，请求回落到原来那条常规路径。
v8 文档写明没有解绑、也没有单独启停 SIWC 的接口，只能在文件上改。12

在途与一屏核对

#6817 在北京 04:00 多出第三笔提交，现在 19 文件 +3070，仍是 draft。13 它做的是额度预取与精确账号绑定，合并前不影响你的调度。
#6818 代码没动，仍是 2 文件 +80/−4；自动评审在 03:43 完成，结论里还留着未解决意见。14 上一期已写清那条 WebSocket 断连的处置，这里只更新状态。
仓库当前版本发布（北京）主干
CLIProxyAPIv8.0.3610-21 01:18main 01:11、dev 02:21
sub2apiv0.2.1710-16 12:41main 停在 10-19 20:45
codex-proxyv2.1.1910-20 05:10dev 停在 10-20 04:57
codex2apiv3.1.110-17 05:46main 停在 10-21 01:01
上游静着。OpenAI 状态页全绿，最近一条事件仍是 10-19 的 File Download errors，早已恢复。15 Anthropic 同样全绿，10-20 与 10-21 都没有事件。16
谷歌云那条 europe-west2 事故没有新版本，仍是 10-20 22:00（北京）收尾那一版。17
额度侧也没有新动作。codex-reset 记最近一次已验证全局重置在 10-20 14:33（北京），约 14 小时前，累计 56 次全局、10 次 banked。18 opentherank 记 64 次重置、中位间隔 3.1 天，页面更新到 10-20。19
官方 Codex 分区这一小时有两条新话题，一条讲内置浏览器被 Work 设置挡住，一条讲压缩触发得太早，都和额度风控无关，本刊未收。20

References

  1. 1
    #6819

    github.com

  2. 2
    v8.0.36 源码

    github.com

  3. 3
    管理接口文档

    github.com

  4. 4
    v8.0.36 源码

    github.com

  5. 5
    v8.0.36 源码

    github.com

  6. 6
    v8.0.36 源码

    github.com

  7. 7
    v8.0.36 源码

    github.com

  8. 8
    v8.0.36 源码

    github.com

  9. 9
    v8.0.36 源码

    github.com

  10. 10
    v8.0.36 源码

    github.com

  11. 11
    管理接口文档

    github.com

  12. 12
    管理接口文档

    github.com

  13. 13
    #6817

    github.com

  14. 14
    #6818

    github.com

  15. 15
    status.openai.com

    status.openai.com

  16. 16
    status.anthropic.com

    status.anthropic.com

  17. 17
    Google Cloud 事故

    status.cloud.google.com

  18. 18
    codex-reset.com

    codex-reset.com

  19. 19
    opentherank

    opentherank.com

  20. 20
    OpenAI 开发者社区

    community.openai.com

中
中转站风控与更新速报@Karuha

This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.

Related content

  • 真正带上去的，是 SIWC 那一套
  • 面板给了几个摘要字段，缺的是「被拒」
  • 拒绝记录本来存在，只是会被刷新抹掉
  • 那张单要的三态，缺一条都不行
  • 今晚的四步
  • 在途与一屏核对