Codex Desktop does not surface completed turn after transient network disconnect #32467

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.3748.0 on Windows (version recovered from the installed Windows package path after the incident; the About dialog was not captured during the incident). Bundled/available CLI: codex-cli 0.133.0.

What subscription do you have?

Not captured for this report.

What platform is your computer?

Microsoft Windows 11 Pro, version 10.0.26200, x64.

What issue are you seeing?

After a transient local network interruption during an active Codex Desktop turn, the app exhausted its reconnect attempts and left the task in an ambiguous state.

The UI showed repeated Reconnecting 1/5 through Reconnecting 5/5 messages followed by:

stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

This report is not claiming an OpenAI outage. The network interruption was local.

The important recovery problem is that substantial work had completed: child-agent activity was visible and three generated-image results appeared as thumbnails. However, no terminal assistant response or trustworthy completed/failed state was shown. I could not tell whether the task was still running, interrupted, or finished.

After I sent a new follow-up message—was the run interrupted—Codex responded in a new turn that the previous run had completed successfully and surfaced the expected final handoff. The extra follow-up itself showed a new long “Worked for…” interval.

This creates a risk of rerunning already completed work, wasting time/usage, or acting on an incomplete-looking task even though its artifacts exist.

What steps can reproduce the bug?

1. Open a Codex Desktop task on Windows.
2. Start a multi-step task that uses tools and produces visible artifacts. In this case the task used browser/command tools, child-agent work, and generated three homepage mockups.
3. Interrupt the local network while the turn is active.
4. Restore connectivity after Codex has begun retrying.
5. Observe Reconnecting 1/5 through 5/5 and the stream disconnected before completion error.
6. Observe that completed tool/artifact outputs may still appear, but there is no final assistant response and no authoritative completed/failed/recoverable state.
7. Send a separate follow-up asking whether the run was interrupted.
8. Observe that Codex then reports that the prior run had completed and provides the missing handoff.

This was observed on July 11, 2026. The model shown in the task UI was 5.6 Sol Ultra.

What is the expected behavior?

After connectivity returns, Codex Desktop should reattach to the active turn and reconcile its authoritative state.

If the remote turn completed, the app should automatically display the terminal assistant response and mark the turn complete.

If automatic reattachment is impossible, the app should show a clear recovery state such as:

• “The turn completed while disconnected — load final result”
• “The turn is still running — reattach”
• “The turn was interrupted — resume from the last completed step”
• “The final state is unknown — retry status check without rerunning completed work”

A user should not need to spend another model turn asking whether the previous turn completed.

Additional information

Related but not exact duplicates:

• Codex Desktop stalls on an existing long-running thread: WebSocket closes before response.completed, while HTTP fallback returns 200 OK but produces no stream events #32366 — Desktop stream stalls/reconnect behavior on an existing thread
• Viewing images causes sessions to be stuck in a Reconnecting loop #32394 — image-related reconnect loop
• Codex Desktop meta-bug: unbounded session/turn state causes freezes, context bloat, and lost active-turn control #25779 — meta issue covering lost active-turn control and renderer/session reconciliation

The distinguishing symptom here is: completed artifacts became visible after a transient network failure, but the final assistant response and terminal turn state were not reconciled until a separate user follow-up.

Two screenshots showing the reconnect loop, generated-result thumbnails, missing final response, and later recovery are available and can be attached if useful.