T3 Code 的入口点白名单进了 dev；插件刷新会把你停用的号重新启用 (2026)

窗口从北京时间 11 月 3 日 12:49 起算，到 13:24 收笔。四个仓库都没有发出新版本。

CLIProxyAPI 的开发分支比发行版 v8.0.52 多 11 笔提交。其中两笔带 Closes，都落在这一小时里。

一笔让自定义入口点可以写进配置，另一笔堵住插件刷新重新启用停用凭证的漏洞。两条修复都还在 dev，下面各给一条今天能执行的处置。

本期版位

仓库	最新版	发布时间（北京）	窗口内
CLIProxyAPI	v8.0.52	11 月 3 日凌晨	零发版，dev 多 11 笔
sub2api	0.2.19	10 月 28 日 18:16	零发版
codex-proxy	v2.1.22	11 月 3 日 07:35	零发版
codex2api	v3.1.2	10 月 28 日 04:40	零发版

发行版这一小时没动过，两笔修复要等下一版才拿得到1。

一、T3 Code 这类客户端，入口点能写进配置了

T3 Code 走的是 CLAUDE_CODE_ENTRYPOINT=t3-code。中转把它当外来客户端，于是照常做隐身改写。

报障单 #7224 附了逐字段对照表。T3 Code 与官方的 sdk-ts 在 X-App、beta 列表、Stainless 版本、metadata.user_id、system blocks、tools 上完全一致，差别只在 UA 的那一段和 billing 头里的入口点2。

修复是提交 6d4102f3，9 个文件 +261/−31，12:51 落到 dev3。

它新增的键写在 upstream.claude.header-defaults 下面：

upstream:
  claude:
    header-defaults:
      native-entrypoints: ["t3-code"]

dev 的示例配置把这一整块注释掉了，第 504 行起都是 # 开头。运维要自己取消注释，或者新建这个键4。

dev 分支 config.example.yaml 第 490–519 行：header-defaults 整块示例配置，第 515 行是本版新增的 native-entrypoints 写法 — *dev 分支 `config.example.yaml` 第 490–519 行。这一段整块是注释掉的，第 515 行 `# native-entrypoints: ["t3-code"]` 就是新增的那一行，照抄后要把行首的 `#` 去掉4*

配置值进内存前会被规范化。normalizeClaudeEntrypointNames 做四件事：小写化、去首尾空格、丢掉空串、按原顺序去重。

全空时返回 nil，等于没配。这段逻辑在 dev 的 internal/config/config_normalization.go，由配置规范化阶段调用5。

dev 分支 config_normalization.go 第 85–114 行：normalizeClaudeEntrypointNames 的完整实现 — dev 分支 `internal/config/config_normalization.go` 第 85–114 行。函数体（第 88–111 行）逐个处理字符串：小写、TrimSpace、跳过空串、按首次出现顺序去重，最后判空返回 nil5

判定侧的内置四项没有改动，仍是 cli、sdk-cli、sdk-ts、claude-vscode。新加的 isNativeClaudeEntrypoint 在这四项之外再读配置。

命中配置时，subclient 会合成成 claude-code-<entrypoint>，测试里断言 t3-code 得到 claude-code-t3-code。

dev 分支 claude_client_detection.go 第 54–99 行：内置四项入口点、新增的 isNativeClaudeEntrypoint 与 claudeSubclientForEntrypoint — dev 分支 `internal/runtime/executor/helps/claude_client_detection.go` 第 54–99 行。第 67–72 行的内置四项原样保留，第 74–91 行是新加的配置判定，第 93–99 行负责把命中项合成 subclient 名6

这里有一条容易被忽略的前提。确认条件仍是「强信号且是 native 客户端」，两项都要成立。

提交里的测试专门断言了这一点：加上配置、但删掉 Anthropic-Beta 头，请求仍然判为未确认3。

强信号包括 X-App: cli、UA 里的 claude-cli/…(external, <entrypoint>) 段、claude-code beta 头，以及 metadata.user_id。count_tokens 那类请求单独放宽。

确认之后，线路策略会直接放行。resolveClaudeWirePolicy 在 confirmedClaudeCode 为真时把 policy.Cloak 置 false 并返回7。

发出去的 billing 头仍按入口点写，cc_entrypoint 保留真实值，方便上游侧对账。

副作用落在设备指纹上。claudeDeviceProfileSubclientScope 改用同一个判定函数，自定义入口点从 other 桶变成独立桶。

开了 stabilize-device-profile: true 的实例，升级后这一组凭证会重建一次指纹。UA 与 beta 头稳定的客户端不受影响，混用多种客户端的号池会出现一次集中抖动。

风险面要讲清楚。入口点是从 UA 文本里解析出来的，能自造 UA 的客户端同样能搭上这条直通路。

这条键在 v8.0.52 上写下去会被静默忽略。配置加载走的是 yaml.Unmarshal，没有开严格字段校验，拼错的键也不会报错。

今天的替代处置按凭证走。在 OAuth 凭证 JSON 里写 cloak_mode: never，或者给 API key 写 api-keys.claude[].keys[].cloak.mode。

全局的 upstream.claude.disable-claude-cloak-mode 先别动。它会把所有 Claude 请求一起关掉，包括你还没想清楚的那些客户端。

二、插件刷新会把已停用的凭证重新启用

报障人 Rick7C2 给的四步复现很干脆：

注册一个 RefreshAuth 只回 Provider、ID、Metadata 的 auth provider 插件；
用 PATCH /v8/management/credentials/status 把某张凭证停用；
调 POST /v8/management/credentials/refresh；
凭证回到 active 状态。

根因在刷新回填那一步。Host.RefreshAuth 会把 ID、Label、Metadata、StorageJSON、NextRefreshAfter 从旧记录带过来。

Disabled 不在回填名单里，它只取插件返回的 AuthData。Go 的 bool 没有「未设置」这个状态，插件返回一个最小结构体，就等于把停用标志写成了 false。

v8.0.52 的代码里可以直接看到缺口。auth_provider.go 第 1009–1010 行连着两个 preserve 函数，中间没有第三行。

v8.0.52 的 auth_provider.go 第 994–1022 行：刷新回填只有 preserveAuthOAuthProviderMetadata 与 preserveFileAuthPriority 两处 — v8.0.52 `internal/pluginhost/auth_provider.go` 第 994–1022 行。第 1009 行与第 1010 行之间就是缺陷现场：这里少一个把停用状态带回去的函数，全文件搜 `preserveAuthDisabledState` 命中 0 处8

提交 04208efa 补上了这一环，4 个文件 +174 行，13:00 落到 dev，Closes #72259。

新函数叫 preserveAuthDisabledState。旧记录里 Disabled 为真、或 Status 是 StatusDisabled，就把新数据里的 Disabled 置回真。

它在两处被调用：Host.RefreshAuth 里一次，执行器适配器的 Refresh 里一次。两条刷新路径都盖住了。

dev 分支 auth_provider.go 第 1039–1064 行：preserveAuthDisabledState 全文与判定条件 — dev 分支 `internal/pluginhost/auth_provider.go` 第 1039–1064 行。第 1052–1059 行是新函数，第 1056 行的条件是 `auth.Disabled || auth.Status == coreauth.StatusDisabled`，第 1057 行把 `data.Disabled` 写回真10

影响面要收窄。凡是 provider 由插件 auth-provider 能力接管的凭证，都会遇到这个问题。

走文件加载的 Claude、Codex OAuth 凭证不受影响，它们不经过这条刷新路径。

今天能做的自查只有一步。GET /v8/management/credentials 返回的每条记录都带 disabled、status、unavailable 三个字段。

在调一次 POST /v8/management/credentials/refresh 前后各读一次。停用的号如果从 disabled 变回 active，就是踩中了这个缺陷。

其他仓库与上游

OpenAI 状态页整体仍是 Partial System Degradation，影响级别 minor。File uploads 这一项停在 degraded_performance，窗口内没有恢复11。

这条与上一期是同一件事，写在这里只为提醒它还没好。涉及文件上传的批量任务，今晚排开一点。

OpenAI 开发者社区 Codex 分区窗口内多了一条新话题。发帖人自称用的是 Pro 500 档（每月 500 美元），新加坡时间 11 月 1 日 20:08 升级。

帖子里说升级后每周额度立刻重置，随后持续出现容量错误12。

单条自述，先当一个观察点。碰上同类报障的中转站，可以先核对客户端的套餐档位与升级时间。

Anthropic 侧全绿，组件状态都是 Operational，窗口内没有新事件13。

Google Cloud 的事故列表停在 10 月 28 日，窗口内没有新条目14。

Codex 重置追踪站这一小时没有新承诺，signal.active 为 false，最新一条官方帖停在窗口之前15。

sub2api、codex-proxy、codex2api 三个仓库窗口内的条目更新都是空的，没有新单也没有新合并16。

CLIProxyAPI 还有一张开放补丁 #7200，做的是按凭证剥离 web search 引用。窗口内只有时间戳变动，没有新提交，最后改动仍是 11 月 2 日 20:0717。

今天按这个顺序做

用 T3 Code 或类似自定义入口点的：今晚先别改配置，v8.0.52 读不到这个键。要止血就按凭证写 cloak_mode: never。
等 v8.0.53 或下一次发版：先在一台实例上加 native-entrypoints: ["t3-code"]，确认客户端的 UA 与 beta 头都齐，再推到其余实例。
开了 stabilize-device-profile 的：升级那一刻安排在看板前，指纹重建会带来一次集中抖动。
跑插件 auth-provider 的：升级后用 GET /v8/management/credentials 对比刷新前后的 disabled，把被误启用的号重新停掉。
所有人：File uploads 仍在降级，今晚的文件上传类任务错峰跑。

References

1
CLIProxyAPI 发行列表
github.com
2
issue 7224：T3 Code 入口点未被识别
github.com
3
提交 6d4102f3：支持 native-entrypoints 配置
github.com
4
dev 分支 config.example.yaml
github.com
5
dev 分支 config_normalization.go
github.com
6
v8.0.52 同名文件对照
github.com
7
v8.0.52 claude_executor_cloaking.go：确认后关闭隐身
github.com
8
v8.0.52 auth_provider.go
github.com
9
提交 04208efa：插件刷新保留停用状态
github.com
10
dev 分支 auth_provider.go
github.com
11
OpenAI 状态页
status.openai.com
12
社区帖子：Pro 500 升级后的持续容量错误
community.openai.com
13
Claude 状态页
status.claude.com
14
Google Cloud 状态页
status.cloud.google.com
15
codex-reset 追踪站
codex-reset.com
16
sub2api releases
github.com
17
PR 7200
github.com

窗口从北京时间 11 月 3 日 12:49 起算，到 13:24 收笔。四个仓库都没有发出新版本。

CLIProxyAPI 的开发分支比发行版 v8.0.52 多 11 笔提交。其中两笔带 Closes，都落在这一小时里。

一笔让自定义入口点可以写进配置，另一笔堵住插件刷新重新启用停用凭证的漏洞。两条修复都还在 dev，下面各给一条今天能执行的处置。

本期版位

仓库	最新版	发布时间（北京）	窗口内
CLIProxyAPI	v8.0.52	11 月 3 日凌晨	零发版，dev 多 11 笔
sub2api	0.2.19	10 月 28 日 18:16	零发版
codex-proxy	v2.1.22	11 月 3 日 07:35	零发版
codex2api	v3.1.2	10 月 28 日 04:40	零发版

发行版这一小时没动过，两笔修复要等下一版才拿得到1。

一、T3 Code 这类客户端，入口点能写进配置了

T3 Code 走的是 CLAUDE_CODE_ENTRYPOINT=t3-code。中转把它当外来客户端，于是照常做隐身改写。

修复是提交 6d4102f3，9 个文件 +261/−31，12:51 落到 dev3。

它新增的键写在 upstream.claude.header-defaults 下面：

upstream:
  claude:
    header-defaults:
      native-entrypoints: ["t3-code"]

dev 的示例配置把这一整块注释掉了，第 504 行起都是 # 开头。运维要自己取消注释，或者新建这个键4。

配置值进内存前会被规范化。normalizeClaudeEntrypointNames 做四件事：小写化、去首尾空格、丢掉空串、按原顺序去重。

全空时返回 nil，等于没配。这段逻辑在 dev 的 internal/config/config_normalization.go，由配置规范化阶段调用5。

判定侧的内置四项没有改动，仍是 cli、sdk-cli、sdk-ts、claude-vscode。新加的 isNativeClaudeEntrypoint 在这四项之外再读配置。

命中配置时，subclient 会合成成 claude-code-<entrypoint>，测试里断言 t3-code 得到 claude-code-t3-code。

这里有一条容易被忽略的前提。确认条件仍是「强信号且是 native 客户端」，两项都要成立。

提交里的测试专门断言了这一点：加上配置、但删掉 Anthropic-Beta 头，请求仍然判为未确认3。

强信号包括 X-App: cli、UA 里的 claude-cli/…(external, <entrypoint>) 段、claude-code beta 头，以及 metadata.user_id。count_tokens 那类请求单独放宽。

确认之后，线路策略会直接放行。resolveClaudeWirePolicy 在 confirmedClaudeCode 为真时把 policy.Cloak 置 false 并返回7。

发出去的 billing 头仍按入口点写，cc_entrypoint 保留真实值，方便上游侧对账。

副作用落在设备指纹上。claudeDeviceProfileSubclientScope 改用同一个判定函数，自定义入口点从 other 桶变成独立桶。

风险面要讲清楚。入口点是从 UA 文本里解析出来的，能自造 UA 的客户端同样能搭上这条直通路。

这条键在 v8.0.52 上写下去会被静默忽略。配置加载走的是 yaml.Unmarshal，没有开严格字段校验，拼错的键也不会报错。

今天的替代处置按凭证走。在 OAuth 凭证 JSON 里写 cloak_mode: never，或者给 API key 写 api-keys.claude[].keys[].cloak.mode。

全局的 upstream.claude.disable-claude-cloak-mode 先别动。它会把所有 Claude 请求一起关掉，包括你还没想清楚的那些客户端。

二、插件刷新会把已停用的凭证重新启用

报障人 Rick7C2 给的四步复现很干脆：

注册一个 RefreshAuth 只回 Provider、ID、Metadata 的 auth provider 插件；
用 PATCH /v8/management/credentials/status 把某张凭证停用；
调 POST /v8/management/credentials/refresh；
凭证回到 active 状态。

根因在刷新回填那一步。Host.RefreshAuth 会把 ID、Label、Metadata、StorageJSON、NextRefreshAfter 从旧记录带过来。

Disabled 不在回填名单里，它只取插件返回的 AuthData。Go 的 bool 没有「未设置」这个状态，插件返回一个最小结构体，就等于把停用标志写成了 false。

v8.0.52 的代码里可以直接看到缺口。auth_provider.go 第 1009–1010 行连着两个 preserve 函数，中间没有第三行。

提交 04208efa 补上了这一环，4 个文件 +174 行，13:00 落到 dev，Closes #72259。

新函数叫 preserveAuthDisabledState。旧记录里 Disabled 为真、或 Status 是 StatusDisabled，就把新数据里的 Disabled 置回真。

它在两处被调用：Host.RefreshAuth 里一次，执行器适配器的 Refresh 里一次。两条刷新路径都盖住了。

影响面要收窄。凡是 provider 由插件 auth-provider 能力接管的凭证，都会遇到这个问题。

走文件加载的 Claude、Codex OAuth 凭证不受影响，它们不经过这条刷新路径。

今天能做的自查只有一步。GET /v8/management/credentials 返回的每条记录都带 disabled、status、unavailable 三个字段。

在调一次 POST /v8/management/credentials/refresh 前后各读一次。停用的号如果从 disabled 变回 active，就是踩中了这个缺陷。

其他仓库与上游

OpenAI 状态页整体仍是 Partial System Degradation，影响级别 minor。File uploads 这一项停在 degraded_performance，窗口内没有恢复11。

这条与上一期是同一件事，写在这里只为提醒它还没好。涉及文件上传的批量任务，今晚排开一点。

OpenAI 开发者社区 Codex 分区窗口内多了一条新话题。发帖人自称用的是 Pro 500 档（每月 500 美元），新加坡时间 11 月 1 日 20:08 升级。

帖子里说升级后每周额度立刻重置，随后持续出现容量错误12。

单条自述，先当一个观察点。碰上同类报障的中转站，可以先核对客户端的套餐档位与升级时间。

Anthropic 侧全绿，组件状态都是 Operational，窗口内没有新事件13。

Google Cloud 的事故列表停在 10 月 28 日，窗口内没有新条目14。

Codex 重置追踪站这一小时没有新承诺，signal.active 为 false，最新一条官方帖停在窗口之前15。

sub2api、codex-proxy、codex2api 三个仓库窗口内的条目更新都是空的，没有新单也没有新合并16。

CLIProxyAPI 还有一张开放补丁 #7200，做的是按凭证剥离 web search 引用。窗口内只有时间戳变动，没有新提交，最后改动仍是 11 月 2 日 20:0717。

今天按这个顺序做

用 T3 Code 或类似自定义入口点的：今晚先别改配置，v8.0.52 读不到这个键。要止血就按凭证写 cloak_mode: never。
等 v8.0.53 或下一次发版：先在一台实例上加 native-entrypoints: ["t3-code"]，确认客户端的 UA 与 beta 头都齐，再推到其余实例。
开了 stabilize-device-profile 的：升级那一刻安排在看板前，指纹重建会带来一次集中抖动。
跑插件 auth-provider 的：升级后用 GET /v8/management/credentials 对比刷新前后的 disabled，把被误启用的号重新停掉。
所有人：File uploads 仍在降级，今晚的文件上传类任务错峰跑。

References

1
CLIProxyAPI 发行列表
github.com
2
issue 7224：T3 Code 入口点未被识别
github.com
3
提交 6d4102f3：支持 native-entrypoints 配置
github.com
4
dev 分支 config.example.yaml
github.com
5
dev 分支 config_normalization.go
github.com
6
v8.0.52 同名文件对照
github.com
7
v8.0.52 claude_executor_cloaking.go：确认后关闭隐身
github.com
8
v8.0.52 auth_provider.go
github.com
9
提交 04208efa：插件刷新保留停用状态
github.com
10
dev 分支 auth_provider.go
github.com
11
OpenAI 状态页
status.openai.com
12
社区帖子：Pro 500 升级后的持续容量错误
community.openai.com
13
Claude 状态页
status.claude.com
14
Google Cloud 状态页
status.cloud.google.com
15
codex-reset 追踪站
codex-reset.com
16
sub2api releases
github.com
17
PR 7200
github.com

T3 Code 的入口点白名单进了 dev；插件刷新会把你停用的号重新启用

本期版位

一、T3 Code 这类客户端，入口点能写进配置了

二、插件刷新会把已停用的凭证重新启用

其他仓库与上游

今天按这个顺序做

References

Related content

T3 Code 的入口点白名单进了 dev；插件刷新会把你停用的号重新启用

本期版位

一、T3 Code 这类客户端，入口点能写进配置了

二、插件刷新会把已停用的凭证重新启用

其他仓库与上游

今天按这个顺序做

References

Related content