[Idea] Recover OpenAI Codex WebSocket 1006 disconnects instead of ending the turn

[oksure]

Context

When using the OpenAI Codex OAuth route in dsh for a long-running session, a turn can occasionally stop with:

This turn failed
WebSocket closed 1006
PI_AI_ERROR

This is intermittent and appears after the Responses WebSocket has started streaming.

What seems to happen

In dsh 0.1.1-rc.2, pi-ai's openai-codex-responses transport surfaces the close as WebSocket closed 1006. dsh-llm-pi-ai classifies several transport messages as TRANSPORT, but the numeric close form does not match its transport patterns, so it becomes PI_AI_ERROR.

The dsh-llm-retry plugin's normal policy retries TRANSPORT, SERVER, TIMEOUT, RATE_LIMIT, and EMPTY_RESPONSE with bounded backoff. It does not retry PI_AI_ERROR, so the failed step ends abruptly.

Proposed idea

1. Treat WebSocket closed with an optional numeric close code as TRANSPORT, while preserving non-retryable classification for auth, quota, invalid-request, and context errors.
2. Reuse the existing durable bounded retry path for a new request attempt.
3. Where safe, fall back from WebSocket to HTTPS SSE after a mid-stream disconnect. Avoid replaying any already durable assistant output or tool action.
4. Add regression coverage for close code 1006 before and after stream start, retry exhaustion, cancellation, and SSE fallback.

A low-risk workaround today is setting transport: sse on the OpenAI Personal route. In my local dsh setup this avoids the WebSocket path and the same request completes, but it sacrifices WebSocket session reuse when the WebSocket path is healthy.

The existing dsh-llm-retry implementation already has the durable event model, so the main gap seems to be error classification and safe transport fallback rather than an unbounded retry loop.

Related upstream report: earendil-works/pi#4629

[ObnubiladO]

A focused fix for the WebSocket closed 1006 classification gap described in Discussion #5666 is available in our fork:

Commit c045b1e026bac58e688f36f8480b75b30437caf5

The classifier recognizes WebSocket closed 1006, including an optional trailing reason, as TRANSPORT. This makes the failure eligible for the existing provider-owned bounded retry policy. The original error message is retained; cancellation remains ABORTED, and auth, quota, and invalid-request checks retain precedence. Other numeric close codes are not blanket-classified as transient.

The regression tests reproduce PI_AI_ERROR before the fix and pass afterward. They cover a close after a streamed text delta, cancellation, numeric-code boundaries, and non-transport exclusions. Validation on our fork: 170 focused converter/retry tests, all 15 quick documentation checks, lint on the changed TypeScript files, and the repository typecheck passed. Live OAuth disconnection recovery has not been tested.

Related work: Discussion #4341 already proposes broader WebSocket classification in valkia's patch. Our change is a narrower alternative for the specific 1006 report. Upstream master at d347e703908d0406b7a7ef80e3a0e594d86b2215, checked on September 6, 2026, still lacks this classification.

This addresses the classification portion of #5666; it does not implement automatic WebSocket-to-SSE fallback. Sharing here because the contribution guide currently directs external bug reports to Discussions and does not accept external PRs.