10/20 清晨速报：codex-proxy v2.1.19 只补了离线包，插件版本带 -v 会被认成别的插件
codex-proxy 的 v2.1.19 只把离线包挂回发行页、源码与上一版逐文件相同；CLIProxyAPI 新报的插件身份解析会把带 -v 的版本号切错，装上却选不中。
这一期从上一期发稿的 03:30 到现在，两个小时出头。
四仓里只有一个动了版本：codex-proxy 在 04:58 发出 v2.1.19。sub2api、CLIProxyAPI、codex2api 都没有新版本，两个主干也没有新提交。
值得先看三件：
- v2.1.19 的源码与 v2.1.18 逐文件相同，唯一的实际变化是离线包终于由流水线挂上了发行页。
- CLIProxyAPI 新开一张单：插件版本号里带
-v时，装完会被认成另一个插件，配置里按原名引用就选不中。 - 一张在途单在修 SOCKS 拨号不吃取消，代理卡在协商阶段时拨号不会返回。
今晚没有必须升的版本。要动手的只有一件：翻一下你那台实例的插件版本号，看有没有
-v。v2.1.19 发了，源码与 v2.1.18 相同
版本在 04:57:34 建出、04:58:14 发出。1
相对 v2.1.18 是 4 个提交、4 个文件：发布工作流、CHANGELOG、
package.json 与 lock 文件。2源码一行没改。这条先记住，它决定下面几段怎么读。
发行说明的「本次更新」列了八条，从本地回环地址绕开系统代理、到流式失败不再回 200。这些行为在 v2.1.18 的包体里就已经是那样，升级到 v2.1.19 不会让它们第一次生效。
这一版真正改的是发布流水线。挂离线包的步骤原来要求事件是
push 且 ref 是 tag；稳定版走的是 workflow_dispatch --ref <tag>，条件永远不成立，步骤被静默跳过。
npm-publish.yml 第 365–388 行，v2.1.19：触发条件从「事件是 push 且 ref 是 tag」改成只看 ref。if: startsWith(github.ref, 'refs/tags/') 是这一版唯一的功能性改动，注释里写明了原因。3它确实生效了：v2.1.19 的
codex-proxy-npm.zip 附件创建于 05:05:58，离发行 7 分 44 秒。4README 里那个固定链接现在能下：请求
/releases/latest/download/codex-proxy-npm.zip 会跳到 v2.1.19 的这个附件。5补一段历史，仓库自己的变更日志也写了：v2.1.16、v2.1.17、v2.1.18 的离线包都是 10 月 19 日 08:42 到 08:44 才补传的，比各自的发行晚了三到六天；v2.1.15 至今没有。6
所以「离线包下不到」不是猜测，是发生过、被手工补齐过的。这一次是流水线第一次自己挂上。
预发布通道仍然没有：v2.1.19-beta.f824033 的 15 个附件里不含它。用 beta 的人拿不到这条免认证安装路径。
还有一个容易误判的点。v2.1.19 这个 tag 里的
package.json 写的是 2.1.18；往前两个 tag 也一样，v2.1.18 里写 2.1.17，v2.1.17 里写 2.1.16。7原因是版本号同步的提交在 tag 之后才落到 dev：04:57:41 那笔
chore(version): sync package.json version to 2.1.19 就是它。8离线包里装的是九个发布包与一个
install.mjs，安装时不需要连 npm 仓库。内网、离线机、以及被 GitHub Packages 的私有默认卡住的场景，走的都是它。值班动作：功能上没有升的理由，跑着 v2.1.18 的实例不用排升级。
只有依赖离线包的环境值得换，或者直接下 zip 跑
install.mjs。插件版本号里带 -v，装上了但不会被认出来
05:03 开出的 #6787，作者 BichengWang，目前 open、0 评论。9
现象是这样的：安装
alpha 的 1.0.0-preview-v2，安装成功；发现侧报回来的是 ID alpha-v1.0.0-preview、版本 2。报障人给了三组对照。
1.0.0-preview 正常；1.0.0-preview-vnext 得到空版本；上面那个 -v2 被切成两半。根因是文件名解析。安装侧把落盘名拼成
<id>-v<version>.so，发现侧拿同一个名字找最后一个 -v 当分隔符。切错也不会报错。切出来的
alpha-v1.0.0-preview 本身是合法 ID，切出来的 2 也是合法版本，两道校验都放行。
internal/pluginhost/platform.go 第 78–93 行，v8.0.35：切分点之后两道校验都会放行切歪的结果。后果落在选文件那一步：按 ID 分组之后，配置里写了版本的，版本对不上就
continue，直接不选。11ID 都变了，配置里按
alpha 引用自然找不到。表现就是「装完了，插件列表里没有」。同一套解析在三个文件里各写了一遍：插件宿主、插件仓库、Home 模式同步。修的时候三处要一起改，只改一处会让两条路径不一致。
报障人自己写了复现测试，也点了一句：改成取第一个
-v 也不行，alpha-v2 这种合法 ID 会被切坏。要修得换一个不含歧义的文件名格式。现在能做的只有规避：插件版本号里别带
-v。1.0.0-preview.2 这种写法切分点唯一，装完能被认回来。已经在跑的实例，两个地方对一眼就够。
插件面板走的是
GET /v8/management/plugins，列出来的就是发现侧的 ID 与版本。名字里多出一截 -v1.0.0-preview 的，就是被切歪的那一个。目录侧看
plugins/<goos>/<goarch>/，落盘名固定是 <id>-v<version> 加扩展名。两边对不上，配置里再怎么写也选不中。SOCKS 拨号不吃取消
10 月 15 日开出的 #6667，在 04:22 被作者 @ 维护者求评审，留言里说 CI 通过，仍未合并。13
现状写法在 v8.0.35 里是这样：
DialContext 收下上下文，然后丢掉，直接调 dialer.Dial。
sdk/proxyutil/proxy.go 第 130–142 行，v8.0.35：上下文被丢掉，拨号走的是不带取消的 Dial。上下文被丢弃之后，取消不会传到拨号上。14
后果要分两步看。SOCKS 代理接了 TCP 却在协商阶段卡住时，取消这个请求不会让拨号返回，代理连接也不释放。
于是那一路的 goroutine 与连接一直挂着，直到协商自己结束，或者 TCP 断掉。
修法是换成
proxy.ContextDialer 的 DialContext。x/net/proxy 的 SOCKS5 dialer 本来就实现了这个接口，一行类型断言就够。改的只是
socks5 与 socks5h 这一支。同一函数里 http 与 https 代理走的是另外两条分支，不受影响。顺带加了回归测试：本地起一个 SOCKS 服务，等客户端发出 greeting 后取消，断言拨号返回错误、连接被关闭，两个 scheme 各一遍。
覆盖面不止一条链路。这个传输被执行器的代理路径、插件侧的 HTTP 桥、以及拉取模型清单的命令共用。15
主干上也还是旧写法，
main 与 v8.0.35 在这一段逐字相同。16值班：这一条现在没有可升级的版本，只能等合并后发版。要判断自己有没有踩到，看 socks5 出口在协商阶段卡住时，进程里是否还留着没关的连接。
上游与额度
OpenAI 全绿，活动事件 0 条，组件没有降级，页面在 10 月 17 日 04:01 更新过一次。17
Anthropic 全绿，今天没有事件。18
Google Cloud 仍是 7 条，最近一条还是 10 月 8 日到 9 日的 Cloud Storage。19
Codex 今天 UTC 仍没有重置。最近一次已验证的全局重置在北京 10 月 18 日 04:41，距今约 49 小时，累计 55 次全局、10 次 banked。20
页面在同一时刻给的 24 小时概率是 45%、48 小时 70%；另一套把提示帖算进去的口径是 21% 与 37%。
opentherank 记的是 63 次、中位间隔 3.1 天、最长 68 天（2025-12-25 到 2026-03-03）。21
主干这一侧：CLIProxyAPI 的 main 与 dev 都停在 00:55，sub2api 的 main 停在 20:45，codex2api 停在 10 月 16 日，窗口内零新提交。
社区这一侧，Codex 分区窗口内有两条新话题：20:24 的 Windows 任务路由失败、21:24 的 CLI 选不了文本，都不是中转侧的额度或风控，未收。25
Reddit 侧，r/OpenAI 有一条 04:31 的自述帖，说 Pro 的周额度按 10 天而不是 7 天重置。单条、未验证，只当社区对照。26
r/ClaudeAI 窗口内是作品展示与闲聊，r/OpenAI 其余是订阅自述、计费截图与安全事件讨论，都按排除规则未收。
未收与待跟
窗口内 CLIProxyAPI 还有一条测试单 #6754 在 21:03 更新，只动 websockets keepalive 的测试，生产代码没变，未收。27
codex-proxy 的 beta 通道为什么不挂离线包，没人提。这一次修的是稳定版那条路，beta 仍是 15 个附件。
#6787 没有修复单，三处解析怎么统一也还没有方案。
#6667 在等评审。就算合了，也要等下一个 tag 才轮到发行版。
老规矩：上面所有 open 的东西，都要等下一个 tag。
References
- 1codex-proxy v2.1.19 发行页
github.com
- 2v2.1.18...v2.1.19 的提交与文件清单
github.com
- 3npm-publish.yml 第 365–388 行
github.com
- 4codex-proxy 近十二次发行的附件与时间
api.github.com
- 5离线包固定下载地址
github.com
- 6CHANGELOG 里这条修复的原话
github.com
- 7v2.1.19 tag 里的 package.json
github.com
- 8codex-proxy dev 分支最近提交
github.com
- 9CLIProxyAPI issue #6787
github.com
- 10platform.go 里的切分与校验
github.com
- 11版本对不上时被跳过的那一行
github.com
- 12versionedPluginFileName 的拼接方式
github.com
- 13CLIProxyAPI PR #6667
github.com
- 14v8.0.35 里 SOCKS5 的传输构建
github.com
- 15执行器侧调用同一个传输构建
github.com
- 16main 分支上的同一段
github.com
- 17status.openai.com
status.openai.com
- 18status.anthropic.com
status.anthropic.com
- 19status.cloud.google.com
status.cloud.google.com
- 20codex-reset.com
codex-reset.com
- 21opentherank Codex 重置追踪
opentherank.com
- 22sub2api Releases
github.com
- 23CLIProxyAPI Releases
github.com
- 24codex2api Releases
github.com
- 25community.openai.com Codex 分区
community.openai.com
- 26r/OpenAI 那条周额度自述
reddit.com
- 27PR #6754
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.