10/15 凌晨续报：v8.0.29 连着写两个设置项会丢第二个，sub2api 的 SSE 恢复还没合并
补报 10 月 15 日 03:35 到 04:13（北京）这 38 分钟：CLIProxyAPI v8.0.29 上管理 API 连着写两个设置项会丢掉第二个、两次却都返回成功，sub2api 补 SSE 侧 encrypted reasoning 恢复的 PR 还没合并，另有一条 codex2api 在小机器上升级后内存抬高的单例报告。
这一期覆盖 10 月 15 日 03:35 到 04:13（北京）。
前一期刚写完 CLIProxyAPI v8.0.29 与 codex-proxy v2.1.17 两个稳定版落版，这 38 分钟里四个仓库都没有再出新版本。
新出现的是 v8.0.29 上的一条报障：管理 API 连着写两个设置项，第二个会被悄悄丢掉，两次请求却都返回成功。
现在就做
- 用管理 API 或面板脚本改配置的实例，一次只发一个写请求，写完读回确认。 在 v8.0.29 上连着发两个写请求，第二个可能没进内存，还会被下一次写入把旧值带回
config.yaml，200 {"status":"ok"}不能当作已经生效。1 - sub2api 上撞到流式响应里的
invalid_encrypted_content，眼下没有版本可升。 补这条恢复路径的 PR #8095 到发稿还开着；现在能做的，是把这一轮重发一次，或者先删掉请求里那段 encrypted reasoning 条目再发。2 - 跑在 Pi 这类小机器上的 codex2api，升到 v3.0.9 之后留意内存水位。 有一条单例报告说升级后空闲内存从约 90 MB 涨到 180 MB 上下，单次查询峰值约 300 MB；这条到发稿还没有第三方复现。3
CLIProxyAPI：v8.0.29 上连着写两个设置项，第二个会丢
两个写入请求一个接一个发出，后一个等前一个返回才发，两次都拿到
200 {"status":"ok"}，但第二个值没有留在内存里。下一次写入把内存里的旧值落盘，
config.yaml 里那次改动跟着一起没了。1报告人是在 Docker 镜像
eceasy/cli-proxy-api:v8.0.29（commit 5fc580b）上撞到的，配置用单文件挂载的 legacy 布局 config.yaml，设了 MANAGEMENT_PASSWORD。两个全新容器都复现。1三条顺序发出的请求，等 4 秒后读回的结果是这样：
| 顺序 | 请求 | 返回 | config.yaml 落盘 | GET /v0/management/config |
|---|---|---|---|---|
| 1 | PUT /v0/management/debug {"value": true} | 200 | true | true |
| 2 | PUT /v0/management/request-retry {"value": 5}（原值 3） | 200 | 3 | 3 |
| 3 | PUT /v0/management/max-retry-credentials {"value": 7}（原值 0） | 200 | 7 | 7 |
为什么写进去了还会退回来
报告人读源码给出的路径是：
persistLocked 落盘后取一份带代数号的快照，再异步触发重载；代数检查跑在重载钩子之前，而钩子把快照丢掉、改去调 reloadConfigFromWatcher()，从磁盘重读 config.yaml。这条重载最后走到
s.mgmt.SetConfig(cfg)，用刚从磁盘读到的内容替换处理器内存里的配置，那一步没有代数检查。1本刊在 v8.0.29 标签的源码里核到了这条路径的前半段。
persistLocked 先保存配置、再取快照、再回 200，然后把重载丢给异步函数；4 而重载钩子注册成 api.WithConfigReloadHook(func(_ context.Context, _ *config.Config) { service.reloadConfigFromWatcher() })，参数位上的那份快照确实没有用。5
画面取自 v8.0.29 标签下
sdk/cliproxy/builder.go 第 301 至 303 行，逐字为 api.WithConfigReloadHook(func(_ context.Context, _ *config.Config) {、service.reloadConfigFromWatcher()。5绕行办法
报告人自己是在写面板时撞上的，最后的做法是每次保存只发一个
PUT /config.yaml，不再连着发多个字段写入。1这条报障到发稿没有关联的 PR 或分支，也没有人回复。1 它和本刊跟了几期的 #6603（并发保存会留下陈旧的 config 与 auth）、#6605（auth 文件原子写）属于同一类问题，那两张 PR 到现在仍然开着。67
sub2api：SSE 侧的 invalid_encrypted_content 还没有恢复路径
OpenAI Responses 的流式请求可以返回 HTTP 200，然后在 SSE 里下发
response.failed 或 error 事件，事件里带着 invalid_encrypted_content。sub2api 既有的加密推理恢复逻辑只认 HTTP 400，这类响应从旁边绕了过去，清理步骤没有执行。2PR #8095 补的就是这一段：在语义输出提交之前识别严格的
invalid_encrypted_content 失败，只删掉由上游绑定的 encrypted reasoning 与 compaction 条目，然后在同一账号上重试一次。重试预算与既有的 HTTP 400 路径共用；恢复次数用尽时保留原来的终态事件，不去换号。2
识别条件是两层：事件的
code 等于 invalid_encrypted_content，或者是 thinking_signature_invalid 并且消息里同时出现 The encrypted content、could not be verified、could not be decrypted or parsed。请求里还要真的出现过带
encrypted_content 的 reasoning 或 compaction 条目，否则不触发。2这张 PR 是 10 月 15 日 04:07（北京）开的，非草稿，6 个文件 +397/−27，1 个提交，到发稿是 open、未合并，GitHub 给的可合并状态是
unstable。2 sub2api 的稳定版仍是 10 月 13 日的 v0.2.16，这条修复还没进版本。8codex2api：Pi zero w 升到 v3.0.9 后内存与 CPU 抬升（单例报告）
报告人从 v3.0.8 升到 v3.0.9，跑在 Pi zero w 上，SQLite 加 Memory 部署。空闲时内存约 180 MB，一次查询冲到 250 MB、峰值约 300 MB。
重启后服务启动完成时是 60 至 70 MB，一刷新上游账号状态就跳到 180 MB 以上，第一次查询后停在 190 MB，CPU 在 92% 上下持续约 20 秒。同一套环境在 v3.0.7 上整包只占约 90 MB。3
证据是报告人自己贴的
journalctl 日志与内存读数。他把严重程度填成「严重 — 影响主要功能，但有 workaround」，到发稿没有维护者回复。3要留意版本差：报告人用的是 v3.0.9，而 codex2api 现在的最新版是 10 月 12 日的 v3.1.0，这两版之间有没有变化还没有人对照过。9
版本与上游：这一窗口没有新事件
四个仓库都没有新版本：CLIProxyAPI 停在 v8.0.29、codex-proxy 停在 v2.1.17、sub2api 停在 v0.2.16、codex2api 停在 v3.1.0。1011
References
- 1
- 2
- 3
- 4
- 5sdk/cliproxy/builder.go at v8.0.29
github.com
- 6
- 7
- 8Sub2API v0.2.16 · Releases
github.com
- 9codex2api v3.1.0 · Releases
github.com
- 10CLIProxyAPI v8.0.29 · Releases
github.com
- 11codex-proxy v2.1.17 · Releases
github.com
- 12Claude Status
status.anthropic.com
- 13Google Cloud Service Health
status.cloud.google.com
- 14Codex reset tracker
opentherank.com
- 15Codex Reset — Last Reset Tracker
codex-reset.com
- 16第 006 期 · 2026-10-14 · linux.do 晚报
linuxdo.club
- 17Codex · OpenAI Developer Community
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.