What issue are you seeing?
In ChatGPT Work on the web, the conversation repeatedly shows:
Connection interrupted. Waiting for the complete answer.
The Chinese UI message is:
連線已中斷。正在等待完整回覆
During an observed incident on October 8, 2026, approximately 05:08–05:17 UTC, an assistant-operated cloud browser repeatedly encountered this state, including after reloading the page.
A separate read-only check of the same task showed that it still reported inProgress, and new assistant progress messages were persisted after the web display had stalled. This establishes a mismatch between the visible conversation and continuing persisted progress in this incident. The banner alone is not evidence that execution stopped.
In a later follow-up submission attempt on the web, the input appeared locally and the composer cleared. After a reload, that input was no longer visible, and it could not be verified in the persisted messages. The submission was not repeated because its acceptance was uncertain. This observation does not establish permanent data loss or whether the request reached the server.
What steps can reproduce the bug?
Observed sequence, not a deterministic minimal reproduction:
- Open an active cloud-backed ChatGPT Work conversation on the web.
- While the task is in progress, the conversation stops showing current progress and displays the connection-interrupted banner.
- Reload the page. In the observed incident, the banner recurred and the view did not reliably reconcile with newly persisted progress.
- Compare the displayed conversation with a separate read-only view of the same task: the task remains in progress and newer assistant progress exists.
- In a later attempt to continue from the web UI, submit a follow-up. It appears locally and the composer clears, but the input disappears after reload and cannot be confirmed in persisted history.
The trigger for the stream interruption and a reliable reproduction rate are unknown.
What is the expected behavior?
- Reconnect to the existing task and reconcile the visible conversation with persisted messages after a stream interruption or reload.
- Show whether the underlying task is running, completed, failed, or awaiting input, separately from the connection state.
- Clearly distinguish locally pending input from server-acknowledged input. Reliably persist acknowledged submissions; preserve an unsent draft and show an actionable error if submission fails.
- Offer recovery without requiring the user to repeat a prompt whose acceptance is uncertain.
The recurring failure requires repeated checks and leaves uncertainty about whether to wait, refresh, or resend.
Additional information
Environment and evidence limits
- Reporter's surfaces: ChatGPT web on Windows and the ChatGPT iOS app.
- The October 8 web observations above were checked in an assistant-operated cloud browser; they are not a claim that the reporter's Windows browser or iOS app was directly instrumented.
- Exact browser, Windows, iOS, and app versions were not collected.
- On October 7, I observed that sending text on the web produced no response, while sending input through the iOS app appeared to wake the conversation. This is a user-reported observation and was not independently reproduced.
- No shared root cause is asserted for the interrupted display, the unconfirmed follow-up submission, or the web/iOS difference. There is no claim of a service-wide outage.
Related reports reviewed
This report adds the specific Work web observation that new progress continues to persist while the UI remains interrupted, together with an unconfirmed follow-up submission that disappears after reload. A common cause with those reports has not been established.
Private conversation content, URLs and identifiers, account details, screenshots, credentials, and raw logs are intentionally omitted.
What issue are you seeing?
In ChatGPT Work on the web, the conversation repeatedly shows:
The Chinese UI message is:
During an observed incident on October 8, 2026, approximately 05:08–05:17 UTC, an assistant-operated cloud browser repeatedly encountered this state, including after reloading the page.
A separate read-only check of the same task showed that it still reported
inProgress, and new assistant progress messages were persisted after the web display had stalled. This establishes a mismatch between the visible conversation and continuing persisted progress in this incident. The banner alone is not evidence that execution stopped.In a later follow-up submission attempt on the web, the input appeared locally and the composer cleared. After a reload, that input was no longer visible, and it could not be verified in the persisted messages. The submission was not repeated because its acceptance was uncertain. This observation does not establish permanent data loss or whether the request reached the server.
What steps can reproduce the bug?
Observed sequence, not a deterministic minimal reproduction:
The trigger for the stream interruption and a reliable reproduction rate are unknown.
What is the expected behavior?
The recurring failure requires repeated checks and leaves uncertainty about whether to wait, refresh, or resend.
Additional information
Environment and evidence limits
Related reports reviewed
This report adds the specific Work web observation that new progress continues to persist while the UI remains interrupted, together with an unconfirmed follow-up submission that disappears after reload. A common cause with those reports has not been established.
Private conversation content, URLs and identifiers, account details, screenshots, credentials, and raw logs are intentionally omitted.