I test the webchat but some how it just randomly die, from "Resume stream unavailable" to " A network error occurred. Please check your connection and try again." #47711

Activity

1. baohappy02

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Sep 24, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Sep 24, 2026
3. SIMON-WORLD commented on Sep 24, 2026

   

   SIMON-WORLD

   on Sep 24, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction from ChatGPT Web on 2026-09-24:

   • ChatGPT Plus

   • Windows

   • ChatGPT Web

   • The failure has occurred multiple times today across existing conversations.

   • In the attached reproduction, the turn had already made visible progress and completed multiple tool interactions before the UI terminated with:

     Resume stream unavailable

   This was not a Deep Research run.

   Separately, on the same day I also observed intermittent existing-conversation load failures (Could not load this ChatGPT conversation). I am not claiming those two symptoms share one root cause; I mention the timing only as environment context.

   For the stream failure itself, the useful distinction is that the turn can be visibly active and progressing before the client loses the ability to resume/recover its output stream.

   I did not clear site data, reinstall, or change network/proxy configuration before these occurrences.
4. 84dnnvbdvp-debug commented on Sep 24, 2026

   

   84dnnvbdvp-debug

   on Sep 24, 2026 – with ChatGPT Codex Connector

   More actions

   One additional recovery boundary from a same-day reproduction: Resume stream unavailable can appear after a turn has already executed tool calls whose effects are independently durable. That means the client cannot safely treat this state as equivalent to “the turn failed, retry everything.” A full replay can duplicate side effects.

   A useful regression contract would be:

   1. assign a stable turn/execution ID before tool effects;
   2. after stream loss or resume failure, expose whether server state is running, completed, failed, or unknown;
   3. if completed, rehydrate the persisted assistant/tool events;
   4. if state is unknown, preserve existing effect receipts and do not automatically replay the turn;
   5. test with an idempotency-sensitive tool effect and verify reconnect/retry cannot execute it twice.

   This does not establish the transport or root cause. It narrows the recovery-correctness boundary: stream delivery failure and execution/effect failure are separate states.