main 多了一个能改余额的管理口：MCP 默认关着，249 迁移照样随主干走
sub2api 主干新增远程管理 MCP（默认关、249 迁移随 main 走），CLIProxyAPI dev 修好冷却状态写错一层目录，Muse Code 间歇 403 的指纹补丁仍未合并。
北京 10-30 08:42 到 11:07 这两个半小时，四个仓库一个新版本都没有。
主干上各多了一点东西：sub2api 的 main 开了个远程管理接口面，CLIProxyAPI 的 dev 多改了一行路径判断，另有一张改 Meta 指纹的补丁刚开在别人的分支上。
三件事都还没进发行版，今晚能做的都落在配置与自查上。
main 上多了一个能改余额的管理口
sub2api 的 PR #8389 在 09:49 合进 main，78 个文件、+7250 行，合并提交
7386bc6a1。它开的是远程管理 MCP：客户端填一个地址，浏览器登录并同意授权，之后用短效 access token 调工具2。
平台不签发静态 MCP token，也不接受面板 API Key 或浏览器 JWT 当凭证2。
跑 v0.2.19 的人今天不用管这件事。
默认是关的，判定只有一行
MCP_PUBLIC_URL 非空才算启用，配置文件里对应的键是 mcp.public_url。为空时，资源端点、OAuth 发现与注册接口一律返回 503，后台侧栏也不出现 MCP 接入这一项5。
地址还卡死在站点根的
/api/v1/mcp。带尾斜杠、挂在
/sub2api/ 这类子路径下、带查询串或片段，都会被启动时的校验直接拒掉5。
MCPConfig.Enabled() 就是「地址非空」，Validate() 把路径锁在 /api/v1/mcp；两者合起来，未配置时整条链路停用。5从 main 构建，249 会跟着跑
所以哪怕没打算开 MCP，只要镜像从 main 构建，迁移照样会跑。
老版本回滚照旧能跑，多出来的表旧代码不读。
麻烦落在备份和迁移审计上：表清单从此和 v0.2.19 的预期对不上。
想开的话，先备好三件事
- 地址：站点根
/api/v1/mcp，生产用 HTTPS；本机开发允许回环地址的 HTTP。 - 反向代理：转发
/api/v1/mcp、/api/v1/mcp/oauth/*和/.well-known/oauth-*，保留 Authorization、Accept 与 MCP 协议头2。 - 前后端分域：另配前端 URL（管理设置或
SERVER_FRONTEND_URL），浏览器授权页靠它定位2。
权限面：默认只读，写权限要过两道
默认同意的是个人范围、只读。
管理员范围要求授权人本人是管理员；管理员读写无论全局二次验证开关是否开启，都强制一次 TOTP 验证7。
拿到管理员读写的客户端能删 API Key、调用户余额、停上游账户调度、撤销订阅，这些都在工具目录里2。
EnforceStepUpAlways，与全局二次验证开关无关。7令牌侧：授权码 5 分钟且只能兑换一次，access token 最长 10 分钟。
授权本身最长 30 天，refresh 每次使用都轮换，复用已消费的 refresh 会撤销整条授权；每用户最多 20 个有效授权8。
限流按网络算：传输层每分钟 600 次（IPv6 按 /64 当一个客户端），注册每分钟 10 次，token 与 revoke 各 60 次。
这些限制全部 fail-closed，Redis 不可用时直接拒9。
撤销入口在后台侧栏的 MCP 接入页；「撤销全部会话」会连带撤销该用户的全部 MCP 授权，停用用户或取消管理员角色则持久撤销对应授权。
一个判断，标为推断：它值得被当成第二个管理入口。
面板现在怎么暴露，这个口就怎么暴露；它多一层浏览器授权，少一层「只有内网能进」的默认保护。
冷却文件写错一层目录：dev 已修，v8.0.47 还在写 auths/auths/
CLIProxyAPI 的 PR #7109 在 10:14 合进 dev，2 文件 +20/−1，dev 头变成
67beb7a610。tag、main 与 v8.0.47 都还停在
90c447d3，今晚拉发行版拿不到这笔11。触发要两个条件同时成立：
save-cooldown-status: true，且 auth-dir 写的是相对路径。./auths 这种 bind mount 的 Docker 部署正好落在这里10。错在
stateRelativePath：v8.0.47 只在 auth 文件是绝对路径时才剥掉 auth-dir 前缀。先看清影响面：冷却恢复仍然有效。
Load 递归遍历整个目录、按 auth ID 匹配记录，嵌套一层照样读得到12。坏的是布局。
备份脚本按
<name>.cds 平级找会漏；清理规则按目录删会连冷却一起删掉；排查时也容易误判成「冷却没落盘」。
filepath.IsAbs(authFile) 是这处 bug 的全部原因；补丁把它删掉，改成对相对路径也用 filepath.Rel 剥前缀。12升到带修复的版本后，下次
Save 会把文件写回平级，并把嵌套那份当陈旧文件删掉。今晚能做的两件事：
ls auths/auths/，看有没有这一层目录。- 确认
save-cooldown-status到底开没开——它默认 false，冷却只留内存，重启即清13。
Muse Code 订阅 key 间歇 403：dev 还印着 1.3.0 的指纹
10:50 开的 PR #7113 记了一条现场：拿 Muse Code 订阅 key 打 Meta 的接口，会收到 403
client_attestation_denied14。上游正文是「This API key is billed to a Muse Code subscription. Muse Code subscriptions cover requests from the Muse Code client only.」14
tbh:tui 换成 tbh:exec。15补丁换成 1.4.14 的写法：
muse-build/1.4.14 (non-interactive; <os>-<arch>; build dec7d74…)、X-Client-Id: tbh:exec。另加一组
X-Tbh-* 会话头，每请求一个新 UUID-7，避免不同客户端共用同一个 Muse 会话14。有一条限定得一起读：作者自己写，旧 1.3.0 指纹后来重试也返回 200。
也就是说这个 403 是间歇的，单次撞上说明不了版本身份的问题14。
PR 还没合，3 文件 +79/−16，
mergeable_state 是 clean14。在你自己的部署上，这件事现在的形态是：Meta 通道偶尔 403，重试可能就过去。
等它合并、随版本发布，再谈升级。
同一窗口里还有两笔依赖升级
main 上另有两笔和安全公告相关的提交，都落在这个窗口内。
09:36 的
fb22c92126b4 把 MCP 的 Go SDK 升到 v1.4.1，修 GO-2026-4773（跨站工具执行）与 GO-2026-4770（null Unicode 的 JSON 解析）16。它同时让 SDK 的跨源检查放行平台自己的 CORS 白名单，并接受带 charset 的
application/json。10:44 的
d851a384 把前端 vue-i18n 升到 11，并给 decode-uri-component 打补丁。对应两个 high 公告：GHSA-83rm-6c8r-g728 的 srcdoc XSS，与 GHSA-qr28-fpjm-wq7f 的二次方 DoS17。
vue-i18n 11 要求 Node ≥22，CI 与构建镜像一并从 20 挪到 24。
两条协议保真报障，都配了修复 PR
09:50 开出两张单，09:51 就各有一张对应的修复 PR，作者都是 lkon2112，两张 PR 都还是 open、
mergeable_state 为 unstable。第一条是 #8427：Responses 转换里同一段
output_text 出现两种结构。response.content_part.done 带 annotations 与 logprobs；response.output_item.done、response.completed 和非流式响应里缺这两个字段。第二条是 #8428：Gemini 工具返回图片时，图片作为顶层
inlineData 附在函数响应旁边。多个工具并行返回图片，结构里就看不出哪张图属于哪个工具结果21。
它建议改用 Gemini 3 起支持的
functionResponse.parts，旧模型保持现状；修复 PR #8430 12 文件 +260/−4222。两张单都还 open，所以 v0.2.19 的行为就是上面写的这样。
版本与上游
| 仓库 | 当前版本 | 本窗口 |
|---|---|---|
| CLIProxyAPI | v8.0.47 | 无新版本 23 |
| sub2api | 0.2.19 | 无新版本 24 |
| codex-proxy | v2.1.21 | 无新版本 25 |
| codex2api | v3.1.2 | 无新版本 26 |
下游这三家这两个半小时安静：codex-proxy 与 codex2api 的条目列表窗口内没有更新。
sub2api 的变动就是上面那几项：一条合并、两笔依赖升级、两张报障与它们的修复 PR。
上游三家也干净。
OpenAI 全绿，没有降级组件27。
Anthropic 最近一条仍是 10-28 的 Google Calendar 连接器事件28。
Google Cloud 的事故列表没有新增，最新一条改动还是 10-28 08:38（北京）29。
Codex 侧今日 UTC 仍未重置。
最近一次已验证的全局重置停在 10-28 14:35（北京），累计 61 次、10 次未用30。
References
- 1
- 2docs/mcp.md
github.com
- 3Sub2API 0.2.19
github.com
- 4249_mcp_oauth.sql
github.com
- 5config.go 第 122–150 行
github.com
- 6repository/ent.go
github.com
- 7mcp_oauth_handler.go 第 203–240 行
github.com
- 8mcp_oauth_service.go 常量
github.com
- 9routes/mcp.go
github.com
- 10
- 11CLIProxyAPI v8.0.47
github.com
- 12cooldown_state.go 第 283–300 行
github.com
- 13config.example.yaml 第 224–234 行
github.com
- 14
- 15meta_executor.go 第 27 行与第 55–56 行
github.com
- 16fix(backend): bump MCP go-sdk to v1.4.1
github.com
- 17fix(frontend): upgrade vue-i18n to v11
github.com
- 18issue 8427
github.com
- 19responses_stream_event_wire.go v0.2.19
github.com
- 20PR 8429
github.com
- 21issue 8428
github.com
- 22PR 8430
github.com
- 23CLIProxyAPI releases
github.com
- 24sub2api releases
github.com
- 25codex-proxy releases
github.com
- 26codex2api releases
github.com
- 27OpenAI Status
status.openai.com
- 28Claude Status
status.claude.com
- 29Google Cloud Status
status.cloud.google.com
- 30Codex Reset 追踪
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.