[BUG] Codex gpt-5.6-sol: "stream disconnected before completion" on /v1/responses (Codex Desktop 26.x)

[dataxad]

Summary

After the Codex Desktop app auto-updated (build 26.707.31428, default model gpt-5.6-sol), Codex requests routed through the Headroom proxy started failing mid-stream with:

stream disconnected before completion: error sending request for url (http://127.0.0.1:8787/v1/responses)

Pointing Codex at its native endpoint (bypassing the proxy) makes the disconnects stop, so the proxy's /v1/responses streaming path for this new Codex model is the suspect.

Environment

• Headroom: 0.31.0 (also reproduced on 0.30.0)
• OS: macOS 26.5.1, arm64
• Codex Desktop: build 26.707.31428
• Model: gpt-5.6-sol, model_reasoning_effort = "ultra"
• Proxy config: mode=token, backend=anthropic, Codex routed via a [model_providers.headroom] provider (supports_websockets = false), openai_base_url = http://127.0.0.1:8787/v1

Symptom / what the proxy shows

The proxy itself is healthy (steady readyz 200, no crash) and does accept and forward the request — it compresses the payload and forwards to the Codex backend as a streaming POST:

event=proxy_inbound_request method=POST path=/v1/responses ...
[hr_...] /v1/responses compressed 3902200→3890281 bytes (2352 tokens saved ...)
event=outbound_request forwarder=streaming method=POST path=https://chatgpt.com/backend-api/codex/responses ...

…but the client (Codex) then reports stream disconnected before completion against http://127.0.0.1:8787/v1/responses. No 4xx/5xx or exception is logged proxy-side around the disconnect — the stream just doesn't complete. Payloads are large (observed 3.9 MB requests).

This lines up with the cluster of open Responses-streaming issues (#1877, #1880, #1876) and appears specific to the new gpt-5.6-sol / Codex Desktop 26.x Responses protocol.

Repro

1. Codex Desktop 26.x (model gpt-5.6-sol) wrapped through Headroom (model_provider = headroom, openai_base_url = http://127.0.0.1:8787/v1).
2. Run a Codex turn with a non-trivial context (large /v1/responses payload).
3. The turn fails partway with stream disconnected before completion: error sending request for url (http://127.0.0.1:8787/v1/responses).

Workaround: comment out model_provider/openai_base_url in ~/.codex/config.toml so Codex talks to its native endpoint directly — disconnects stop.

Possibly related (separate, happy to file on its own)

On the same new Codex Desktop, with the proxy's memory feature enabled, every Codex /v1/responses call was rejected upstream with {"detail":"Store must be set to false"}. Traced to handlers/openai.py forcing payload["store"] = True when memory tools are injected ("forced store=true for Responses memory tool continuation"), which the Codex ChatGPT backend rejects. Disabling memory avoided it. Flagging in case both stem from the updated Codex Responses contract.

Happy to provide more logs (with --verbose) or test a patch.

[houleixx]

Since the proxy logs show a successful inbound request and an outbound streaming POST, the most useful next artifact would be the final few SSE events on both sides of Headroom.

I would check whether the upstream stream ends with a valid terminal event such as `response.completed`, whether Headroom forwards that event and the terminating blank line, and whether any event contains a field introduced by gpt-5.6-sol that the proxy parser does not recognize. It is also worth recording response status, `Content-Type`, transfer encoding, time-to-first-event, time of the last event, and whether the failure correlates with the ~3.9 MB request size. That separates an upstream early close, a parser/forwarder drop, client backpressure, and an idle timeout.

One way to gather a second request-level trace is to put ccglass between Codex's configurable OpenAI-compatible base URL and the Headroom upstream for a single reproduction. It shows the actual Responses request, reassembled streamed response/error, latency, usage, and turn-to-turn flow, and can export a raw transcript/JSON/HAR for comparison with Headroom's logs.

This will not fix the streaming implementation by itself, but it should answer the important question: what was the last complete event emitted upstream, and was the same terminal event delivered to Codex?

Project: https://github.com/jianshuo/ccglass

[dataxad]

Thanks — I used Headroom's own --codex-wire-debug to capture wire snapshots on the upstream side. A key result that narrows this a lot:

gpt-5.6-sol streams fine through the proxy for normal and large requests — I could not reproduce the disconnect via CLI.

Reproduced via codex exec (the Codex Desktop binary) routed through the proxy, wire-debug on:

• Small request (~5 KB body, ~21K input tokens): success.
• Large request (~535 KB stdin, ~105K input tokens): success.

Both completed with status 200 and a well-formed SSE sequence ending in a proper terminal event. Event types on the successful stream:

response.created → response.in_progress → response.output_item.added
→ response.content_part.added → response.output_text.delta (×785)
→ response.output_text.done → response.content_part.done
→ response.output_item.done → response.completed   ← terminal event present

The final response.completed frame carries full usage (input/output/total tokens) and the last sequence_number. No [DONE] sentinel — the Responses API terminates with response.completed, which Headroom received and forwarded correctly. So this is not a general gpt-5.6-sol SSE-format or terminal-event problem.

Where the failure actually occurs: the disconnects happen on real Codex Desktop turns, which are much larger (~3.9 MB request bodies observed) and carry beta features the CLI path doesn't — the inbound requests include x-codex-beta-features: memories, remote_compaction_v2. So the trigger looks specific to very large Desktop requests and/or those beta features, not the model's streaming per se. That lines up with the size correlation you flagged.

I have the successful-case wire snapshots (chunk + ..._complete.json) and can share sanitized versions. To capture a failing trace I'd need to instrument an actual large Desktop turn with wire-debug on — happy to do that if it'd help; let me know what artifact would be most useful (e.g. the last N SSE frames on both sides of a failing 3.9 MB turn, with Content-Type/transfer-encoding, time-to-first-event, and last-event time).

[abhay-codes07]

Since bypassing the proxy stops the disconnects, the failure is on the proxy's /v1/responses path for this model. A couple of things would make it reproducible:

1. The proxy-side log around the disconnect (~/.headroom/logs/proxy.log), specifically any line near the failed request: compression_timeout / Compression worker exceeded its request deadline (quarantine), Forwarding upstream streaming error status=..., or a traceback. The client message (stream disconnected before completion) only says the connection dropped; the proxy log says why.
2. Confirm the transport: you have supports_websockets = false, so this is the buffered HTTP /v1/responses streaming path (not the WS one). Is that right?
3. Does it fail on every request, or intermittently / only on large ones? model_reasoning_effort = "ultra" on gpt-5.6-sol can produce long reasoning streams, so a per-request timeout or an idle-read timeout on the proxy->upstream leg is a prime suspect. If you can, note the approximate response size / time-to-first-token when it drops.
4. The exact mode (you said token) and whether HEADROOM_OUTPUT_SHAPER or memory is on.

With the proxy-side error line and whether it is size/time-correlated, I can tell if it's a compression timeout, an upstream read timeout, or a reconstruction issue.