[macOS Desktop] Response stream disconnect followed by repeated silent turns in existing task

Summary

An existing local desktop task stopped making progress after a logged Responses WebSocket disconnect. Subsequent turn starts were acknowledged but produced no recorded assistant responses or tool calls before manual interruption. This intermittently prevents sustained tasks from finishing.

Environment

• macOS desktop app version: 26.901.41123 (installed app bundle)
• Model: gpt-6-astra; initial work used ultra effort, subsequent unsuccessful attempts already used medium
• Local workspace; desktop app logs and saved execution transcripts inspected

Correlated timeline (UTC, September 5, 2026)

• 01:15:32: Initial production turn logged stream disconnected before completion: websocket closed by server before response.completed, retry 2/5. That turn subsequently completed at 01:29:49, showing recovery was possible earlier.
• 01:31:33: Follow-up edit turn completed its renderer-code inspection successfully (exit 0; output returned).
• 01:31:46: Subagent follow-up tool returned.
• 01:32:13: Last recorded parent reasoning item.
• 01:34:56: This same follow-up turn logged the WebSocket error above and stream disconnected - retrying sampling request (2/5 in 400ms)....
• 01:35:30: Child completion event arrived; no further parent tool execution was recorded.
• 01:45:19: User interrupted the stalled turn.
• Subsequent starts that evening and the following morning produced no recorded assistant/tool response before interruption (approximately 76–171 seconds each).
• 14:22:37 and 14:25:02: Two simple-command test attempts likewise produced no recorded assistant/tool items before manual interruption after 71.711 and 98.437 seconds. A separate task could execute date immediately.

Expected behavior

After a stream disconnect, recover and continue execution or surface an actionable failure. Existing tasks should not remain apparently active with no observable progress on repeated follow-ups.

Evidence boundaries

The local logs show retry 2/5, not proof that all five retries were exhausted. Repeated forwarding of one error into UI logs was deduplicated. The later silent turns have no explicit correlated sampling error in the inspected desktop logs. No explicit context-limit or rate-limit rejection was found. Last recorded input usage before the original stall was 197,688 against a reported 258,400 context window; this does not exclude backend history-processing defects.

Host network testing found failed IPv6 connections while IPv4 HTTPS worked. Switching the Mac to local-only IPv6 did not resolve the subsequent silent-turn tests; IPv6 causation is unproven. No private transcript contents, raw logs, credentials, or local file paths are included here.

Investigation request

Please investigate response-stream retry recovery and subsequent turn execution/event delivery for existing desktop tasks. In particular, distinguish sampling requests left pending from client event-delivery/replay failures. Exact task/turn identifiers and local source references are retained for private support follow-up.

Potentially related reports: #35203 (Windows existing-task recovery), #28115, #20739. This report adds macOS evidence connecting a successful tool completion, a disconnect in the same turn, and repeated later silent starts.

Start with the desktop logs around the recorded stream disconnected before completion and retry messages, then compare the original stalled turn with the later silent turns. Trace whether sampling requests remain pending or whether client event delivery/replay fails. Done means reproducing the failure boundary and confirming recovery or an actionable error after a disconnect.