保存配置的那一秒，config.yaml 是 0 字节；两个读者正好在看它

北京时间今天 04:53，KennethWKZ 给两张躺了两周多的补丁各推了一笔提交；同一小时里第三张补丁的页面也被刷了一次。发行版这边一个字没动，v8.0.51 的 tag、main、dev 与远端 HEAD 全停在 7cad1cb71。

这三张补丁动的是同一处地方：把文件写进磁盘的那几行。今晚就能照着做的两件事在第五节和第七节。

管理端保存配置走 internal/api/handlers/management/config_basic.go 第 101 行的 WriteConfig。第 114 行打开文件时带了 O_WRONLY|O_CREATE|O_TRUNC，权限 0644，写完再 Sync 落盘2。

O_TRUNC 的语义是打开即清空。从 OpenFile 返回到 Write 完成之间，磁盘上那份 config.yaml 是 0 字节。

普通的编辑器保存走的是「写临时文件再 rename」，读的人要么看到旧版本、要么看到新版本。这里是原地覆盖，中间存在第三个状态。

第一个读者是配置监听器。internal/watcher/config_reload.go 第 59 行先 os.ReadFile 一次算内容哈希；第 84 行触发重载，第 99 行调 loadConfigFileFunc 再读一次3。

两次读之间就是那段空窗。第一次读到的是空文件，哈希是空的；第二次读到的若是写了一半的内容，解析就会失败。

发行版里已经有一道护栏：第 64–67 行判到 len(data)==0 直接返回，日志写 ignoring empty config file write event。这道判断落在第一次读，重载那次读没有对应检查。

第二个读者是远端镜像。internal/store/objectstore.go 第 27 行有个常量 objectStoreConfigKey = "config/config.yaml"，仓库里同一层还有 git 与 postgres 两份实现5。

三份实现都用同一个对象键，所以一个空的中途文件会以同一个名字推上去。

补丁作者列的后果比这更具体。他在 #6603 的说明里写：「镜像按它自己运行时看到的 config.yaml 状态推，空的中途文件让对象存储删掉远端配置，Postgres 与 git 存下它。」6

同一张表里还有一条：管理端 PUT 与密钥回写并发时，PUT 会丢。

以上是作者的自述，我核到的是「两次读之间存在空窗」这一步，后果清单按作者原话署名。

#6603 的说明正文是一张七行表，逐条列它要堵的竞态。表里第 1 条注明了「已由 dev 的 1631875b（#6631）修掉」，剩下六条它自己扛6。

规模是 21 个文件、+2112/−70、32 笔提交；状态 open，mergeable 为 clean；页面上只有 chatgpt-codex-connector[bot] 的自动评审，没有维护者写过一句。

同一天夜里另外两张也是同一个作者、同一种状态：

三张都没有合。今晚 20:53:41Z 那两笔提交是 #6605 与 #6413，之后 21:11 与 21:27 两次页面更新也只动了元数据。

config.yaml 不是唯一被原地覆盖的文件。sdk/auth/filestore.go 第 139 行先读旧内容，jsonEqual 判定相同就 break；不同则 os.OpenFile(path, os.O_WRONLY|os.O_TRUNC, 0o600) 再写7。

写入端有 0600，但 O_TRUNC 的语义没变：打开即清空。凭证文件比配置文件更小，空窗更短，形状一样。

读这一侧的处理分两层。internal/watcher/synthesizer/file.go 第 64 行遇 !json.Valid(data) 就 RecordIncompleteFile 并跳过；第 88 行对 len(data)==0 直接返回空8。

所以解析失败的文件会被跳过，策略是等一下次事件。

今晚 #6605 那笔改的是另一处：替换已存在的文件时，临时文件从调用者的权限改成 0600，写完再套回原来的 mode。作者的测试 TestWriteFileTempIsOwnerOnlyWhileHoldingNewContent 在改前是失败的，因为那一刻临时文件是 -rw-r--r--，里面已经是新 token9。

这条不用等合并。现在就可以进门看看 auth 目录里的 *.json 是什么权限，0644 的一个个改成 600。

sdk/cliproxy/auth/conductor_cooldown.go 第 1119 行是 case 429:，第 1129 行用 if !disableCooling { 把整段冷却计算包住。开关为真时，这一支不写任何恢复时刻10。

第 1261–1264 行还有一段收尾：disableCooling 为真、且 NextRetryAfter 与 Quota.NextRecoverAt 都为零时，把 Unavailable 与 Quota.Exceeded 一起清掉。

结果就是那张凭证下一轮照样可选中。而重试轮次只按配额算：conductor_selection.go 第 1163–1181 行的 requestRetryRoundExclusions 用 effectiveRequestRetryLimit 判，request-retry: 3 时同一张凭证能进 1 到 3 轮11。

一次客户端请求，最多 4 次上游发送，落在同一张刚被 429 的凭证上。

作者在 #6413 的正文里给了一个现场：routing.cooldown.disable-cooling: true 加 request-retry: 3，被 429 的凭证立刻重发 4 次；经一个自身对 429 退避的上游代理，约 4 × 61 秒，一次失败请求要烧掉 4 分钟左右12。

今晚那笔提交让「在 reset 记录之后发出」的 429 可以覆盖更早、更长的那个 reset，判据是 ExecutionSeq 水位；乱序回来的老调用只能把冷却时间往长里延。

这张补丁的机制在 v8.0.51 整包里搜不到：coolingDisabledRetry 零命中。

一、确认开关状态。 看 routing.cooldown.disable-cooling，config.example.yaml 第 227 行的默认值是 false13。单个凭证也能覆盖它，别忘了翻 auth 文件。

二、开着就降重试。 同一段的 request-retry 默认 3（第 211 行），把它改到 1 或 0，一次请求对上游的发送次数立刻从 4 降到 2 或 1。

三、保存配置改成串行并核对。 改完 curl 一次管理接口把配置读回来，确认为非空；同时看一眼远端镜像最近一次提交是什么内容。

四、收紧凭证权限。 chmod 600 覆盖 auth 目录下的每个 *.json，等 #6605 合并后再交给代码。

四个仓库这段时间没有新版本。CLIProxyAPI 停在 v8.0.51（tag、main、dev、HEAD 同一个提交）；sub2api 的 main 停在 10 月 30 日上午 10:44（北京）；codex-proxy 的 dev 停在今天凌晨 03:14，也就是上期写过的 #881；codex2api 停在 10 月 27 日。

上游三条状态页全绿，Google Cloud 最新一条事故仍停在 10 月 20 日。Codex 重置这边今天 UTC 没有落地，最近一次已验证的全局重置是 10 月 28 日 14:35（北京），累计 61 次全局重置、10 次存着未用。

还开着的是三张补丁，加上上期提过的 #7182（凭证文件权限，零评论）与 #6680（老 PR 的形态变化）。