›_ Codex Issues
Codex Issues / #26274

Repeated reconnect loops on home network make Codex unreliable and sometimes unusable

Open 💬 4 comments Opened Jun 4, 2026 by GGBondBlueWhale
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex app version

Desktop Codex: 26.601.21317 — released Jun 2, 2026

Platform

  • macOS Tahoe 26.5.1
  • Apple Silicon MacBook Pro
  • Pro plan
  • Network: home network

Related feedback ID

019e8c77-2617-7b23-b61f-18bfe6b565e1

Summary

Codex Desktop repeatedly enters reconnect loops on my home network, making the app unreliable and sometimes impossible to use normally.

This does not happen as a single isolated failure. The problem has happened repeatedly: sometimes Codex works normally, but at other times it repeatedly disconnects and reconnects during an active task.

Observed behavior

During a task, Codex can show repeated reconnect attempts such as:

Reconnecting... 2/5
Reconnecting... 3/5
Reconnecting... 4/5
Reconnecting... 5/5

<img width="2496" height="660" alt="Image" src="https://github.com/user-attachments/assets/e0414372-8f0a-4297-b5ae-6235efc0cf70" />

One visible error was:

stream disconnected before completion: websocket closed by server before response.completed

After this happens, the task becomes unstable. The session may keep trying to reconnect instead of continuing smoothly, and normal work is interrupted.

Expected behavior

Codex should handle temporary network instability more robustly, especially on ordinary home networks. If a websocket or stream disconnect happens, Codex should be able to recover cleanly without repeatedly entering a reconnect loop.

At minimum, Codex should:

  • resume the task reliably after reconnecting,
  • avoid repeated reconnect loops,
  • preserve task state during reconnects,
  • provide a clearer error message when reconnect recovery fails,
  • offer a manual retry/resume option if automatic reconnect cannot recover.

Actual behavior

Codex repeatedly reconnects and may fail to continue the task normally. The user is left waiting while the app cycles through reconnect attempts, and the task becomes unreliable.

Why this matters

This is a serious reliability issue. Codex tasks are often long-running and expensive in time/tokens. If the app repeatedly reconnects on a normal home network, users cannot trust Codex to complete work reliably.

It is especially disruptive because the issue is intermittent: sometimes the same environment works normally, and sometimes Codex repeatedly reconnects. That makes the problem hard for the user to predict or avoid.

Request

Please investigate Codex Desktop's websocket/stream reconnect behavior on unstable or ordinary home-network conditions. Reconnect handling should be more resilient, and task execution should not become unusable when a temporary disconnect occurs.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #24885
  • #25103
  • #25308

Powered by Codex Action

Keesan12 · 2 months ago

The painful part here is usually not the first disconnect. It's when reconnect turns into an unbounded state machine and the user can't tell whether anything actually progressed.

A contract like this would make the failure much less expensive to live with:

  • same_failure_count so repeated websocket drops stop escalating silently
  • next_retry_allowed_at so the client can back off instead of thrashing
  • last_good_checkpoint or last_completed_step so resume is real, not optimistic
  • a terminal receipt like halt_reason=reconnect_budget_exhausted once the retry budget is spent

That gives users and parent systems something actionable: wait, resume, or stop. Without that, "Reconnecting 2/5 ... 5/5" still feels like blind hope.

We've been building MartinLoop around this exact class of control-plane problem, and the biggest win has been making retries produce receipts instead of vibes.

vab2048 · 1 month ago

This continues to happen for me on Windows - it seems to be a websocket issue (or at least is reported as one).

There are also tons of issue raised for this - they should all be consolidated into one and a workaround/fix should be deployed ASAP. It is a horrible user experience when this occurs.

andrewjiang · 28 days ago

This happens to me constantly