先给直接答案

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

先判断是哪一类中断

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

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

CLI：恢复原来的交互会话

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

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

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

非交互任务：用codex exec resume

脚本或 CI 任务中断时，应恢复原来的 exec 会话并保留机器可读事件。 官方 CLI 支持 --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）：

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

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

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

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

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

一个实用的状态模板是：

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

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

若任务使用了未跟踪文件，再运行 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月）

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