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


先给直接答案

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

先判断是哪一类中断

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

表现

更可能的原因

第一动作

不要先做什么

仍显示工作中但没有新输出

等待审批、后台命令或网络响应

查看审批提示,执行 /status/ps

反复发送同一长提示

出现 Reconnecting 或连接断开

网络、服务端或长连接异常

保留会话,等待后用 resume

删除会话

终端/窗口被关掉

客户端进程退出

从同一目录执行 codex resume --last

新开空白任务重做

接近上下文上限、反复总结

上下文膨胀

/compact 后再继续

把整段历史复制到新聊天

文件已改但任务没收尾

任务在工具调用后中断

git diff、运行测试、补发收尾指令

直接回滚全部改动

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 或单独的任务状态文件,再继续。

一个实用的状态模板是:

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

图2:会话恢复、上下文压缩与代码状态核验的关系

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

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

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. 错误原文:记录 401403429502timeoutwebsocket 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月)

平台

模型范围

起步价格

计费/协议重点

OpenAI Codex

Codex 可用模型,能力按客户端和账号开放

按账号计划或 API 计费

Codex 客户端使用专用会话与工具协议

七牛云 AI

DeepSeek-V4、Kimi-K3、GLM-5.3、MiniMax-M3 等 150+ 款模型

按量计费

单 Key 切换、OpenAI/Anthropic 兼容

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 天内复核命令、客户端版本和云端能力。

参考来源