# Codex 远程压缩失败：先看完整报错，再决定重试还是恢复会话

> 遇到 Error running remote compact task 时，先保留文件和会话现场，再按 stream、timeout、404、参数、上下文或子进程后缀定位正确边界。

- Source: https://www.aifreeapi.com/zh/posts/codex-remote-compact-task-error
- Language: zh
- Published: 2026-08-25
- Updated: 2026-08-25
- Publisher: AI Free API (https://www.aifreeapi.com)

`Error running remote compact task` 不是一个完整的根因诊断。它表示 Codex 正在把长会话压缩成更小的上下文，以便继续工作，但这一步没有正常完成。网络流中断、请求超时、provider 不支持压缩路径、参数不兼容、输入超出模型上下文、内容被拦截、返回格式解析失败，甚至子进程迟迟不退出，都可能挂在同一个前缀后面。

因此，先不要删除 `.codex`、退出账号、切模型、换 provider 和新建多个会话。先把完整报错保存下来，尤其是冒号后面的后缀；再查看 Git diff、未跟踪文件和仍在运行的命令。压缩失败不等于前面的工具调用、写文件或远程任务从未发生。重复一次写操作之前，必须先确认它是否已经部分完成。

## 先用后缀确定排查对象

下面不是“看到某个词就一定是什么原因”，而是把第一次检查限制在正确边界。

| 完整报错中的线索 | 优先检查 | 第一次小测试 |
|---|---|---|
| `stream disconnected before completion`、`stream closed before response.completed` | Codex 到服务端的流式连接、代理/VPN、远程主机网络、客户端版本 | 保持账号、模型、项目不变，只在同一会话恢复一次；记录是否仍停在压缩阶段 |
| `request timed out` 或短暂高负载提示 | 一次请求等待结束，或当时服务路线不可用 | 等一个短间隔后做一次相同路线的小重试，不连续开多个任务 |
| `404 Not Found` | 当前 base URL 根本没有压缩路由，或 app/CLI 与 provider 合同不一致 | 确认实际 provider 和 base URL，再核对它是否明确支持对应的 compact endpoint |
| `Unknown parameter`、`service_tier`、variant 或字段解析错误 | 客户端发送的参数、模型能力、第三方兼容层、返回结构 | 保留完整响应体并固定模型；不要用“兼容 Responses”推断它也兼容 compaction |
| `input exceeds ... context window`、`ran out of room` | 压缩请求本身也装不下当前历史，或所选模型上下文不匹配 | 先提取已完成事项、关键决定、文件和下一步，再用精简交接开启新会话 |
| `Request blocked` 或明确的内容拦截信息 | 当前压缩输入触发了策略或安全过滤 | 缩小到最小可复现内容；不要用重试次数证明它是网络故障 |
| `timeout waiting for child process to exit` | 压缩流程在等本地/远程子进程结束 | 检查最后一个命令是否是 watcher、开发服务器、等待 stdin 的脚本或未关闭句柄 |

只有一个外层前缀、没有后缀时，也不要猜。记录 Codex 入口和版本、时间与时区、最后一条可见动作，以及错误发生在自动压缩还是手动 `/compact`。这些信息比“我重试了很多次”更容易把问题交给正确的边界。

![Codex 远程压缩失败的完整后缀分类、访问路线差异、最小恢复动作和可复现记录组成的综合诊断地图](https://www.aifreeapi.com/posts/zh/codex-remote-compact-task-error/img/suffix-route-recovery-map.webp)

## 路线不同，所谓“远程”也不同

OpenAI 的 [Compact a response API 参考](https://developers.openai.com/api/reference/java/resources/responses/methods/compact)把公开接口定义为 `POST /responses/compact`，返回用于继续对话的压缩结果。官方的[模型压缩说明](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.2)还强调，压缩项是不透明的继续状态，不应依赖其内部格式。

但 Codex 用 ChatGPT 登录、直接使用 OpenAI API key，以及配置第三方 provider/base URL，并不是同一条访问合同：

- ChatGPT 登录由 Codex 客户端和对应的 ChatGPT 服务路线处理，不能拿第三方网关的 `/v1` 支持情况直接解释；
- 直接 API 路线要看所选模型和项目是否支持当前请求；
- 第三方 provider 即使支持普通 `/responses`，也不代表它支持 `/responses/compact`、相同参数和相同流式事件；
- 桌面端、终端、Remote SSH 和容器可能继承不同的代理、DNS、证书与环境变量。

所以“浏览器能打开 ChatGPT”只能证明浏览器那条路线可用。“普通对话能返回”也只能证明普通 response 路线可用。它们都不能替代对压缩请求实际运行位置与 provider 合同的确认。

## 用最小恢复动作保住原任务

如果当前会话仍可选择，优先保留它。OpenAI 的 [Codex 开发者命令文档](https://learn.chatgpt.com/docs/developer-commands?surface=cli)记录了几个用途不同的入口：

- `/status` 查看当前会话配置与上下文状态；
- `/compact` 手动压缩当前会话；
- `codex resume` 恢复交互会话；
- `codex exec resume` 恢复符合条件的非交互任务；
- `codex doctor` 生成安装、配置、认证与运行环境诊断；
- `/feedback` 可提交反馈并按界面选择附带日志。

按下面的顺序做一次有诊断价值的恢复：

1. 查看仓库改动、后台进程和远程任务，标记已经发生的写操作；
2. 复制完整错误，记录版本、入口、登录方式或 provider、时间和 session ID；
3. 保持账号、模型、项目和网络路线不变，只恢复原会话一次；
4. 若后缀指向明确的 404、参数或子进程问题，只修改那一个条件；
5. 先执行只读或容易撤销的小动作，成功后再继续原任务。

![把七类 Codex 远程压缩错误后缀分别对应到一个优先检查边界和一次只改一项的可逆测试](https://www.aifreeapi.com/posts/zh/codex-remote-compact-task-error/img/one-variable-test-map.webp)

若原会话每次恢复都会立刻重新进入失败的压缩，不要无限循环。先写一份短交接：目标、已完成事项、关键决定、改动文件、验证结果、未解决风险和唯一下一步；然后再 fork 或开启新会话。这样损失的是聊天冗余，而不是任务状态。

## 哪些常见做法不适合作为第一步

删除整个 `.codex`、清空缓存或重新登录，可能同时移除会话定位、配置和诊断线索；只有证据明确指向损坏的本地状态时，才应在备份后缩小到具体对象。临时换一个模型有时会改变压缩能否完成，但它同时改变了模型能力、上下文和 provider 路线，不能证明原原因。把 timeout 从 60 秒改成 600 秒，只对“同一操作稳定地稍晚完成”有意义；对 404、参数错误、崩溃或死锁没有修复作用。

如果完整错误其实是 HTTP 429、额度或使用窗口问题，应转到 [Codex 429 限制诊断](/zh/posts/codex-rate-limits)。如果连压缩阶段都不能确定，先用 [Codex 通用超时分层方法](/zh/posts/codex-timeout)找最后一个有进展的位置。若证据指向 provider、代理、沙箱或命令网络边界，再查 [Codex sandbox 与 config.toml](/zh/posts/codex-config-toml)，不要把所有路线一次性重写。

## 重复失败时，留下能复现的记录

一份有效报告不需要上传整个项目。保留 Codex 版本和入口、操作系统、认证类型、provider/base URL（隐藏密钥）、完整错误与时间、session/request ID、最后完成动作、是否自动或手动触发压缩、最小复现步骤，以及相关日志中不含隐私的片段。分享前删除 token、邮箱、私有提示词、源码和项目标识。

这条报错最重要的信息不在 `Error running remote compact task` 本身，而在它后面。先保住工作，再让下一次动作只回答一个问题：是流式连接、等待时间、路由合同、上下文、内容、解析，还是子进程真正拥有这次失败。