10/20 上午速报：Codex 设备登录还没接进 v8 管理接口，同一端点的 xai、meta、kimi 早已返回 user_code
v8 管理接口里的 Codex 登录今天只回浏览器回调，设备码得进容器从 stdout 捞；同一端点上 xai、meta、kimi 早已返回 user_code，PR #6715 把 codex 这一支补上但还没合并。
这一期从上一期发稿的 08:56 到现在，一小时多一点。
四仓这一窗口都没有新版本：sub2api 仍是 v0.2.17，CLIProxyAPI 仍是 v8.0.35，codex-proxy 仍是 v2.1.19，codex2api 仍是 v3.1.1。1234
主干也没动：CLIProxyAPI 的 main 停在 10 月 19 日 16:55 的
ae3ee3be，dev 停在 10 月 20 日 00:13 的 c449529e。56 sub2api 的 main 停在 10 月 19 日 20:45 的 8f2cbb53。7窗口里在动的是 CLIProxyAPI 的 PR #6715：给 v8 管理接口补上 Codex 的设备登录。北京 09:06 它落下第八笔提交，内容是一次测试侧的清理。8
先给三条结论。
- v8.0.35 会忽略
flow=device，仍走浏览器回调，响应里没有user_code。 - 设备登录今天只能从命令行跑，码打在进程的 stdout，时限 15 分钟。
- 同一个端点上，xai、meta、kimi 三家早就把
flow: device、user_code、expires_in一起返回了。
flow=device 今天会被忽略
PR 新建的
auth_files_codex_device.go，在 v8.0.35 与 dev 两个 ref 下都取不到。10
case "codex" 后只有 h.RequestCodexToken(c)，同文件里 kimi、xai、meta 走的都是各自的处理器，没有一处读 query 里的 flow。于是照 PR 文档传
flow=device，客户端拿回来的仍是浏览器回调那一套：status、url、state，没有用户码。设备码今天只从进程 stdout 出
loginWithDeviceFlow 在拿到用户码后直接打到 stdout：第 88 行打 https://auth.openai.com/codex/device，第 89 行打用户码。上面第 61 行就是那个 metadata 判断，命令行之外没有别的入口会走到这里。时限写在同一个文件的常量块里：
codexDeviceTimeout = 15 * time.Minute。14所以容器里今天的做法是：exec 进容器，跑一次
./cli-proxy-api --codex-device-login，从控制台捞出那两行，15 分钟内把码输进设备页。同一个端点，三家已经接好了
auth_files_provider_oauth.go 里，xai、meta、kimi 三家的处理器都已经把设备码挂进 v8 的响应：flow: "device"、user_code、expires_in 三个字段一起返回。151617
flow: device，第 906–908 行补 user_code，第 909–911 行补 expires_in；这个 handler 挂在 /v8/management/oauth/auth-url?provider=kimi 后面。也就是说，v8 管理接口本身有这套返回格式，codex 这一支还停在浏览器回调上。
合并之后长什么样
PR #6715 现在 open、非 draft、8 笔提交、12 个文件 +822/−33，头提交
3a4dea2bc5，可合并状态 clean。8按头分支的实现，
provider=codex&flow=device 的成功响应是六个字段：status、url、state、flow、user_code、expires_in。expires_in 写成 900 秒，取自上面那个 15 分钟时限。10
httpwire.FlushResponse 把响应推出去，第 129–130 行才置 handedOff 并放行保存。客户端在 flush 之前断开，第 126 行直接返回，会话被丢弃。启动有 30 秒上限（
codexDeviceStartTimeout）。超时回 504 device authorization flow timed out；拿到码但字段不全回 502 invalid device authorization response；流程根本没起来回 502 failed to start device authorization flow。10之后走两条现成路由：轮询
GET /v8/management/oauth/status?state=，取消走 DELETE /v8/management/oauth/session?state=。取消的语义这次补了一道闸：新增的 BeginSave 在落盘前先占住会话，Cancel 碰到已占住的会话就返回 cancelled: false。18对写客户端的人，这条意味着：拿到
cancelled: true 表示凭证不会落盘；拿到 false 就继续轮询状态，重开一轮会与正在落盘的那次撞车。今天能做什么
跟发行版。 今天没有可升的版本，v8.0.35 的行为就是上面第一节写的那样。2
今天就要把号加进去。 命令行那条在上一节。走接口的，起浏览器回调流，把登录后跳到的
http://127.0.0.1:1455/auth/callback?... 整段回贴给 POST /v8/management/oauth/callback，body 里带 provider 与 redirect_url。19 这条路由在 v8 下是挂着的。20 无头机器上它一直能用，代价是每次手工复制一次地址。自建。 PR 头分支在 fork 上（
JustYannicc:feat/management-codex-device-auth），可以 checkout 自己构建；v0 的路由这次不动。8测试连接与转发，取的是两份 token
sub2api 的 #8134 在北京 09:28 有了报障人的回话：「应该是配了路由之后，错误消失了」。21
这张单 10 月 16 日开的，现象是控制台「测试连接」返回 200、正式转发却报
OAuth 401: Invalid bearer token 并进临时不可调度。22贡献者在核对里指出一处可对照的分叉：控制台测试直接读账号里存的 access token，正式转发走 TokenProvider，而 provider 会先返回缓存里非空的 token。23
两条路取到的 token 可以不同，所以「测试通过」与「转发可用」是两份独立的读数。
处置按这张单里验证过的顺序：先给要用的模型配精确路由（他的例子里是
gpt-6.1-sol → OpenAI）；仍反复 401 就对这个账号重新授权一次；多实例部署留意同一账号被多处并发刷新。要定位就带 account_id 与 upstream_status 两个字段，日志里把 token 脱敏。23贡献者还把这张单与两张待评估的恢复补丁关联起来：#7826（HTTP 一次刷新重试）与 #8034（到期判断与 WebSocket 恢复）。
上游与额度
OpenAI 全绿，0 条活动事件，0 个降级组件。26 最近一条已解决的是 10 月 19 日的文件下载错误：北京 21:31 报出、22:14 解决，都在本窗口之前。
Anthropic 全绿，今日无事件。27
Google Cloud 仍是 7 条，最近一条是 10 月 8 日到 9 日的 Cloud Storage。28
Codex 今天 UTC 仍未重置。最近一次已验证的全局重置在北京 10 月 18 日 04:41，距今两天。29 页面记 55 次全局、10 次 banked、节奏约每 3 天；两套概率口径是 21%/37% 与 45%/70%，后者把 10 月 18 日那条「We'll see」也算进了样本。
opentherank 记 63 次、中位间隔 3.1 天、最长 68 天（2025 年 12 月 25 日到 2026 年 3 月 3 日）；它记的最近一次是 10 月 17 日 21:12 UTC。30
未收与待跟
官方社区 Codex 分区窗口内一条新帖，北京 09:07 的「Plus 套餐的 5 小时用量表在哪看」，属产品提问，未收。31
Reddit 的 r/OpenAI 窗口内 0 条，最新一条在窗口前；19 日白天那几条「额度掉得比平时快」全在窗口外，未收。32
codex2api #809（北京 09:31 开、
type/question、0 评论）问的是：额度耗尽、上游开始回 503 之后，质检为什么仍显示正常。33 按 v3.1.1 的实现与文档，上游返回非 200 时这一格记 error、不会写成 normal。34 这张单还没有回复，现象未验证，未收。sub2api PR #7940 是一次 seedance 任务 ID 与路由凭据的修复，窗口内只有一条解冲突的评论，仍 open，与中转运维无关，未收。35
要盯三件：
- #6715 何时合并进 dev，合并后落哪个 tag。
- #8134 关联的 #7826 与 #8034 会不会合并。
- 上期报的 #6788 修复仍在 dev，等下一个 tag 才到读者手上。
References
- 1sub2api Releases
github.com
- 2CLIProxyAPI Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5CLIProxyAPI 主干提交
github.com
- 6CLIProxyAPI dev 提交
github.com
- 7sub2api 主干提交
github.com
- 8PR #6715
github.com
- 9v8.0.35 的 auth_files_v8.go
github.com
- 10PR 头分支新建的设备登录处理器
github.com
- 11v8.0.35 的 sdk/auth/codex_device.go
github.com
- 12cmd/server/main.go 里的命令行开关
github.com
- 13命令模式的判定
github.com
- 14v8.0.35 的 sdk/auth/codex_device.go
github.com
- 15v8.0.35 的 auth_files_provider_oauth.go
github.com
- 16meta 的返回在第 700–710 行
github.com
- 17kimi 的返回在第 905–912 行
github.com
- 18
- 19v8 管理接口文档：回调可以用 redirect_url 回贴
github.com
- 20v8 的回调路由
github.com
- 21报障人 09:28 的确认
github.com
- 22sub2api #8134
github.com
- 23#8134 里对两处取 token 路径的核对
github.com
- 24v0.2.17 的 account_test_service.go
github.com
- 25v0.2.17 的 openai_token_provider.go
github.com
- 26status.openai.com
status.openai.com
- 27status.anthropic.com
status.anthropic.com
- 28status.cloud.google.com
status.cloud.google.com
- 29codex-reset.com
codex-reset.com
- 30opentherank Codex 重置追踪
opentherank.com
- 31community.openai.com Codex 分区
community.openai.com
- 32r/OpenAI
reddit.com
- 33codex2api #809
github.com
- 34v3.1.1 的质检说明
github.com
- 35sub2api PR #7940
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.