Codex decoding 报错的本质含义

decoding 指的是客户端将服务端推送的数据流解析为文本的过程。Codex 采用流式方式输出回答，逐帧接收并逐帧解码；一旦某一帧数据不完整、连接被中途改写或解码超时，解析即告失败，抛出 decoding 类报错。其核心含义是“无法读懂响应”，而非“请求被拒绝”。

该报错的典型完整形态为 stream disconnected before completion: Transport error: network error: error decoding response body。表现为任务正常启动、已收到部分输出，但流在中途断开，始终没有最终完成状态，同一任务重跑有时却能成功。需注意与两类报错区分：“Selected model is at capacity”属于服务端容量问题；“app-server is not available”则是本地后台进程不可达。

高频触发场景包括：大型仓库的长任务执行中途、resume 旧会话、以及代理环境下的流式输出。

六类典型成因与识别信号

报错常集中在版本更新后的首次长任务中：既可能是版本回归，也可能是更新重置了代理或缓存了过期登录态，需按后续对照顺序判断归属。

  • 代理链路掐断流式响应：SSE 帧中断、ECONNRESET、ETIMEDOUT，常见。
  • 缓存与登录态过期：清缓存重登后恢复，常见。
  • 旧会话上下文过大或输出过长：大仓库长报告任务必现，拆小后缓解，常见。
  • provider/接口配置残留：回到默认配置后消失，偶发。
  • 版本回归：0.129.0 及以上在 WSL 有已知问题，偶发。
  • 服务端偶发故障：同一时段大面积出现、稍后自愈，偶发。

验证有效的排查顺序

建议按以下顺序逐步推进：

  1. 清本地状态重登（通常最有效）：执行 codex logout → 删除 ~/.codex → codex login 重新登录。token 过期或缓存损坏时仍能发起请求，但流走到一半就断；删前确认路径并备份历史会话。
  2. 开新会话、避开 resume：挂了两三天的旧会话不要恢复，直接新建；上下文越大，流传输量越大，任何一环超时都会断。
  3. 固定版本对照：执行 codex --version 记录版本；更新后集中出现的，npm 安装的可回退上一版本对照，如 npm install -g @openai/[email protected]。
  4. 关代理对照：关掉代理跑一次，若恢复正常即为链路问题；必须走代理时有两条路——支持 TUN 模式的工具开虚拟网卡全局接管，或在 ~/.codex/ 建 .env 写入 all_proxy=http://127.0.0.1:7897（端口按实际设置）后重启。
  5. 清理 provider 残留：检查 ~/.config/openai/codex/ 下的配置，删掉不再使用的自定义接口条目。
  6. 任务拆小验证：大任务拆成多步；给 Codex 加上“每个文件控制在 500 行以内”的输出约束后，报错概率明显下降。
  7. 都不行就等：CLI 会自动重试；同一时段大面积出现多半是服务端压力，稍后重跑往往自愈。

日志关键词与处理方向对照：

  • ECONNRESET / ETIMEDOUT：链路被中间设备掐断，换出口对照、改显式代理。
  • finish_reason: “length”：单次生成被截断，拆小任务、调大输出上限。
  • 401 / auth 相关：登录态过期，清缓存重新登录。
  • context length / too large：会话体积过大，新建会话、拆分任务。

两个易忽略的细节：单纯重装通常无效——会话与缓存都在 .codex 目录里，卸载不触碰它；内网网关对未知域名做 302 跳转、往响应里塞 HTML 时，也会触发同类报错，表现为响应以尖括号开头。

代理环境为何更易触发

Codex 的流式响应依赖长连接，中间任何一跳对长连接不友好，都会以 decoding 失败的形式暴露。同一任务在系统代理下反复报 decoding，改用显式 HTTP 代理后可连续跑通；晚高峰拥塞时段报错明显增多，错峰后消失。

机制并不复杂：系统代理对 SSE/WebSocket 的支持常不完整，超时阈值偏短、对响应头处理不一致；低质量出口还存在响应帧被改写的情况。同一条报错在代理环境中有独立成因——本地排查全做完，链路不换仍可能复现。

2026 年为 Codex 选网络出口的四个标准

  • 协议完整度：低质量出口仅支持 HTTP，SOCKS 场景缺位；稳定出口 HTTP 与 SOCKS5 双协议可用。
  • 长连接稳定性：低质量出口高峰断连、流式帧超时；稳定出口 SSE/WebSocket 长连接稳定。
  • 出口一致性：低质量出口地区跳变，触发反复验证；稳定出口固定归属地，会话连续。
  • 并发与带宽：低质量出口晚高峰拥塞、任务中断；稳定出口带宽保障，多人共用不互相拖累。

综合对照结果，能被客户端显式指定的代理（如 .env 写入 all_proxy）优于全局系统代理，前提是出口本身支持长连接。IPxSS海外AI网络方案提供 HTTP 与 SOCKS5 双协议、固定归属出口，配套代理IP资源灵活扩展，可小批量验收后放量，一次性排掉链路侧变量。详见 https://www.ipxss.com/ 。

常见问题 FAQ

Codex error decoding response body 是账号被封吗？

不是。它是响应解析失败，属于链路或本地会话状态问题，与账号状态无关；同一账号换网络或新会话即可验证。

为什么 resume 旧会话更容易触发？

旧会话上下文大、历史消息多，流式帧更密集，链路稍有抖动就解码失败；新会话上下文小，容错更高。

开着代理时频繁 decoding，关掉就好，是什么原因？

典型是代理链路掐断流式响应：超时阈值偏短，或对 SSE/WebSocket 支持不完整。支持 TUN 模式的工具可开虚拟网卡全局接管；也可在 ~/.codex/ 建 .env 写入 all_proxy 显式指定后重启；或换长连接稳定的出口对照验证。

需要降级 Codex 版本吗？

仅当报错与特定小版本强相关、且排除网络与配置因素后才考虑；多数情况优先换链路对照。

decoding 报错会丢已生成的内容吗？

通常不会。已流式输出的内容保留在终端里，中断的是后续生成；换会话续写或重跑即可，不必从头再来。

总结

Codex error decoding response body 的本质是“读不懂响应”而不是“被拒绝”：多数报错与链路相关，本地侧聚焦缓存、会话体积、配置残留与版本四类。按“清缓存重登→开新会话→版本对照→代理对照→清配置残留→任务拆小”的顺序推进，多数情况不换机也能恢复。IPxSS海外AI网络方案提供双协议稳定出口，配套代理IP资源，适合开发团队长期固定使用。