插件先试开一次再加载，T3 Code 仍不在入口名单：CLIProxyAPI 三笔未发版
窗口内四个仓库都没发新版，变动全在 CLIProxyAPI dev 分支：插件加载前多了一道进程外试开、回放缺底引用会被剥掉，而 T3 Code 仍卡在入口白名单外。
窗口内四个仓库都没有发行新版本：CLIProxyAPI 停在 v8.0.52，sub2api 是 0.2.19，codex-proxy 与 codex2api 一轮扫描下来零条目。变化全在 CLIProxyAPI 的 dev 分支上，三笔提交。
最该看的是插件那一笔。装了第三方预编译
.so 的实例，下个版本起会在 dlopen 之前先用子进程把副本试开一次，SIGILL 这类崩溃不会再连宿主一起带走。但 v8.0.52 上没有这道检查。对应报障 #7220 状态仍是 OPEN、只挂了 Fixed 标签，修复只在 dev。1
另有一笔在主线上是真修复、在行为上是真变化：跨会话回放时找不到搜索结果的引用会被剥掉。第三笔只改仓库内部规约，对使用者没有影响。
窗口从 11 月 3 日 11:47:30（上一期发稿）算起。其中 11:21 落地的引用剥离修复，切点在上一期发稿前不到半小时，上一期没写，这期补上——它比另两笔更早，但不是新的。
版本位置
| 仓库 | 当前版本 | 本期窗口内 | dev 与发版位置 |
|---|---|---|---|
| CLIProxyAPI | v8.0.52（北京 11-03 03:15） | 无新版本，dev 多 9 笔 | 发行版、主干、HEAD、v8.0.52 标签同为 6e6afab9，dev 到 54778bd3 |
| sub2api | 0.2.19 | 无新版本，只有 issue 与 PR | 窗口内主干未发版 |
| codex-proxy | v2.1.22 | 无新版本、无条目 | — |
| codex2api | v3.1.2 | 无新版本、无条目 | — |
一、插件会在加载前先被“试开”一次
先给结论：下一个版本起，宿主不再直接把你的
.so 递给 dlopen。它先按内容哈希做一份影子副本，再起一个子进程，让子进程去打开那份副本、跑完插件初始化与关闭，然后看子进程留下了什么。顺序写在
Open 里：先做影子副本，再跑预检，预检报错就删掉副本直接返回，不报错才走到真正的 dlopen。4
internal/pluginhost/loader_unix.go 第 172–194 行：shadowCopyPlugin 在第 173 行、预检 probePluginLibrary 在第 177 行、真正的 C.cliproxy_dlopen 直到第 184 行才出现；第 189 行起的注释说明从这里往后动态库映像不能再卸载。5两个环境变量负责交接：一个告诉子进程副本在哪，一个告诉它把状态写到哪个临时文件。子进程只在三个状态里留一个，父进程据此分三路。4
loaded 说明副本能正常加载，放行，并把这一份记进“已探过”表。dlopen_null 说明子进程自己也没拿到 handle，同样放行，让宿主按老路径 dlopen、报出真正的错误。started 最要紧：子进程在完成初始化之前就退了。父进程把 stderr 第一行接在错误后面，插件不加载，宿主进程继续。
loaded 时把插件记进已探过表，第 485 行 started 时拼出“完成初始化之前就退出”的说明；第 497 行写明只有状态为 started 且失败可复现时才写缓存。6缓存是有条件的：进程被 SIGILL、SIGSEGV、SIGBUS 这类信号带走，或 stderr 里出现 illegal instruction、segmentation、bus error、panic: 之类，才算可复现，下次同一个插件直接拒、不再重复炸一遍。
SIGILL 的报错原文是
preflight probe terminated by SIGILL: illegal instruction (possible CPU instruction set mismatch)。看到这句，问题在你的插件产物，不在中转配置。代价要说清楚：探针没有超时。这份文件里没有
CommandContext、没有 Timer、没有 Deadline 或 WaitDelay，一个在初始化里挂死的插件会让插件加载一直停在那里。另外每次首次加载多一次 fork 与 exec；插件重编译后副本哈希变了，会按新键重新探一遍，不会沿用上次的结论。
平台范围有限：这套只在 cgo 且 linux、darwin、freebsd 上生效。Windows 走
loader_windows.go，没有这道预检。第二件事是如果你不敢赌第三方产物，就把
plugins.enabled 留在 false。v8.0.52 的示例配置里它就是 false，改过的人自己确认一遍。7二、回放时没了底的引用会被剥掉
第二笔修的是回放。
web_search_tool_result 的内容来自本地缓存：同会话、同凭证、缓存没过期，能取回原文，引用就保留。取不回来的时候，v8.0.52 会把这些引用原样发给上游，上游一验签就报
messages.1.content.4.citations.0: Invalid encrypted_index in text block。dev 的处置是三步：先按会话键尝试恢复；恢复不到、而这一轮 assistant 消息里确实有一个空的搜索结果块，就把这一轮里所有文本块的 citations 过一遍，只剥
web_search_result_location 这一种。8
internal/runtime/executor/helps/claude_web_search_results.go 第 141–176 行：第 144 行按会话键取缓存，第 154 行标记这一轮存在空结果块，第 163 行才进入剥引用的循环；正文不动，引用剥空就整键删除。9提交说明里还有一半容易被忽略：缓存查询提前到了 Responses 转 Claude 的翻译之前。普通、流式、token 计数三个执行器都是先挂上下文再翻译。
测试把边界写死了：同会话能恢复就保留引用；换会话、没有会话标识、缓存关着、会话被淘汰、同会话换凭证 ID、同会话换 API key，六种情况一律剥。10
对读者的意义是：升级后引用会“静默消失”，那是预期，不是又坏了一次。依赖引用做溯源的客户端要改预期，把正文当唯一可信来源。
一句待跟：
PR #7200 还开着，它的做法是按凭证剥离引用，跟这笔提交的路子不同，谁先进发行版没有定论。11三、T3 Code 不在入口白名单里
这条是新的，而且没有任何修复。#7224 报的是：用 T3 Code 接入时，请求被当成“非 Claude Code 客户端”处理，上游收到的是伪装成 cli 的请求。12
机制在两张识别表上。子客户端映射有二十五项：cli、mcp、bench、sdk-cli、sdk-ts、sdk-py、claude-vscode、remote、claude-desktop……里面没有
t3-code。原生入口表只有四项：cli、sdk-cli、sdk-ts、claude-vscode。判定要求两张表同时成立，所以
t3-code 永远进不了 Confirmed。
internal/runtime/executor/helps/claude_client_detection.go 第 35–72 行：第 35 行起的映射表二十五个入口点里没有 t3-code，第 66 行起的原生入口只有四项；第 63–65 行注释写明其余“第一方外观”的入口点要先抓到请求形状并评审才放行。13所以这不是漏了一行，而是一条写明的政策：只有已验证过线上行为的入口点才允许透传，其余第一方外观的入口点在抓到并评审请求形状之前一律 cloaked。T3 Code 属于后者。
这个文件在 v8.0.52 与 dev 上逐字节相同，开放 PR 列表里也没有针对它的补丁。今天没有版本可以升来解决它。
两条处置，按代价排。第一条：给这类客户端单独一条 Claude 凭证，在凭证 JSON 里写
cloak_mode: never，只影响这一条凭证。14不要为此去改全局的
upstream.claude.disable-claude-cloak-mode。那是所有 Claude 凭证共享的默认，一关就是把你手上真正在跑 Claude Code 的那几条也一起改了。15第二条：提 issue 或补一份可复现的请求形状，等它被收录进白名单。这条路慢，但它是唯一能让标签变准的路。
报障人自己用的绕法是把
CLAUDE_CODE_ENTRYPOINT 设成 sdk-ts 再 exec。不建议当长期方案：那是给上游一个不准确的标签，只把问题挪了个位置，换个客户端还得再改一次。也别把“cloaking 影响不大”当结论。报障人引的第三方小样本只测了 token 用量与缓存命中，长会话、压缩、子代理都没测。
其他仓库与上游
sub2api 的
#8492 说“账号里设了指定模型、分组也开了白名单，下游仍能完整透传上游模型名”。这条没有复现、没有版本号，不能当结论，但排查顺序可以定下来。16第一道闸是分组白名单中间件。未绑定分组或白名单没开，它直接放行、连请求体都不读；Responses WebSocket 入口它是跳过的，那一入口逐帧校验。17
命中拒绝时它回的是 404，并在运维里标
model_not_allowed。所以看到 200，就说明这道闸没开、或者没走到。第二道闸是账号级模型限制。账号开了透传时，在模型映射判定之前就放行，注释写明“只替换认证、模型语义交给上游”。18
两者不是同一道闸。查的时候先看 key 绑的是哪个分组、白名单开关是否真开，再看账号是不是透传——顺序反了会一直在错的那一层打转。
另有 PR
#8491（一键重置一个账号下所有限额 Key 的已用额度）开着，未合。19CLIProxyAPI 12:00 的
54778bd3 只改 AGENTS.md，是一条仓库内规约：JSON 与 Base64 一律走 moego 的库，JSON 写操作在 *ojson.Doc 上做、最后只序列化一次。对使用者没有影响。20上游这边：OpenAI 的
File uploads 仍是 degraded，就是上一期报过的那条事故，窗口内仍未 resolved。24重置追踪站窗口内没有新承诺：最近一条帖落在窗口之外，那条旧信号已经标成不活跃。27
社区这边也扫了一遍：OpenAI 开发者社区 Codex 分区窗口内没有新话题，最新一条落在窗口之前；r/OpenAI 窗口内只有一条额度相关的提问，r/ClaudeAI 全是使用类帖子，没有封号或限额的新信号。282930
今天按这个顺序做
- 版本先确认：四个仓库都在本期版本上，今晚没有必须升的版本。
- 装了第三方插件的：今晚就按发布基线重编，或先把
plugins.enabled关掉。别指望 v8.0.52 替你兜住 SIGILL。 - 依赖 search 引用溯源的：升级前排一下期，引用跨会话会消失，正文才是唯一可信来源。
- 用 T3 Code 之类非白名单客户端接 Claude 的：单独一条凭证加
cloak_mode: never，不要全局关 cloaking。 - 配了模型白名单却仍看到上游模型名的：按分组白名单、透传短路两层顺序查，先看 key 的分组。
References
- 1Issue 7220 插件打崩宿主
github.com
- 2v8.0.52 到 dev 的差异
github.com
- 3CLIProxyAPI 发行列表
github.com
- 4提交 dde469d3 隔离预检
github.com
- 5loader_unix 的 Open 函数
github.com
- 6loader_unix 的预检结果处理
github.com
- 7示例配置的插件开关
github.com
- 8提交 9acf81d3 剥离引用
github.com
- 9claude_web_search_results 的剥离逻辑
github.com
- 10剥离逻辑的测试边界
github.com
- 11PR 7200 按凭证剥离
github.com
- 12Issue 7224 T3 Code 入口点
github.com
- 13客户端识别表
github.com
- 14Claude 按凭证的 cloak 模式
github.com
- 15全局 cloaking 开关的说明
github.com
- 16sub2api Issue 8492
github.com
- 17分组模型白名单中间件
github.com
- 18账号模型的透传短路
github.com
- 19sub2api PR 8491
github.com
- 20提交 54778bd3 仓库规约
github.com
- 21v8.0.52 的 go.mod
github.com
- 22codex-proxy 发行列表
github.com
- 23codex2api 发行列表
github.com
- 24OpenAI 状态页事故
status.openai.com
- 25Anthropic 状态页
status.anthropic.com
- 26Google Cloud 事故列表
status.cloud.google.com
- 27codex-reset 信号
codex-reset.com
- 28OpenAI 开发者社区 Codex 分区
community.openai.com
- 29r OpenAI 最新帖
reddit.com
- 30r ClaudeAI 最新帖
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.