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。这些信息比“我重试了很多次”更容易把问题交给正确的边界。
路线不同，所谓“远程”也不同
OpenAI 的 Compact a response API 参考把公开接口定义为 POST /responses/compact，返回用于继续对话的压缩结果。官方的模型压缩说明还强调，压缩项是不透明的继续状态，不应依赖其内部格式。
但 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 开发者命令文档记录了几个用途不同的入口：
/status查看当前会话配置与上下文状态；/compact手动压缩当前会话；codex resume恢复交互会话；codex exec resume恢复符合条件的非交互任务；codex doctor生成安装、配置、认证与运行环境诊断；/feedback可提交反馈并按界面选择附带日志。
按下面的顺序做一次有诊断价值的恢复：
- 查看仓库改动、后台进程和远程任务，标记已经发生的写操作；
- 复制完整错误，记录版本、入口、登录方式或 provider、时间和 session ID；
- 保持账号、模型、项目和网络路线不变，只恢复原会话一次；
- 若后缀指向明确的 404、参数或子进程问题，只修改那一个条件；
- 先执行只读或容易撤销的小动作，成功后再继续原任务。
若原会话每次恢复都会立刻重新进入失败的压缩，不要无限循环。先写一份短交接：目标、已完成事项、关键决定、改动文件、验证结果、未解决风险和唯一下一步；然后再 fork 或开启新会话。这样损失的是聊天冗余，而不是任务状态。
哪些常见做法不适合作为第一步
删除整个 .codex、清空缓存或重新登录，可能同时移除会话定位、配置和诊断线索；只有证据明确指向损坏的本地状态时，才应在备份后缩小到具体对象。临时换一个模型有时会改变压缩能否完成，但它同时改变了模型能力、上下文和 provider 路线，不能证明原原因。把 timeout 从 60 秒改成 600 秒，只对“同一操作稳定地稍晚完成”有意义；对 404、参数错误、崩溃或死锁没有修复作用。
如果完整错误其实是 HTTP 429、额度或使用窗口问题，应转到 Codex 429 限制诊断。如果连压缩阶段都不能确定，先用 Codex 通用超时分层方法找最后一个有进展的位置。若证据指向 provider、代理、沙箱或命令网络边界，再查 Codex sandbox 与 config.toml，不要把所有路线一次性重写。
重复失败时，留下能复现的记录
一份有效报告不需要上传整个项目。保留 Codex 版本和入口、操作系统、认证类型、provider/base URL（隐藏密钥）、完整错误与时间、session/request ID、最后完成动作、是否自动或手动触发压缩、最小复现步骤，以及相关日志中不含隐私的片段。分享前删除 token、邮箱、私有提示词、源码和项目标识。
这条报错最重要的信息不在 Error running remote compact task 本身，而在它后面。先保住工作，再让下一次动作只回答一个问题：是流式连接、等待时间、路由合同、上下文、内容、解析，还是子进程真正拥有这次失败。
