[Bug]: Codex Desktop receives response text but the turn never completes over WebSocket in 2.7.43/2.8.0 #864

Client or integration

Codex Desktop for Windows

Area

Responses API transport / WebSocket lifecycle

Summary

After upgrading OpenCodex from 2.7.39 to 2.7.43 / 2.8.0, responses routed from Codex Desktop through the local OpenCodex proxy to an OpenAI-compatible provider are generated successfully, but the Desktop turn does not reliably transition to the completed state.

With websockets: true, the assistant text appears in Codex Desktop, but the activity spinner and stop button remain active indefinitely. The user must stop the turn manually.

With websockets: false, the upstream HTTP SSE response returns status 200 and contains a complete event stream, but Codex Desktop remains on Thinking and does not render the new assistant response.

Rolling OpenCodex back to 2.7.39 and keeping websockets: true restores normal response completion.

Version

OpenCodex 2.7.43 and 2.8.0 are affected. OpenCodex 2.7.39 is the known working rollback version.

Operating system

Windows 10 Home 22H2, version 10.0.19045, build 19045, x64.

Provider and model

OpenAI-compatible Responses API provider at https://llm.ability.associates/v1, using ability/gpt-5.5 in Codex Desktop.

Environment details

PowerShell: 5.1.19041.6456
Codex Desktop: 26.727.4816.0 x64
Codex Desktop embedded app-server/CLI: 0.146.0-alpha.9.2
Global Codex CLI: 0.143.0
Local OpenCodex proxy: 127.0.0.1:10100
OpenCodex service: Windows scheduled task, running
Provider adapter: OpenAI-compatible Responses API

Reproduction

1. Install OpenCodex 2.7.43 or 2.8.0.
2. Set websockets to true in the OpenCodex configuration.
3. Run ocx ensure or ocx restart and confirm that the proxy is listening on port 10100.
4. Completely restart Codex Desktop.
5. Select ability/gpt-5.5.
6. Send a short prompt such as What model are you?.
7. Observe that the assistant response text is rendered.
8. Observe that the spinner and stop button remain active and the turn never completes automatically.
9. Stop the turn manually; the already generated response remains visible.

Alternative transport test:

1. Set websockets to false.
2. Restart OpenCodex and Codex Desktop.
3. Send the same short prompt.
4. The upstream request returns HTTP 200 with text/event-stream, but Codex Desktop remains on Thinking and does not render the assistant response.

Expected behavior

Codex Desktop should receive the final lifecycle event and transition the turn to completed after the upstream response finishes, regardless of whether the OpenCodex proxy uses WebSocket or HTTP SSE transport.

Observed behavior

websockets: true

• The provider receives POST /v1/responses.
• The provider returns HTTP 200 quickly.
• Assistant output text is displayed in Codex Desktop.
• The turn remains active indefinitely.
• The Desktop UI continues showing the spinner and stop button.
• Manual stop is required.

websockets: false

• The provider receives the request and returns a valid HTTP 200 SSE response.
• The raw stream completes.
• Codex Desktop does not display the response and remains on Thinking.

Isolation and supporting evidence

• The provider/VPS receives the request normally and returns status 200 within a few seconds.
• A raw HTTP request through the local OpenCodex proxy completes in approximately 2.2 seconds.
• The raw SSE stream contains the normal completion sequence:

response.created
response.output_text.done
response.output_item.done
response.completed

• In the failing WebSocket case, Codex Desktop logs include:

websocket reuse properties didn't match

• Output events reach the Desktop, but the turn does not appear to receive or recognize the final response.completed lifecycle event.
• Rolling back Codex Desktop itself to a previously working Desktop package did not resolve the problem while the newer OpenCodex version remained installed.
• Cold restarts and reinstalling the OpenCodex background service did not resolve it.
• Rolling OpenCodex back to 2.7.39, with websockets: true, restored normal turn completion.

This suggests a regression in the OpenCodex Responses API transport bridge, final-event forwarding, or WebSocket connection reuse logic introduced after 2.7.39. The provider appears to finish the response correctly.

Version timeline

Working: OpenCodex 2.7.39 + websockets enabled
Failing: OpenCodex 2.7.43 + websockets enabled
Failing: OpenCodex 2.8.0 + websockets enabled
Worse fallback behavior: newer OpenCodex + websockets disabled
Working again: rollback to OpenCodex 2.7.39 + websockets enabled

Redacted configuration

{
  "websockets": true,
  "providers": {
    "ability": {
      "baseUrl": "https://llm.ability.associates/v1",
      "models": ["gpt-5.5"]
    }
  }
}

Authentication values, tokens, account details, request bodies, and unrelated configuration have been removed.

Related issue check

Issue #857 concerns stale model catalogs and the spawn_agent allowlist. It appears to be a different lifecycle problem and does not cover this missing turn-completion behavior.

Checks

• I searched existing issues before submitting.
• I reproduced the behavior with short prompts.
• I compared WebSocket and HTTP SSE transport behavior.
• I verified that the upstream provider completed successfully.
• I verified that rollback to 2.7.39 restores normal behavior.
• I removed secrets, tokens, account details, credentials, and personal request content.