Windows Codex stuck on “Reconnecting... waiting for network” when Schannel certificate validation fails

What version of the Codex App are you using?

26.820.80927

What platform are you using?

Windows x64, enterprise/public-sector network environment.

What issue are you seeing?

Codex Desktop cannot start or continue any conversation. Every prompt immediately enters a reconnect loop:

Reconnecting... waiting for network
Reconnecting... waiting for network
...

This reproduces in existing and brand-new conversations, and persists after a full Windows reboot. The app is on the latest available version.

The key diagnostic finding is that the underlying Windows Schannel/TLS certificate validation is failing. Codex only surfaces the generic reconnect message, which makes the root cause difficult to identify.

Diagnostics

TCP connectivity to chatgpt.com:443 succeeds:

Test-NetConnection chatgpt.com -Port 443
TcpTestSucceeded : True

A .NET ClientWebSocket connection to wss://chatgpt.com/ fails during TLS validation:

System.Net.WebSockets.WebSocketException: Unable to connect to the remote server
System.Security.Authentication.AuthenticationException:
The remote certificate is invalid according to the validation procedure.

curl.exe -Iv https://chatgpt.com fails with Schannel:

schannel: SEC_E_UNTRUSTED_ROOT (0x80090325)
The certificate chain was issued by an authority that is not trusted.

curl.exe -Iv https://api.openai.com fails with:

CRYPT_E_NO_REVOCATION_CHECK (0x80092012)
The revocation function was unable to check revocation for the certificate.

With revocation checking disabled for diagnostic purposes only:

curl.exe -Iv --ssl-no-revoke https://api.openai.com

TLS succeeds and the server returns an HTTP response (421 Misdirected Request), confirming that the network path to the OpenAI endpoint itself is reachable.

However, even with --ssl-no-revoke, https://chatgpt.com still fails with SEC_E_UNTRUSTED_ROOT.

For comparison, Schannel also reports CRYPT_E_NO_REVOCATION_CHECK for unrelated HTTPS sites such as https://www.google.com/ and https://letsencrypt.org/, while plain HTTP access to the Let's Encrypt certificate distribution endpoint succeeds.

Chrome can open https://chatgpt.com normally. The certificate shown in Chrome is:

Subject CN: chatgpt.com
Issuer CN: YE2
Issuer O: Let's Encrypt

Windows trusted-root CTL verification also completes successfully:

certutil -verifyCTL AuthRootWU
CertUtil: -verifyCTL command completed successfully.

Clearing the Windows URL certificate cache does not change the failure.

Steps to reproduce

1. Launch Codex Desktop on the affected Windows environment.
2. Open any existing conversation or create a new conversation.
3. Send a prompt.
4. Observe repeated Reconnecting... waiting for network messages and no model response.
5. Run curl.exe -Iv https://chatgpt.com from PowerShell.
6. Observe SEC_E_UNTRUSTED_ROOT from Schannel.

Expected behavior

If the Windows TLS stack cannot validate the certificate required for Codex transport, Codex should ideally surface an actionable TLS/certificate diagnostic instead of only showing a generic reconnect loop.

For example, indicating that the WebSocket/TLS handshake failed due to certificate trust or revocation validation would make enterprise-network troubleshooting much easier.

Actual behavior

The UI repeatedly reports only:

Reconnecting... waiting for network

There is no visible indication that the failure is occurring during TLS certificate validation.

Additional information

This may ultimately be caused by the Windows/enterprise certificate-validation environment rather than Codex itself. The Codex-specific problem being reported is that the Desktop app becomes unusable and exposes only a generic reconnect message despite a reproducible Schannel certificate-validation failure underneath.

No organization identifiers, internal IP addresses, usernames, credentials, or local paths are included in this report.

Start by reproducing the reconnect loop on the affected Windows environment and tracing the Codex Desktop WebSocket/TLS connection failure. Identify where Schannel certificate or revocation errors are reduced to the generic reconnect message; done means the UI surfaces an actionable certificate-validation diagnostic while preserving normal reconnect behavior.