[Windows][High impact] Codex Desktop reconnects 1/5–5/5 on every prompt despite codex doctor 17 OK / 0 warn / 0 fail

What issue are you seeing?

Codex Desktop on Windows is effectively unusable: every normal prompt enters a reconnect loop (Reconnecting 1/5, 2/5, … 5/5) and no response completes.

This is reproducible while the Codex CLI diagnostics report a completely healthy installation, authentication, network path, WebSocket handshake, and provider reachability.

There was also an app startup warning:

MCP startup interrupted. The following servers were not initialized: codex_apps

The failure pattern when actually using the Desktop app is consistently: send any prompt → reconnect attempts 1/5 through 5/5 → no completed response.

This blocks normal project work entirely.

Environment

• Platform: Windows x64
• Codex CLI/Doctor version: 0.147.0 (windows-x86_64)
• Install: npm
• Terminal: Windows Terminal
• Auth: configured
• MCP: 1 server (1 stdio), 0 disabled
• Sandbox: restricted fs + restricted network, approval OnRequest

Strong diagnostic evidence

codex doctor --summary --ascii reports:

Codex Doctor v0.147.0 · windows-x86_64

Environment
[ok] system       de-DE
[ok] runtime      npm
[ok] install      consistent
[ok] search       file exists (bundled)
[ok] git          git version 2.53.0.windows.2
[ok] terminal     Windows Terminal
[ok] title        default | project Digiwiz
[ok] state        databases healthy
[ok] threads      rollout files and state DB thread inventory agree

Configuration
[ok] config       loaded
[ok] auth         auth is configured
[ok] mcp          1 server (1 stdio) · 0 disabled
[ok] sandbox      restricted fs + restricted network · approval OnRequest

Updates
[ok] updates      update configuration is locally consistent

Connectivity
[ok] network      no proxy env vars
[ok] websocket    connected (HTTP 101 Switching Protocols) · 15s timeout
[ok] reachability active provider endpoints are reachable over HTTP

Background Server
[--] app-server   not running (ephemeral mode)

17 ok | 1 idle | 0 warn | 0 fail

This makes a generic local connectivity/configuration explanation unlikely: WebSocket handshake succeeds, HTTP provider endpoints are reachable, auth is configured, installation is consistent, and there are zero doctor warnings/failures.

Steps to reproduce

1. Start Codex Desktop on Windows.
2. Open a project/thread (the problem also manifests as a general Desktop response-stream problem, not a repository task failure).
3. Send a normal prompt.
4. Observe repeated reconnect attempts:

Reconnecting 1/5
Reconnecting 2/5
Reconnecting 3/5
Reconnecting 4/5
Reconnecting 5/5

5. No response completes.
6. Run codex doctor --summary --ascii in PowerShell.
7. Observe 17 ok | 1 idle | 0 warn | 0 fail, including successful WebSocket HTTP 101 and provider reachability.

Expected behavior

A normal Desktop prompt should establish/maintain the response stream and complete normally. If the stream cannot be established despite a successful diagnostic handshake, Codex should surface the actual failing layer and an actionable diagnostic rather than looping through five reconnect attempts.

Why this is high impact

The Desktop application cannot be used for normal Codex work at all. This is not an intermittent failure in a long-running task: the reconnect loop occurs when asking ordinary questions/prompts.

The especially important contradiction is:

Doctor: 17 OK / 0 warn / 0 fail + WebSocket HTTP 101 + provider endpoints reachable

versus

Desktop: every prompt → Reconnecting 1/5–5/5 → no completed response.

Please investigate the Desktop response-stream/app-server/MCP startup path separately from basic network reachability. The codex_apps MCP startup interruption may be relevant, but causality is not yet established.

Related issue

This appears related to #37992 ([Windows] Codex Desktop repeatedly reconnects and fails with "stream disconnected before completion", while CLI works normally), but this report adds the strong codex doctor evidence showing a fully green WebSocket/network/auth/install diagnostic while Desktop remains unusable.

Start by reproducing the Windows Desktop prompt failure and run codex doctor --summary --ascii to compare the green diagnostics with the reconnect loop. Trace the Desktop response-stream, app-server, and codex_apps MCP startup path mentioned in the report, and compare it with related issue #37992. Done means identifying the failing layer and restoring completed prompt responses or providing an actionable diagnostic.