Codex长任务中断的解决方案：恢复会话、排查重连与减少丢进度

Codex 长任务中断，是任务执行过程被网络、客户端、审批、上下文或本地进程打断后没有继续输出；它不等于代码一定丢失。恢复的核心顺序是保留原会话、确认最后一个可验证状态、区分“任务暂停”和“进程退出”，再决定使用 resume、compact、/ps 或云端后台任务；截至 2026-08-27，OpenAI 官方文档已为 CLI、桌面端和云端分别提供恢复路径。

先给直接答案

Codex 长任务中断时，先恢复原会话并检查最后一次工具结果，再重试失败步骤；不要立刻新开聊天或删除 ~/.codex。 CLI 用 codex resume --last，非交互任务用 codex exec resume --last，桌面端用 Goal 的暂停/恢复，长上下文先执行 /compact。

先判断是哪一类中断

相同的“停住”现象可能来自五种不同层级，先看状态再选修复动作。

OpenAI 官方 Troubleshooting 文档建议，聊天卡住时先确认是否在等待审批，再在终端运行 git status 这类基本命令；只有短命令也失败时，才把问题升级到客户端或网络层。

CLI：恢复原来的交互会话

CLI 恢复的关键是使用保存的 session，而不是重新描述任务。 在原项目目录运行：

# 恢复当前目录最近一次会话
codex resume --last

# 打开会话选择器，按 ID 或名称恢复
codex resume

# 在所有目录的会话中搜索最近任务
codex resume --last --all

--last 默认只搜索当前工作目录；加 --all 才会跨目录搜索。若当前目录和会话保存目录不同，Codex 会询问使用哪一个目录；可在 config.toml 中设置 tui.resume_cwd = "current" 或 "session"，也可用 --cd 显式覆盖。

恢复后先发送一条短指令，要求 Codex 总结“最后完成的文件、最后一个成功命令、当前阻塞点和下一步”，再继续实现。这样能把恢复动作变成可审查的状态确认，而不是盲目重跑。

非交互任务：用codex exec resume

脚本或 CI 任务中断时，应恢复原来的 exec 会话并保留机器可读事件。 官方 CLI 支持 --last、--all 和 --json：

# 恢复当前目录最近一次非交互任务
codex exec resume --last

# 跨目录查找最近任务，并输出状态事件
codex exec resume --last --all --json

在 CI 中把事件流写入构建日志，同时使用 --output-last-message 保存最终摘要。恢复前先检查工作区是否仍是预期提交，避免把旧会话应用到错误分支。

桌面端和 IDE：暂停再恢复

桌面端或 IDE 里的长任务应优先使用 Goal 状态控制，而不是关闭窗口。 在 ChatGPT 桌面端、CLI 或 IDE 中输入 /goal 可以创建目标；桌面端的 Goal 进度条可暂停、恢复、编辑或清除。官方 Long-running work 文档说明，Goal 文本同时是任务目标和完成标准，目标长度上限为 4,000 个字符（OpenAI Docs，2026）。

当你准备离开电脑或预计网络会断时：

1. 在 Goal 进度条执行暂停，或在 CLI 输入 /goal pause。
2. 确认当前工具调用已经结束，记录最后一个成功命令和 git diff --stat。
3. 网络恢复、回到同一项目后执行 /goal resume，先让 Codex 输出状态摘要。
4. 只补发缺失的下一步，不要把整份原始需求重复粘贴。

桌面端还可以在设置中打开 Prevent sleep while running。它只防止本机睡眠，不会修复服务端故障、认证失效或企业网络阻断。

任务没停，是后台命令没结束

当 Codex 看起来没有响应时，先检查后台终端，而不是立即停止主任务。 官方 /ps 会列出当前会话的后台终端、命令和最多 3 行最近的非空输出（OpenAI Docs，2026）：

/ps

如果命令仍在编译、下载或测试，继续等待或发送后续指令；如果进程已经卡死，再执行：

/stop

/stop 会停止当前会话启动的后台终端，/clean 是同义别名。停止后先检查锁文件、端口和工作区差异，再决定是否重新运行命令。

上下文过长：先压缩，再继续

长任务最常见的“假中断”是上下文膨胀导致响应变慢、工具循环变长或新指令无法稳定执行。 在交互会话中输入：

/compact

官方 CLI 文档把 /compact 定义为“用摘要替换较早的对话，同时保留关键细节”。压缩后应立即核对四项：目标文件、已完成测试、未解决错误和禁止事项。若摘要遗漏了接口契约或测试命令，把这些内容写进项目 AGENTS.md 或单独的任务状态文件，再继续。

一个实用的状态模板是：

目标：
已完成文件：
最后成功命令：
失败命令与原始错误：
下一步：
验收标准：

中断后怎样确认代码没有丢

会话恢复和代码恢复是两件事，必须分别验证。 在项目目录执行只读检查：

git status --short
git diff --stat
git diff --check

若任务使用了未跟踪文件，再运行 git status --short 确认它们仍在磁盘；若 Codex 已经改完核心逻辑但还没测试，先运行项目已有的最小测试集。不要因为聊天中断就用 git reset --hard 清空现场。

如果需要比较某一轮改动，CLI 的 /diff 支持查看当前 Git 差异；桌面端 Review pane 的 Last turn 视图可以只看最近一次 Codex 回合的变更。

网络、认证和服务端异常怎么分层排查

错误码比“重连中”提示更有诊断价值。 建议按以下顺序收集证据：

1. 服务状态：确认 OpenAI 状态页或工作区公告，没有大范围故障。
2. 客户端版本：执行 codex --version；桌面端可检查其兼容 bundle 版本。CLI 与桌面端可能不是同一版本。
3. 认证状态：确认账号仍登录、workspace 权限未变化，必要时重新完成官方登录流程。
4. 网络路径：区分普通 HTTPS、WebSocket/长连接、企业代理和 TLS 检查；能打开首页不代表流式连接可用。
5. 最小复现：在空目录发送“只回复 OK”，再发送一次只读 git status；短任务成功而长任务失败，优先检查上下文、MCP、工具和超时。
6. 错误原文：记录 401、403、429、502、timeout、websocket closed 等完整文本和发生时间。

OpenAI Troubleshooting 文档建议保留应用日志和会话转录；macOS 应用日志位于 ~/Library/Logs/com.openai.codex/YYYY/MM/DD，会话默认位于 $CODEX_HOME/sessions。分享日志前要清理源代码、路径、令牌和客户数据。

用兼容 API 做隔离烟测

当你怀疑是 Codex 客户端链路而非模型服务问题时，可以用另一条 OpenAI-compatible API 做普通文本烟测，但它不能证明 Codex Responses 链路正常。

国内多模型 API 平台速查（2026年8月）

export QINIU_API_KEY="从控制台注入，不要写入仓库"
curl -sS https://api.qnaigc.com/v1/chat/completions \
  -H "Authorization: Bearer ${QINIU_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<控制台返回的完整模型 ID>",
    "messages": [{"role": "user", "content": "只回复 OK"}],
    "stream": false
  }'

若兼容 API 能返回、Codex 仍无法恢复，优先回到 Codex 的认证、会话、Responses 端点、代理和版本排查；不要把第三方 API 地址直接写进 Codex 配置，除非该平台明确提供并验证了 Codex 所需协议。

什么时候改用 Codex cloud

如果任务需要数小时运行、不能依赖本机在线状态，Codex cloud 更适合作为后台执行环境。 官方 Cloud 文档说明，云端任务在隔离环境中运行，你可以离开电脑后回来看日志和结果；CLI 可用 codex cloud list 查看任务，网页端也能继续观察和审查。

本地任务已经中断时，不要无条件把半成品重交云端。先保存当前分支和状态摘要，再把“剩余步骤、已改文件、测试结果、验收标准”作为新任务输入，避免云端重复修改同一工作区。

防止下一次中断

稳定的长任务依赖可恢复状态，而不是依赖模型一次性完成。 建议固定以下习惯：

• 开始前创建 Git checkpoint，结束后再检查 diff 和测试。
• 用 /goal 写清目标、约束和完成标准，目标过长时改放到文件中。
• 每完成一个阶段就写入状态摘要，记录命令、文件和失败原因。
• 长对话定期 /compact，只保留会影响下一步决策的上下文。
• 后台命令用 /ps 观察，确认卡死后再 /stop。
• 把 API Key 放到环境变量或密钥管理器，不写入 config.toml、日志和截图。
• 对高风险工具设置最小权限；先只读，再逐步开放写入和执行。
• 需要离开电脑时暂停 Goal，或改用 Codex cloud；不要让 Mac 睡眠中断本地进程。

结论

Codex 长任务中断的可靠处理顺序是“保留会话、确认状态、恢复原任务、验证代码、再继续”，CLI 优先使用 codex resume，长上下文使用 /compact，后台终端使用 /ps 和 /stop，桌面端使用 Goal 暂停/恢复。

OpenAI 官方 Long-running work、CLI 和 Troubleshooting 文档（2026）分别确认了 Goal、会话恢复、日志位置和卡住时的最小排查路径；本文属于高时效内容，建议在 39 天内复核命令、客户端版本和云端能力。

以上就是Codex长任务中断的解决方案：恢复会话、排查重连与减少丢进度的详细内容，更多关于Codex长任务中断解决的资料请关注脚本之家其它相关文章！

最新评论