这个 codex-cli 补丁只改一个很具体的超时问题，但发布时还得说明版本、源码构建、备份安装和验证方式。
codex-cli-0.131.0-issue14860-fix 是一个很小的源码补丁包。公开仓库在这里：
https://github.com/GitLaughs/codex-cli-0.131.0-issue14860-fix它针对的是 Codex CLI 0.131.0 的一个具体问题：远程 compaction 相关的长请求容易超时。补丁思路也很集中：在默认 HTTP client 上设置 reqwest::ClientBuilder::tcp_user_timeout，同时为某些旧 Linux 环境保留最后链接阶段需要的兼容 shim。
我这里不写安装步骤，主要记录这次打包时踩到的发布说明问题：补丁到底适用于谁，不能让用户猜。
既不只是替换版，也不只是魔改发行版
README 里一开始就说明：这个仓库是 source-based patch package，不发布也不替换任何第三方二进制。
这句最好放在 README 开头，否则很容易被看成第三方发行版。
如果你把一个上游 CLI 改完重新打包，很容易让使用者误解为“这是另一个发行版”。不过这个项目的范围更窄：
- 使用官方
rust-v0.131.0源码 checkout。 - 应用一个针对具体文件的 patch。
- 保持 CLI 版本仍然显示为
codex-cli 0.131.0。 - 本地构建后再替换本机 vendor binary。
- 替换前创建备份。
也就是说，仓库提供的是一条能重复执行的修补流程，而不是另起一个 Codex 版本。读者看到这里，至少能先确认版本、问题和构建来源。
补丁越小，说明越要清楚
这个补丁的重点看起来只是一行网络参数，但 README 仍然列出了完整内容：
- patch 文件。
- CentOS 7 兼容 C shim。
- 构建脚本。
- 安装脚本。
- 构建说明。
- CI 验证 workflow。
- release workflow。
这很有必要。因为用户除了关心改了哪行，还会关心下面这些事：
- 这行代码应该打到哪里。
- 如何判断 patch 已经应用。
- 如何在旧系统上链接成功。
- 构建出来的 CLI 版本是否仍然正确。
- 替换现有 binary 前有没有备份。
- 这个包有没有被基本验证过。
这种小补丁更容易被低估，所以 README 里最好直接写清楚怎么验证，而不是只说“已修复”。
为什么没有改版本号
项目明确保留 codex-cli 0.131.0 的版本显示。
这比随便改成 0.131.0-fixed 更谨慎。它不是上游正式发布，也不是语义版本意义上的新版本，只是一个针对本地构建的补丁路径。
不改版本号可以避免脚本误判，也不会暗示这是上游新版本。但 README 必须把 patched binary 写明白，否则用户看到同一个版本号，会分不清自己跑的是原版还是补丁版。
所以补丁包最好同时做到：
- CLI 自身版本不乱改。
- 安装脚本做备份。
- README 说明验证方式。
- release notes 说明 patch 内容。
旧系统兼容不该藏在脚注里
README 里提到 CentOS 7 的兼容 shim，用来处理旧系统 headers/libc 没有暴露某些符号的问题。
这种问题很现实。很多服务器环境不会因为一个 CLI 就升级系统。源码能在新机器上构建，不代表能在老服务器上顺利链接。
所以这个补丁包把兼容层单独放出来，而不是把问题写成“如果失败请自行处理”。这样使用者至少知道该从哪里查：
- 问题范围明确。
- 兼容代码位置明确。
- CI 至少能检查 shim 编译。
- 构建说明能解释为什么需要它。
既然仓库公开了，就别默认所有人都在作者那台机器上构建。把旧系统兼容问题写出来，后来的人能少排查一轮。
安装脚本要先备份
补丁包涉及替换已安装 CLI 的 vendor binary。这个动作风险很高。
所以安装脚本创建 timestamped backup 是必要的。没有备份，安装失败或者新 binary 行为异常时，用户就只能重新安装整套 CLI。
我更喜欢这种保守安装流程：
locate installed binaryverify built replacementbackup current binaryinstall replacement with expected moderun version/help smoke test这件事看起来繁琐，但对命令行工具来说值得做。工具一旦坏掉，可能会影响后续远程任务、自动化脚本和会话恢复。
CI 不一定要跑完整构建
这个仓库的 CI 重点是 shell syntax、patch parsing 和 shim compilation。
这个 CI 没有跑完整源码构建，我觉得可以接受。完整构建会绑到具体 checkout、Rust 工具链、系统库和安装路径；公共 CI 先检查 patch、脚本和 shim，覆盖的是发布包本身最容易坏的部分：
- 静态验证 patch 文件存在且能解析。
- 检查 shell 脚本基本语法。
- 编译兼容 shim。
- release workflow 能按 tag 触发。
README 是发布物的一部分
这类仓库的 README 其实就是发布说明。
它需要回答几个问题：
- 这个补丁针对哪个版本。
- 它修改了什么。
- 它不做什么。
- 需要什么前置源码和依赖。
- 如何构建。
- 如何安装。
- 如何验证。
- 失败时应该从哪些范围排查。
如果 README 只写“修好了某个问题”，别人拿到后仍然不知道该在哪个版本上打、怎么构建、失败后怎么退回去。
小补丁也要有发布范围
这次整理下来，我会把小补丁包的 README 固定检查这几项：
- 适用版本。
- 改动范围。
- 构建来源。
- 安装方式。
- 回滚路径。
- 验证结果。
- 已知环境范围。
codex-cli-0.131.0-issue14860-fix 的代码改动不大，但这些说明决定了别人能不能放心在自己的机器上试。
继续读