账号页点了禁用，降智检测还在按间隔敲门：codex2api 修在主干；插件执行器五处配置静默不生效
codex2api 的降智检测不读账号启停，禁用之后仍按间隔发请求，修复已进主干等 v3.1.2；CLIProxyAPI 的插件执行器上五处配置不生效，其中三条补丁今天已进 dev。
北京 19:49 到 20:50 这一个小时，中转这边出了两件现在就要知道的事：一件在你自己的面板里，一件在插件执行器的代码里。
同一小时里，CLIProxyAPI 开出五张关于插件执行器的单，其中三张的补丁已经在 20:41 前落进 dev。3
结论先说
今天没有可升级的新版本。四仓发行版仍是 CLIProxyAPI v8.0.41、sub2api v0.2.18、codex-proxy v2.1.20、codex2api v3.1.1。
现在能做的三件事：
- 在 codex2api 上，把不想被探测的账号的「检测」勾选取消，或者临时关掉全局自动检测。
- 给插件承载的模型配过
payload.default/override/filter的，先当作没生效。 - 插件路径不解析思考后缀，要档位就直接写进请求体。
codex2api：禁用只把它移出调度，检测这条路照旧
报障单 #814 是 10-22 上午 09:53 开出的一句话：「api 在禁用的情况下还是会进行降智测试」。1
维护者在今天 19:53 回帖，先说结论：已定位并修复，提交 1511374d 已推到 main，随 v3.1.2 发布。1
根因写在回帖第二段：自动降智检测只看两个开关，全局「自动检测」和每个账号自己的「检测」勾选。账号页的启用／禁用状态，它从来没读。1
账号被禁用，只是不再参与业务调度。检测按 300 秒的间隔照常排期，照常发请求。4
发行版里那几处判断，都缺账号这一维
认领排队任务的 SQL 更直接：
account_id IN (SELECT account_id FROM intelligence_check_accounts WHERE enabled=TRUE)，同样只看检测开关。6真正开始跑之前还有一道判断，但它读的
a.Enabled 就是检测开关本身。7面板上那条「排队中」也是同一个原因：残留的自动任务被当成进行中，账号禁用了它就一直转。9
修法：把三种开关合并成一个谓词
主干新增一个函数，要求检测开关与账号启用同时为真。10
func intelligenceAutomaticSQL(account, state string) string {
return state + `.enabled=TRUE AND COALESCE(` + account + `.enabled,TRUE)=TRUE`
}开始执行前那句也补上了账号这一维，变成
!s.Enabled || !a.Enabled || !a.ManualEnabled。13整笔提交 5 个文件、加 65 行减 11 行，带两个测试文件的用例。2
james-6-23/codex2api 主干 database/intelligence_check.go 第 229–240 行：第 233–234 行的注释写明「只放行进自动排期的账号」，第 236 行的条件同时要求检测开关与账号启用；上面第 230 行是原有的资格判定，仍管平台与状态。三件保持不变的行为
手动点「立即检测」对禁用账号仍然可用，回帖把这条算作明确的人工操作。1
禁用那一刻已经在跑的那一次检测会正常跑完。因质量不合格被自动暂停的账号继续复测，好让达标后自动恢复。1
禁用之前已经排队的自动任务不会丢，只是保持 queued，重新启用后接着跑。2
今天在 v3.1.1 上怎么办
发行版没动，v3.1.1 是 10-17 05:42 发的，上面那三处判断原样在里面。14
要立刻止住，按顺序做：
- 在降智检测页把该账号的「检测」勾选去掉；这是入队那句 SQL 唯一认的条件。
- 如果禁用了一批账号，暂时把全局「自动检测」关掉，手动的照旧能用。
- 回面板看检测条，若还挂着「排队中」，说明那条 queued 任务是禁用前留下的，升级后会自动消失。
判据也简单：升级到带 1511374d 的版本之后，禁用的账号不该再出现新的自动检测记录。出了就贴那条记录的「来源」与账号状态给维护者。1
五张插件单：三条已经进 dev，两条还开着
19:42:03 到 19:42:07 的四秒里，同一位报障人（jonatanpolak）连开五张单，每条都附了复现与一份补丁。15
| 单号 | 现象 | 你这台会看到什么 | 状态 |
|---|---|---|---|
| #6936 | 跨源重定向不剥凭证头 | 跳到别的主机时，插件的 key 跟着走 | 已进 dev |
| #6937 | 错误带不出 Retry-After | 插件模型限流时，本地冷却与客户端都拿不到等待时间 | 已进 dev |
| #6938 | count_tokens 回复被当模型响应翻译 | 客户端拿到整条 assistant 消息，里面没有 token 数 | 已进 dev |
| #6939 | payload 规则对插件执行器失效 | 给插件模型配的规则一条都不生效 | PR #6944 开着 |
| #6940 | 思考管线被跳过 | 后缀原样送出去，非法后缀与超预算也不拦 | 只有单，没有补丁 |
三笔落地提交的署名都是维护者 Luis Pater，时间分别是北京 20:35、20:40、20:41，补丁以提交形式直接落在 dev 上。3
凭证头：Go 的默认策略管不到端口
发行版的
CheckRedirect 只做三件事：记下这次重定向请求、关掉空闲连接、数到第 10 跳就报错。16
router-for-me/CLIProxyAPI v8.0.41 的 internal/pluginhost/http_bridge.go 第 507–521 行：第 514 行的回调里只有记录、关连接、跳数上限三步，没有任何剥头动作。落进 dev 的补丁按有效 origin 判定，scheme、规范化主机名、有效端口三者都算，默认端口视为同源。17
报障人自己说了句实话：他没在真实上游身上复现过，这是纵深防御。15
Retry-After：插件的错误里没有这个字段
宿主把 429 交给上游重试链时，靠的是一个
RetryAfter() 接口。没有这个接口，取到的就是空。19空值让冷却退回通用退避：1 秒起，逐次翻倍，封顶 30 分钟。上游说的「等 7 秒」被换成了本地猜的数。20
客户端那一侧同样拿不到头：写响应头的那张白名单只认几种内置错误类型，插件错误不在里面。21
报障人拿假上游验过：回 429 加
Retry-After: 7，客户端只收到 429 和 JSON 体。22
sdk/pluginabi/types.go 第 123–132 行：第 128–129 行的注释说明 http_status 缺省会被当成 500；结构体里没有「等多久」这一项，这就是插件说不出 Retry-After 的原因。进 dev 的那笔加了可选
retry_after_seconds，非正数忽略，超大值按最大时长截断。23count_tokens：插件回的是数字，客户端收到的是消息
插件的
CountTokens 把回复交给模型响应翻译器，这条路径和普通响应是同一个函数。24翻译器在源格式与目标格式不同时动作，也就是插件声明 chat-completions、客户端走 Claude 的那种情况。25
内置执行器不走这条路，它们用专门的 token 计数翻译函数。27
internal/pluginhost/adapters_executors.go 第 983–1015 行：第 1005 行把插件回复交给 translateExecutorResponse，而该函数的非流式分支走 sdktranslator.TranslateNonStream——模型响应用的那一套。进 dev 的那笔改成先认整数计数、再拒绝模型响应形状的载荷，格式一致时保持原样。28
payload 规则：插件这条路上根本没接
在 v8.0.41 的
internal/pluginhost 目录里搜不到 ApplyPayloadConfig、NewPayloadFinalizer、ApplyRequestThinking 的任何一次调用。29开着的补丁 #6944 只覆盖一部分：它只改「POST + 顶层
model 与执行器模型一致」的 JSON，带签名头的请求不动，因为宿主没法替插件重新签名。32思考管线那张单还停在设计问题上。作者在等维护者先定两件事：后缀要不要从送到插件的模型名里剥掉，声明了思考元数据却没注册 applier 的插件怎么办。33
这件事对运维意味着什么
如果你没有插件承载的模型，这五条今天都不碰你。
如果有，按影响从大到小排：payload 规则静默失效最容易被忽略，因为它看起来配置成功、运行也不报错。29
思考后缀次之，行为是「设了等于没设」，只有看上游请求体才发现。33
次条
Antigravity 的 Gemini 4 Argon 有一条正在评审的补丁：长多轮请求以纯 tool-result 收尾时，上游先回 200 流式吐推理，再回 400
INVALID_ARGUMENT。34同窗口另开两张：Kimi 把 Responses 的自定义工具桥成 functions，补丁 19:57 开出；35 home 集群里被取消的 rebalance RPC 一直不返回，20:10 记成一单，描述指向 go-redis 的 Close 排在阻塞读后面。36
上游风控侧有一条值得留个记号：openai/codex 上有人报 CLI 0.164.0 在正常代码评审里被
cyberPolicy 反复拦，模型是 gpt-6.1-sol，codex doctor 21 项全绿，帖子到发稿仍是 0 回复。39这一条按未证实处理，只是说上游的代码策略拦截仍在误伤正常请求。
社区这一轮扫了四处。OpenAI 社区 Codex 分区窗口内两条：18:39 一条讲 SIWC 下
response.metadata 客户端怎么处理，18:03 一条是界面建议。40Reddit 上 r/GeminiAI 有一条 18:52 的报障，说连 Flash 版也在超额消耗，发帖人给了一个 Python 脚本跑在 skill 里的用法，暂时没有回应。43
r/ClaudeAI 窗口内的两条分别问采购与听写，跟封号与额度无关。44
状态与额度
- 四仓发行版：CLIProxyAPI v8.0.41（北京 10-24 02:25）、45 sub2api v0.2.18（10-23 15:44）、46 codex-proxy v2.1.20（10-23 03:56）、47 codex2api v3.1.1（10-17 05:42）。14
- 分支头：CLIProxyAPI dev 到 20:41、main 停在 10-24 02:18；48 codex2api main 到 19:52，就是那笔修复；49 codex-proxy dev 停在 10-23 03:54。50
- 上游三家全绿：OpenAI 最近一条事件是 CIMD 连接降级，北京 10-24 07:43 已恢复；51 Anthropic 页面 19:39 更新，全部 Operational；52 Google Cloud 最近仍是 europe-west2 的 Multiple Products，最后更新在 10-23 00:19。53
- 额度：codex-reset 首页写今天 UTC 还没重置，最近一次已验证的全局重置在北京 10-23 01:10（约 44 小时前），累计 57 次、账上 10 张，节奏约每两天。54
- opentherank 记的是 66 次、中位间隔 3 天、最长 68 天，更新到 10-24。55
- Tibo 的最新一条帖停在 10-24 11:41，落在本窗口之前，窗口内没有重置表态。56
References
- 1codex2api issue #814
github.com
- 2提交 1511374d
github.com
- 3CLIProxyAPI dev 提交
github.com
- 4
- 5
- 6同文件第 223 行
github.com
- 7同文件第 273 行
github.com
- 8
- 9
- 10
- 11
- 12主干同文件第 585 行
github.com
- 13主干同文件第 273 行
github.com
- 14codex2api v3.1.1 发行页
github.com
- 15CLIProxyAPI issue #6936
github.com
- 16
- 17PR #6941
github.com
- 18
- 19
- 20
- 21
- 22CLIProxyAPI issue #6937
github.com
- 23PR #6942
github.com
- 24
- 25同文件第 544–566 行
github.com
- 26CLIProxyAPI issue #6938
github.com
- 27
- 28PR #6943
github.com
- 29CLIProxyAPI issue #6939
github.com
- 30
- 31
- 32PR #6944
github.com
- 33CLIProxyAPI issue #6940
github.com
- 34PR #6935
github.com
- 35PR #6945
github.com
- 36CLIProxyAPI issue #6946
github.com
- 37sub2api main 提交
github.com
- 38sub2api PR #8323
github.com
- 39openai/codex issue #56695
github.com
- 40OpenAI 社区 Codex 分区
community.openai.com
- 41Antigravity 分区
discuss.ai.google.dev
- 42Gemini API 分区
discuss.ai.google.dev
- 43r/GeminiAI 那条超额消耗帖
reddit.com
- 44r/ClaudeAI
reddit.com
- 45CLIProxyAPI v8.0.41 发行页
github.com
- 46sub2api v0.2.18 发行页
github.com
- 47codex-proxy v2.1.20 发行页
github.com
- 48CLIProxyAPI main 提交
github.com
- 49codex2api main 提交
github.com
- 50codex-proxy dev 提交
github.com
- 51OpenAI 状态页
status.openai.com
- 52Claude 状态页
status.claude.com
- 53Google Cloud 状态页
status.cloud.google.com
- 54codex-reset
codex-reset.com
- 55opentherank
opentherank.com
- 56
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.