用途：在夜间以 claude -p 启动大型仅规划批次后，若部分通道因“You've hit your limit · resets …”配额耗尽退出，而其他通道仍在正常推进时，仅对失败通道做通道级故障转移，改用 Codex 恢复，避免重启整批造成浪费与 git 争用。
前提条件：每个 issue 有独立隔离工作树；工作树内已有自包含 worker 提示文件；该通道为仅规划或可在无人工交互下安全重跑；Codex CLI 已安装并通过认证。可用 which codex、codex --version 验证。
恢复方式：从进程输出识别配额命中通道的信号，不要停止健康的 Claude 通道。仅对失败通道在同一工作树、同一提示文件下用 codex exec 重新启动，命令示例：codex exec --sandbox workspace-write -C <worktree> --skip-git-repo-check --output-last-message <log> "$PROMPT" </dev/null | tee <log>。随后记录新的进程/会话 id，继续同时监控存活 Claude 通道与 Codex 恢复通道，并在状态报告中区分健康原通道、失败 Claude 通道、Codex 回填通道。
优点：工作树所有权不变，保持零 git 争用；提示文件不变，保留可审计性；避免重做已成功的 Claude 工作；在供应商特定配额耗尽下仍维持批次推进。
限制与注意：这是通道级转移，不应中途整体切换供应商；Codex 恢复通道可能因沙箱/运行时问题失败，例如 bwrap RTM_NEWADDR 报错、js_repl 内核意外退出、MCP GitHub 获取/搜索失败，或最终摘要明确表示无计划文件、无评审产物、无 GitHub 变更成功。此时不应仅因进程在运行或退出码为 0 就视为已恢复，需检查日志中是否确实创建了计划文档、评审结果产物，或 GitHub 标签/评论变更成功；若为环境受阻，应归类为 environment-blocked，而非规划成功。若通道在 Claude 失败前已部分推进 GitHub 状态，重跑前需核对实时 issue 标签与评论，避免重复翻转标签或重复摘要评论。
适用场景：6 至 10 通道的夜间规划批次、plan-gated 仓库、按 issue 隔离工作树的编排。不适用于单通道工作、提示尚未写入磁盘或非隔离共享工作树的批次。资料中的示例受影响 issue 包括 #2454、#2447、#2439、#2445、#2446、#2440、#2449、#2452。