GPT(openai-codex) frequent transport interruptions (fetch failed/terminated) — data + questions

[dust617]

GPT (openai-codex) frequent transport interruptions — data + questions (pi-web user via a desktop wrapper)

Context: Pi Web user on Windows (Node 22, pi-web 0.8.6-based desktop wrapper), openai-codex via ChatGPT subscription OAuth, transport: sse, retry.provider.maxRetries: 4.

Symptom: GPT sessions frequently stop mid-output with fetch failed / terminated. Other providers (aliyun/deepseek) also hit it but far less often.

Data (scanning 185 session JSONLs, ~7 days, after fixing our local diagnostic tool to also match assistant-turn stopReason:"error" + errorMessage):

• 37 sessions end in transport errors: openai-codex/gpt-5.6-sol 11, gpt-5.6-terra 8, pi-router 8, aliyun 9, deepseek 1.
• Largest: 311 messages / ~2.2M est tokens, 6 consecutive fetch failed/terminated at session start.
• Transport failures never appear as standalone type:"error" events — only as assistant-turn stopReason:"error" + errorMessage, so naive scanners mislabel them "interrupted".

Questions for pi-web (root cause appears to be in pi-ai's openai-codex provider + regional OpenAI backend degradation, but want to confirm nothing pi-web-specific is involved):

1. Does pi-web apply any transport/retry defaults of its own, or pass through pi-ai settings untouched?
2. Any known pi-web issue with long-lived SSE sessions to chatgpt.com/backend-api (Asia Cloudflare PoP)?
3. Would an errorStatus/errorKind on errored AssistantMessage (Preserve HTTP status / error kind on the errored AssistantMessage earendil-works/pi#7234) help here too?

Happy to share more sanitized session statistics.

[agegr]

Thanks for the report. We need a little more diagnostic information to
distinguish a provider/network interruption from a Pi Web UI issue.

Please provide:

1. Your exact Pi Web version, provider, and model.
2. The full visible error message and relevant Pi Web server-console output,
   especially the stack trace and error.cause.code if present.
3. Approximately how long the request had been running, and how long it had
   been since the last streamed token. Please note whether it was close to
   300 seconds.
4. The corresponding assistant entry's stopReason and errorMessage from
   the session JSONL file. You may redact all prompt and response content.
5. Your httpIdleTimeoutMs, httpProxy, and retry settings, with all
   credentials removed.
6. Your region/proxy setup, and whether the same request also fails in Pi CLI
   on the same machine and network.
7. Whether the session was still shown as running after the UI appeared to stop.

Please do not include API keys, tokens, or sensitive conversation content.

[dust617]

Thanks for the detailed checklist — answering each point below (all credentials stripped; no conversation content included).

1. Version / provider / model

• Wrapper: pi-web-desktop 0.3.6 (Electron) bundling @agegr/pi-web 0.8.6; @earendil-works/pi-ai 0.83.0 (from resources/pi-web/node_modules).
• Provider: openai-codex (ChatGPT subscription OAuth), models gpt-5.6-sol / gpt-5.6-terra (some traffic also routed through a pi-router that ends on the same provider).
• Not pi-web-specific: the same provider profile fails identically in plain pi CLI sessions under ~/.pi/agent/sessions, since both use the same pi-ai provider code.

2. Full error message / server-console / cause.code
Session JSONL records show stopReason:"error" with errorMessage, plus a diagnostics[] entry {"type":"provider_transport_failure"} carrying the stack:

Error: WebSocket error
    at extractWebSocketError (.../@earendil-works/pi-ai/dist/api/openai-codex-responses.js:875:12)
    at WebSocket.onError (.../@earendil-works/pi-ai/dist/api/openai-codex-responses.js:954:18)
    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:843:20)

No error.cause.code appears on any record — the error is surfaced as a bare message string, so we cannot see the underlying errno. Distribution across 651 GPT errored turns: fetch failed 455, terminated 88, HTML error page (Cloudflare-style) 48, WebSocket error 21, Service Unavailable 15, Too many concurrent requests 5, context-window 5, upstream connect error or disconnect/reset before headers 1, ChatGPT usage-limit 1.

3. Time since last token / near 300s?
Median gap between the last successful assistant content and the error is ~34s; no clustering near 300s. httpIdleTimeoutMs is 600000 (600s), and errors occur mid-stream or at request start (e.g. one session opens with 6 consecutive fetch failed/terminated), not after an idle timeout. Note transport:"sse" is the pi agent-level transport; the openai-codex provider itself talks to chatgpt.com/backend-api over its own WebSocket (hence the WS error path above).

4. stopReason / errorMessage (redacted)
Example record (content omitted): {"role":"assistant","api":"openai-codex-responses","provider":"openai-codex","model":"gpt-5.6-sol","usage":{"totalTokens":0},"stopReason":"error","errorMessage":"fetch failed","diagnostics":[{"type":"provider_transport_failure","error":{"message":"WebSocket error",...}}]}. Errored turns produce zero output tokens.

5. Settings (no secrets)
httpIdleTimeoutMs: 600000; httpProxy: <unset>; retry: {enabled: true, maxRetries: 2, baseDelayMs: 3000, provider: {timeoutMs: 600000, maxRetries: 4, maxRetryDelayMs: 60000}}; transport: "sse".

6. Region / proxy; Pi CLI comparison
China network, no httpProxy, direct connection to chatgpt.com (Asia Cloudflare PoP). Same failures reproduce in the plain Pi CLI on the same machine/network (shared pi-ai code path). The official codex CLI on the same network does not visibly stall — it transparently retries up to 5 times — which supports the "regional provider transport flakiness absorbed by retries" hypothesis rather than a pi-web-specific bug.

7. UI state after stop
The desktop UI shows the turn stopped mid-output. From JSONL I cannot confirm whether it visually stayed "running", but the session ends on the errored assistant turn with no further messages, consistent with the agent aborting the round.

What would help us instrument further: errorStatus/errorKind on errored AssistantMessage (earendil-works/pi#7234) so we can separate 5xx vs network vs rate-limit without string-matching errorMessage, and a way to distinguish request-start vs mid-stream failures. Happy to share sanitized JSONL snippets if useful.