Repository navigation
Codex executor returns retryable 408 when stream closes before response.completed #3055
Description
Summary
When using the Claude-compatible /v1/messages route with a Codex-backed model alias, some large requests fail because the upstream stream closes before a final response.completed event is received.
CLIProxyAPI returns HTTP 408 for this case:
stream error: stream disconnected before completion: stream closed before response.completed
Because 408 is treated as retryable, the same request can be retried across credentials. This may cause multiple auth entries to become unavailable even though the failure appears to be request-specific.
Environment
- CLIProxyAPI version:
v6.9.37 - Route:
/v1/messages - Client: Claude Code
- Backend/executor: Codex executor
- Model alias example:
gpt-5.5 - Streaming enabled
- Request size observed: around
1.1MB - 1.3MB
Relevant config:
request-retry: 1
max-retry-credentials: 1
max-retry-interval: 30
streaming:
keepalive-seconds: 15
bootstrap-retries: 1
routing:
strategy: "round-robin"
session-affinity: true
session-affinity-ttl: "1h"Actual behavior
Large Claude Code requests routed through the Codex executor repeatedly fail with:
status=408
error=stream error: stream disconnected before completion: stream closed before response.completed
Observed log pattern:
status=408
content_length≈1155106-1321124
session=<same-session-id>
error=stream error: stream disconnected before completion: stream closed before response.completed
After repeated attempts, multiple auth entries can become unavailable:
auth_unavailable=4/6
auth_unavailable=5/6
Expected behavior
A request-specific stream completion failure should not cause broad credential rotation or make multiple auth entries unavailable.
Additional notes
Enabling streaming keepalive did not resolve the issue:
streaming:
keepalive-seconds: 15
bootstrap-retries: 1Limiting credential retries reduced the blast radius but did not eliminate the problem:
request-retry: 1
max-retry-credentials: 1Related PRs checked:
- fix(codex): classify context, thinking-signature, previous-response, and auth failures #3020 appears to classify explicit upstream Codex HTTP errors, but this issue happens after an upstream stream starts and then ends without
response.completed. - fix(models): correct GPT-5.5 Codex context length #3034 updates
gpt-5.5model context metadata, but this issue is about runtime stream completion behavior.
Activity
zzl360 commentedon Apr 26, 2026
#2358
#636
zrz-orz commentedon Apr 27, 2026
请问这个问题解决了吗？
zzl360 commentedon Apr 27, 2026
我是让大模型帮我改了下，遇到这个问题的时候，返回了400或者其他的错误值，提示需要压缩。算是缓解了这个问题，但最好还是官网在上游解决这个问题
RYQ-22 commentedon May 6, 2026
same here, especially with the gpt-5.5 model. I didn't run into this issue with gpt-5.4, but the performance of gpt-5.5 is much better. Now I have to start a new session whenever the context is long enough to trigger this issue.
WoChen5770 commentedon Jun 17, 2026
上游是newapi的现在基本上都会报这个错误了
265866 commentedon Jul 1, 2026
Hi, also getting this error w/ gpt5.5 on longer context sessions
feat(translator): improve error handling and response conversion for …
feat(translator): improve error handling and response conversion for …
fashen97 commentedon Jul 23, 2026
New reproduction on newer versions
I can reproduce the same client-visible failure on a much newer setup:
v7.2.95v1.18.4gpt-5.6-terrarequest-retry: 3max-retry-credentials: 5streaming.keepalive-seconds: 15streaming.bootstrap-retries: 3The client receives HTTP 408 before any usable Responses event:
{"type":"error","sequence_number":0,"code":"request_timeout","message":"stream error: stream disconnected before completion: stream closed before response.completed"}The
sequence_numberis0; OpenCode has not received a usable response event and terminates the turn, so the user must manually resubmit the task.One affected upstream request returned these correlation headers:
This was not a normal HTTP 429 rate-limit response.
Additional network observation: CPA traffic to
chatgpt.comis transparently routed through a local TUN/Fake-IP proxy path. In an 8-request HTTPS probe, the first TLS handshake took about 3.9 seconds and the following requests took about 0.13-0.19 seconds. An explicit local HTTP proxy path was consistently about 0.11-0.17 seconds for TLS. I do not claim this proves a network-only cause, but it may matter when CPA opens fresh upstream connections.Could a maintainer please help determine whether CPA is seeing an upstream clean EOF, an underlying transport/read error, or losing the terminal event while parsing or forwarding the stream? The client-visible 408 does not distinguish these cases.
Could this issue be reopened, or linked to the relevant fix if one already exists? I can provide redacted debug logs or raw final SSE frames if you can specify the useful fields.
feat(translator): improve error handling and response conversion for …
feat(translator): improve error handling and response conversion for …
RoySalisbury commentedon Sep 15, 2026
Additional reproduction on CLIProxyAPI v7.3.3 (
7bbfeaf) with OpenCode 1.18.29, with a specific downstream error-classification observation.Route: OpenCode →
/v1/chat/completions→ CLIProxyAPI → Codex upstream.The proxy-side request/response log shows:
response.created,response.in_progress, and manyresponse.output_text.deltaevents.response.completed.stream error: stream disconnected before completion: stream closed before response.completed.Configured protections:
The user observed OpenCode terminating the turn without automatic recovery. Client-side normalized error and retry traces have not yet been captured; we are not claiming a proven internal client classification path or an established root cause for the upstream disconnect.
Question: should a premature upstream stream disconnect be emitted with a stable transient stream/transport error type and code, rather than
invalid_request_errorwith no code? That label describes this transport/completion failure as a bad request and may prevent downstream clients from recognizing it as recoverable.This example is after generated output, so we are not asking the proxy to transparently replay the generation or treating bootstrap retries as a fix. Downstream recovery needs to preserve partial progress and avoid replaying completed tool actions.
Corresponding OpenCode report with the sanitized sequence:
anomalyco/opencode#30611 (comment)
Full request logs are intentionally omitted because they contain conversation content and headers.