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
- Launch Codex Desktop on the affected Windows environment.
- Open any existing conversation or create a new conversation.
- Send a prompt.
- Observe repeated
Reconnecting... waiting for network messages and no model response.
- Run
curl.exe -Iv https://chatgpt.com from PowerShell.
- 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.
What version of the Codex App are you using?
26.820.80927What 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:
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:443succeeds:A .NET
ClientWebSocketconnection towss://chatgpt.com/fails during TLS validation:curl.exe -Iv https://chatgpt.comfails with Schannel:curl.exe -Iv https://api.openai.comfails with:With revocation checking disabled for diagnostic purposes only:
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.comstill fails withSEC_E_UNTRUSTED_ROOT.For comparison, Schannel also reports
CRYPT_E_NO_REVOCATION_CHECKfor unrelated HTTPS sites such ashttps://www.google.com/andhttps://letsencrypt.org/, while plain HTTP access to the Let's Encrypt certificate distribution endpoint succeeds.Chrome can open
https://chatgpt.comnormally. The certificate shown in Chrome is:Windows trusted-root CTL verification also completes successfully:
Clearing the Windows URL certificate cache does not change the failure.
Steps to reproduce
Reconnecting... waiting for networkmessages and no model response.curl.exe -Iv https://chatgpt.comfrom PowerShell.SEC_E_UNTRUSTED_ROOTfrom 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:
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.