强制刷新绕过三道拦截，已吊销的 Codex 凭证被放回号池
CLIProxyAPI v8.0.48 里点一次「刷新令牌」，会把刷新令牌已吊销的 Codex 凭证从 error 翻回 active，而 requires_sign_in 留在原处，下一次请求因此收到 401 而不是 503；这篇给出三条面板上能当场对上的指纹、被强制刷新让开的三道闸，以及今晚该改用 verify 验号的四条动作。
今天 16:24，CLIProxyAPI 的 issue 列表里多了一张单：手动刷新凭证，会把需要重新登录的 Codex 凭证送回路由。1
报障人手里有 5 个 Codex 凭证，其中一个的 refresh token 已被上游吊销。1
他点了一次面板上的「刷新令牌」。同一个号的状态从 error 变成 active，
requires_sign_in 留在原处。1紧接着发一个只由 codex 承接的模型请求，客户端收到 401。1
正文是
Encountered invalidated oauth token for user。1刷新之前，同一个请求拿到的是
503 auth_unavailable: no auth available。池子里没有可用凭证，一个都没被尝试。1单号池的站点最难分辨这两种回执：客户端的 key 完好，401 却长得像 key 出了问题。1
面板同时写着 active 和「需要重新登录」，运维在最不确定的那一刻只能自己猜。1
下面把这个按钮拆开看：它走哪条路、让开了哪三道闸、成功后清了哪些字段。1
今晚该用哪个接口验号，也在最后一节。行号取自 v8.0.48（commit
dbb70621）。1三条能当场对上的指纹
第三，再让这个号接一次真实请求，状态自己回到 error。1
修好它的是那次失败的上游调用。刷新按钮只负责把门打开。1
internal/api/handlers/management/auth_files.go 第 797–814 行：requires_sign_in、renewal_state、recovery_stage、inference_verified 由不同分支各自写入同一份返回体，两种相反的状态因此能同时出现。2按钮走的是强制刷新那条路
v8 的路径是
POST /v8/management/credentials/refresh。3v0 的老路径是
POST /v0/management/auth-files/refresh。4报障单里写的
/v0/management/credentials/refresh 在这两个版本里都不存在，照着敲会 404。1handler 认的参数是
name，凭证 ID 或文件名都行。4通过校验后调
ForceRefreshAuth，刷新出错回 500。4它的候选条件是「未禁用，且有 refresh 凭证或运行时」，带着
requires_sign_in 标记的号同样会被刷一遍。5定时脚本里那句
{"all": true} 因此会把池子里所有待重登的号一次放回去。
internal/api/handlers/management/auth_files_refresh.go 第 53–71 行：name 为空回 400、找不到回 404，随后才调 ForceRefreshAuth 并返回整份凭证。4三道闸都挂着 !forceRefresh
sdk/cliproxy/auth/conductor_refresh.go 第 1244–1262 行：第 1247、1250、1262 三行的条件里都带着 && !forceRefresh，强制刷新走到这里，三处拦截同时失效。6refreshAuthForRequestAtEpoch 里连着三道闸。6第 1247 行拦「invalid_grant 已禁用」的号，第 1250 行拦「未授权失败」的号。6
第 1262 行拦「refresh token 被拒且没换过」的号。6
三个条件后面都挂着
&& !forceRefresh。6第二道判的
hasUnauthorizedAuthFailure 要求四件事同时成立。6凭证不可用、状态是 error、两个重试时刻都为空、最后错误是 401。6
第三道就是产出
unauthorized (refresh token invalid) 的地方。6它把不可用置真、状态置 error、
RequiresSignIn 置真，再把刷新任务摘掉。6带 force 标记的请求走到这三行，
!forceRefresh 已经为假，三道闸同时让开。6本来被判死刑的号于是重新进入刷新流程。6
成功分支只看一个字段
sdk/cliproxy/auth/conductor_refresh.go 第 1516–1538 行：第 1528 行的条件只看 RejectedAccessToken，条件成立就把 LastError、StatusMessage、Unavailable 一起清掉，RequiresSignIn 不出现在这一段里。7刷新成功后的收尾在第 1528–1537 行。7
条件是
RejectedAccessToken 为空、或与当前 access token 不同。7RefreshFailures 归零，状态改回 active，模型级的未授权状态一并清掉。7选号侧也读不到它。8
真正拦号的是
isAuthBlockedForModel，它看不可用标记与凭证级额度冷却。8清掉不可用，门就开了。8
影响面：三个要记住的细节
第一，401 与 503 的含义差得很远。1
503
no auth available 说明池子空了，客户端通常会重试或报警。1401 会被当成 key 无效，很多客户端直接停止重试。1
第二，
all=true 只跳过已禁用的号。5想把待重登的号真正隔离，得把它设成 disabled。5
报障人自己的生产绕法也是这一条。1
第三，刷新响应体带明文的
metadata.access_token。1任何把这段响应打进日志或转发到前端的脚本，都会让 token 落到不该落的地方。1
报障人还提到，运行时不落盘，重启之后这个号会回到文件里的旧状态。1
于是故障看起来像间歇的，很难归因到那个按钮上。1
今晚可以做的四件事
- 验号用
POST /v8/management/credentials/verify。 它走到推理校验那一步时，遇到RequiresSignIn直接回 409credential requires sign-in before inference verification。9 - 已经被刷回 active 的号，先禁用再重登。 禁用之后
all=true也刷不到它。 - 翻一遍定时任务里的全量刷新。 池子里有死号时，每次执行都会重新打开这个窗口。
- 客户端报 401 时先看面板两个字段。
requires_sign_in为真，就是账号要重登。
顺带区分一个容易混的接口。10
冷却接口处理「等一等还能用」，重登处理「凭证已经换了」。这两个按钮在面板上离得很近。10
次线：Grok 路径不认 agent_message
17:20，sub2api 仓库里另一张单落在同一个形状上。11
请求里带的字段本地不认识，被原样送去上游，上游回 422，客户端看到 502。11
返回 502
Upstream request failed。11运维错误记录里写着
xAI upstream returned status 422。11
sanitizeGrokResponsesModelInput：第 71 行的 switch itemType 只列了文本类与工具调用类两组，agent_message 不在其中。12源码里
agent_message 没有分支，条目落到第 149 行被原样留在请求里。13同一个修订的 Chat Completions 桥接已经处理过这个条目，会调
agentMessageText 取出正文。14缺的是 Grok 原生 Responses 这一侧的同一份适配。11
今天的绕法只有一条：让承接 Codex 多智能体流量的分组避开 Grok 账号。11
把这段流量交给已经适配过的桥接路径，也能绕开。11
报障单还提醒，真实 Codex 请求的任务正文可能落在
encrypted_content 片段的明文里。11只保留
input_text 的信封会丢任务。11短讯
PR #8462：生图账号按 1K/2K/4K 尺寸档位分流。 open、非 draft，1 笔提交、21 个文件、+1398/−9。15
账号的
extra.openai_image_size_tiers 写允许的档位。缺省或三档齐全都表示不限，存量账号不用迁移。15分组里没人接该档位时回 400；PR 写明这么选是因为 503 会让下游实例冷却自己的账号。15
PR #7639：muse 通道的第 34 笔提交。 18:00 那笔把浏览器会话直接接进号池，累计 34 笔提交、131 个文件、+10206/−120。16
昨天那期把同一笔记在了 #8459 上，这里更正。17
#8459 停在 7 笔提交，最后一笔在 15:50，窗口内没有新代码。17
PR #7761：调度快照补上端点能力。 窗口内补了一轮测试，现在 2 笔提交、2 个文件、+77/−1。18
它把
openai_capabilities 补回调度快照的 extra 白名单，合并前不必改配置。18上游与社区这一窗口
四仓这一窗口零发版、主干零提交。当前版本是 CLIProxyAPI v8.0.48，10 月 30 日 22:37 发布。19
三家状态页都干净。OpenAI 现为全绿，最近一条事故在 10 月 31 日凌晨 03:38 到 05:14 已恢复。23
上游重置：codex-reset 首页写着今天还没有重置，最近一次已验证的全局重置在 10 月 28 日 14:35。26
它的累计读数是 61 次全局重置、10 次存下；24 小时概率 46%、48 小时 71%。26
API feed 里
signal.active 为假，最新一条官方信号停在 10 月 22 日。26opentherank 记 69 次、中位间隔 2.9 天。27
社区这一窗口的额度类信号只有一条。28
16:18，有人在 r/GeminiAI 问 Mac 上的 Gemini 4 Argon。28
他说每次都被提示 high using time，模型被切到 flash auto。28
References
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10CLIProxyAPI v8.0.48 quota.go 第 27–70 行
github.com
- 11
- 12
- 13
- 14
- 15feat(openai)：生图账号按 1K/2K/4K 尺寸档位分流
github.com
- 16
- 17sub2api PR #8459
github.com
- 18
- 19CLIProxyAPI v8.0.48 发行页
github.com
- 20sub2api v0.2.19 发行页
github.com
- 21codex-proxy v2.1.21 发行页
github.com
- 22codex2api v3.1.2 发行页
github.com
- 23OpenAI 状态页事故记录
status.openai.com
- 24Claude 状态页
status.claude.com
- 25Google Cloud 状态页事故记录
status.cloud.google.com
- 26codex-reset 首页读数
codex-reset.com
- 27opentherank Codex 重置统计
opentherank.com
- 28
- 29
- 30
- 31Google 官方开发者论坛 Gemini API 分区 RSS
discuss.ai.google.dev
- 32Google 官方开发者论坛 Antigravity 分区 RSS
discuss.ai.google.dev
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.