10/14 22 点续报：注册审核还没合并，Antigravity 的两次同步写盘只在 dev
补报 10 月 14 日 21:48 之后的四十分钟：sub2api 的注册审核流还没合并，codex-proxy 的 Antigravity 面板计数合进了 dev 并带出一条只在 dev 上的同步写盘报称，CLIProxyAPI 的并发写修复多了一轮第三方复核。
上一期通报停在 10 月 14 日 21:48（北京）。这一期补它之后的四十分钟，窗口到 22:26，正文里的时间都换算成北京时间。
新增的是四件事：sub2api 的一条注册审核 PR；codex-proxy 的一条写盘 issue 和一次合并；CLIProxyAPI 那边补上来的一轮第三方复核。
现在就做
- 注册审核先别接进生产。 它给的迁移、开关与登录错误码都还只在一张未合并的分支上，控制台里也还没有这个开关。6
- 要用 Antigravity 的账号面板，等下个含 dev 的构建。 面板计数已经合进
dev，稳定版和最新预发布都还没有；在这之前，账号在不在看api-keys.json里的记录。37 - 跑 dev 构建的，把写盘盯一下。 Antigravity 的请求热路径上会多出两次同步写，稳定版和最新预发布里都没有这两处。8910
- CLIProxyAPI 的并发写修复继续等。 第三方已经独立复现了它修的两处时序，但它到发稿仍未合并，停机与账号核对按现版本做。1112
上游：这一窗口没有新的额度或封号信号
Anthropic 的状态页在窗口内 0 条事件，各组件显示正常。15
Google Cloud 的事件源同期也是 0 条，最近一条仍是 10 月 8 日的 Cloud Storage 延迟。16
OpenAI 社区 Codex 分区在窗口内没有与额度或风控相关的新帖，新出现的是 Windows 客户端的本地浏览器任务报错。17
sub2api：注册可以先审后放，但这条还没合并
PR #8090 在 21:44 开出，22:12 还有更新，到发稿是打开、未合并。6 它给注册加了一道人工闸门：管理员在「设置 → 安全 → 注册」里打开「注册审核」之后，新用户要填一段申请理由，落进
pending 状态，管理员批准才能登录。6| 要照抄的东西 | 值 | 说明 |
|---|---|---|
| 设置项 | registration_review_enabled | 管理端安全页的开关，也出现在公开设置里给注册表单读；提交设置时省略该字段表示保持现值 619 |
| 迁移文件 | 246_user_registration_review.sql | 给 users 加一列 registration_reason TEXT NOT NULL DEFAULT '' 18 |
| 新用户状态 | pending | 注册后落在这个状态，管理员批准后转成 active 19 |
| 注册接口返回 | pending_review: true | 审核开着时不发 token，只回这个标记 6 |
| 登录错误码 | REGISTRATION_PENDING | 待审用户登录时返回；被禁用的账号仍是 USER_NOT_ACTIVE 6 |
行为上有三点要先知道。6 开关默认关着，现有部署的注册登录流程照旧。邮箱验证流程保留，申请理由暂存在
register_data 里，和验证码一起提交。额度、订阅与配额仍在注册那一刻发放，批准之后账号立刻可用。6管理端用户列表也跟着改了：多一个待审筛选、黄色徽标、悬停显示申请理由，以及一键批准或拒绝，审核结果写进审计日志。6
codex-proxy：Antigravity 的面板合进 dev，写盘的报称也只在 dev 上
原因是
AccountList 只看自己那份 Codex 号池：空状态按这份号池是否为空来显示，表头与筛选计数也来自它。7 修法是让列表接住 Antigravity 这份号池，把它算进表头和「全部」筛选的计数；有 Antigravity 账号时不再显示空状态，而 Codex 的状态筛选仍只管 Codex。7一小时后开出的 issue #871 说的是同一块功能带来的另一件事：Antigravity 的请求热路径会同步写盘。8
报告人读的是源码。8 路由选中 Antigravity 账号后调用
ApiKeyPool.markUsed()，这个方法更新计数后立即落盘；请求产生用量时 recordApiKeyUsage() 再调一次 recordUsage()，也立即落盘。默认的持久化实现用 writeFileSync() 写临时文件再改名，所以带用量的请求可能同步写两次。8报告人自己写明，他只核对了源码路径，运行时 I/O 与延迟基准还没有做，量级因此未知。8
markUsed() 里，第 301 行在 recordUsage() 里，两处都是请求热路径上的那一次同步写入。在稳定版 v2.1.16 和最新预发布 v2.1.17-beta.1604624 上，
markUsed() 的末尾是一行注释 // Defer persist — lastUsedAt is non-critical，ApiKeyPool 上也没有 recordUsage()。910CLIProxyAPI：并发写修复多了一轮第三方复核
评论里有一轮第三方复核（19:28）。11 复核人用
-race -count=1，在干净的 v8.0.28 源码包上独立复现了两处时序：重载期间落下的配置保存被跳过，队列里的旧 auth 快照覆盖了新值。11他给出的最小配置序列是：设好 8080 端口，在重载回调里把端口改成 9090，再触发下一次重载；第二次的值被跳过，因为第一次重载确认的是它没有应用的字节。11 他同时说明，auth 那条复现用的是没有持久化 Store 的 manager，因此只覆盖这种没有 Store 的情形。11
止血与防再犯
止血
- 别用面板数字判断 Antigravity 账号在不在。 计数修复已经合进
dev，能跑起来的构建里还没有它。37 - 跑 dev 构建的，把
api-keys.json的写盘放进观察项。 带用量的请求在热路径上同步写两次，报告人还没有给出量级，先按现象看。8
防再犯
| 制度 | 说明 |
|---|---|
| 报称先对版本源码 | 社区报称先在本版本源码里搜一遍，再决定动不动；本期的写盘报称在稳定版与预发布上都对不到 8910 |
| 分支不同不混用结论 | dev 上的行为不代表已发布版本的行为，判断前先看这条改动落在哪个分支 2021 |
号池与定价
这一窗口没有新的价目表。
下一次通报等新的破坏性版本、明确的额度或封号信号，或者社区已验证的止血步骤。
References
- 1Sub2API v0.2.16 · Releases
github.com
- 2CLIProxyAPI v8.0.28 · Releases
github.com
- 3codex-proxy v2.1.16 · Releases
github.com
- 4
- 5codex2api v3.1.0 · Releases
github.com
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13Codex reset tracker
opentherank.com
- 14Codex Reset — Last Reset Tracker
codex-reset.com
- 15Claude Status
status.anthropic.com
- 16Google Cloud Service Health
status.cloud.google.com
- 17Latest Codex topics · OpenAI Developer Community
community.openai.com
- 18246_user_registration_review.sql
github.com
- 19
- 20
- 21
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.