Codex知道几点恢复额度，却选择让任务死在你睡着的夜里

openai/codex 仓库里有一个开了快半年的功能请求（#21073，5 月 4 日提交），诉求只有一句话：任务跑到一半撞上用量限额时，错误信息里明明带着确切的恢复时间——“try again at 6:34 AM”——为什么不能到点自动接着跑，而要让人定闹钟爬起来敲一句 continue？

这条 issue 下面攒了 23 条评论。它不是孤例：把同一仓库翻一遍，至少有五条 open issue 在要同一件事，只是入口不同——CLI 会话（#21073）、App 里 5 小时制 Goal 任务（#28931）、暂停中的 Goals 等配额刷新（#31386）、挂起而非终止会话（#34188）、长任务的持久自动续跑（#43605）。9 月的一条评论做了整理，结论直白：贡献指南要求大家"给描述同一需求的已有 issue 点赞"，而按界面拆分议题的做法让四个月的集中需求看起来像五个零散呼声，这个分裂本身正在伤害信号的可读性。

机制上它几乎是免费的

报告者论证过实现成本：恢复时间戳本来就是协议里的结构化数据（UsageLimitReachedError.resets_at），会话层收到限额错误时已经在更新速率限制状态——今天代码拿着这个时间戳做的事，是把它扔掉然后终止回合。功能请求的全部内容是"用它"。

这条论证后来被社区工具反向验证了。一个外部工具的作者发现比解析报错文案更可靠的取证点：Codex 写在本地会话记录（rollout 文件）里的就是 Unix 时间戳形式的真实重置时间，CLI、IDE 扩展、桌面应用三种形态共享同一份数据，等待逻辑因此可以精确到秒而不是靠正则匹配"Try again at 3:51 PM"这类人话。另一个 watchdog 项目走的是 app-server 接口（account/rateLimits/read）：读到同样的结构化重置时间戳（primary.resetsAt），先确认配额真的可用，再向原会话注入恰好一条续跑消息——刻意不用反复 codex exec resume 当轮询器，那会往历史里堆重复的续跑回合。

技术判断到这里其实已经清楚了：这不是"能不能"的问题。

竞品三个月前交了卷

整理那条同时给出第二个论据：Claude Code 在 2026 年 8 月 17 日的 2.1.234 版 changelog 里上线了同款能力，原文是"用量限额重置后自动继续你的会话；可在 /config 里关掉（Continue automatically at usage limit）"。从 Codex 侧 issue 开立算起，中间隔了三个半月。

值得产品经理细读的是那两个实现决定。第一，默认开启，关闭开关藏在配置里——因为这个功能存在的场景恰恰是"人不在键盘前"，需要启动时手动加旗标的设计等于在最需要它的时刻缺席。第二，恢复动作是"续写"而不是"重放"：接手的上下文被告知继续被打断的工作、不要重做已完成的部分。对比之下，Codex 原提案里 --auto-resume-on-limit 的字面语义是重新执行同一个回合——而那个回合可能已经写过文件、跑过命令，重放并不总是安全。评论里这句辨析点出了需求定义里最容易漏的一格：恢复和重启之间的差异，要在动手写之前说清。

后续跟帖把第三条边界也补上了：多个用户强调自动续跑必须保留原有模型与权限设置、尊重其他已耗尽的配额、遇到需要输入或审批的步骤就停下等人，并提供可见的"将于何时继续"状态和取消入口。这些都不是宏大架构，全是把一个已知时间戳用对之后顺手要配的安全带。

官方沉默期里长出来的第三方生态

半年没等到官方回应的这段时间里，issue 评论区自己变成了一个小型市场。数一数：至少四个外部工具先后在这里发布——一个跨 CLI 通用的看门狗（监听终端横幅、解析所有重置格式、到期 resume，MIT 开源）；一个 Windows 桌面应用的自动续跑器（先查配额真的可用再发续跑，走官方 queue 命令不碰 GUI 自动化，迭代到 v0.6.20 后扩展到覆盖 CLI 和 VS Code 场景）；一个读 app-server 配额接口做验证后再恢复的参考实现；以及 10 月 17 日有人把这件事做成了打包桌面产品（Bellows，除限额续跑外还加了"换一家 Agent 接手"的分叉选项，问题推送到配对手机上回答）。

这串自发供给传递了三重信号。需求强度是真的，真到有五六个团队愿意为它维护软件；技术门槛是低的，低到个人开发者各自就能造出一个；而产品空白是有代价的——每多一个第三方站在缺口上，官方的"原生方案才更干净可靠"（多个作者自己在声明里写的这句话）就多一分紧迫。其中打包成桌面产品的那一个尤其值得玩味：它意味着"限额管理"正在被当成一层独立的产品面来做，而不只是订阅条款的附属品。

对做 Agent 平台的人，这一节可以直接抄成一张检查表：你的系统有没有一个"已知的未来可用时间点"被当成一次性错误文本消费掉了？凡是错误信息里带了时间戳、重试建议、恢复条件的场合，都值得问一句——这些信息是给机器用的还是给人截图发牢骚用的。

还没完的事

截至 11 月 2 日复核，#21073 与 #28931 都仍是 open 状态，标签停在 enhancement/rate-limits。竞品交卷、社区交卷、整理评论呼吁把分散的议题合并却始终没有合拢，官方功能仍停留在"基本免费就能做"的自我论证阶段——这个悬而未决本身也是材料的一部分：它说明限额续跑卡住的环节大概率不是工程排期评估，而是某种产品哲学上的犹豫（自动烧下去 vs 强制人工确认，谁替用户做主）。哪种犹豫合理，只有 OpenAI 自己能回答；但用户行为已经给出了短期答案——装不上官方版的人会装第三方的。

文中数字口径：点赞与评论数以采集回执快照（2026-11-02）为准，GitHub 计数持续增长；changelog 引文来自评论者转述的 Claude Code 2.1.234 版本记录，我们未独立核对原始发布页；第三方工具的功能描述均取自其作者在 issue 下的自述，本文未实测任何一款。

参考来源：openai/codex issue #21073、#28931 原始页面（采集快照 2026-11-02）；文中 #31386、#34188、#43605 编号转述自这两页评论区的整理条目，未单独采集。