OpenAI network infrastructure and or bad network connection?

Codex Bugs
1

I noticed that the network connection is really unstable and often drops; the way codex handles this is to silently re-send the whole previous conversation up to the point where the turns dropped. if it’s a wss connection after a few dropped wss connection retries; it falls back to http

This might seem reasonable to open ai if they have unlimited internal compute but is this really reasonable behavior? while it keeps the conversation flowing; there’s a few problems even on cache hits

it wastes time

you’re paying for work that wasn’t delivered

i see my usage get burned then i get interrupted connection drops; not only that its wasting time!!!

any api infrastructure engineers have anything to say about dealing with this?

2

I have been following this topic since it was posted, but until now there has been little I could do beyond observe.

Today, that changed.

I asked ChatGPT to search for the closest related issue, and it identified:

If that issue describes the same problem you are experiencing, consider adding a :+1: reaction to the GitHub issue itself, rather than only reacting to this forum topic. GitHub reactions can help the maintainers gauge how many users are affected.

If it does not match your problem closely enough, search the existing Codex issues for a better match. If you cannot find one, consider opening a new issue and include as much relevant information as possible, such as your Codex version, operating system, environment, reproduction steps, expected behavior, actual behavior, and any relevant logs or error messages.

3

Adding a newer controlled observation, without assuming all reconnect errors have the same cause. On Windows desktop package26.1021.3705.0 / bundled core0.164.0-alpha.11.1, an independent localhost-only mock with dummy credentials reproduces persistent per-chat HTTP fallback:

Same app-server process WS requests, including warmup HTTP requests
ChatA, mock WS fails then HTTP succeeds 3 1
ChatA next turn, mock WS now healthy 0 1
Fresh ChatB, same process and healthy mock 2 0

All three turns completed/error=null. No real model inference, persistent settings change, or original-chat edit was involved. This verifies fallback lifetime, not the initial cause of a real TLS/server error.

Separately, actual US wired residential use showed TLS decrypt errors, invalid TLS records, WS closure before response.completed, and HTTP200 followed by response-body decode failures across multiple chats. One affected chat had only about550KB raw request bytes; fresh same-history controls worked. Reloading that inactive original chat preserved history hashes/model/provider and was followed by an explicitly associated new model WS connection and a completed real desktop minimal reply. Long-run stability remains unproven.

Detailed incremental evidence is already posted in the closest existing OpenAI Codex GitHub issue, number 53139, comment 6398542559, rather than opening duplicates. No external link is included here because new community accounts cannot post links.

Private OpenAI Support has the correlatable request IDs and has confirmed escalation to a support specialist. A later-turn bounded WS re-probe or safe history-preserving reconnect path would help. Initial network/TLS failures still require separate diagnosis; high access bandwidth does not settle client state, TLS, routing or service behavior. There is no claim of a universal fix or measured global failure-rate increase.

4

Hey @none1, is this still happening? If so, could you share which Codex client and version you’re using, along with any exact error message?

@frogjiangs, thanks for the detailed testing and for sharing what you found! Since you mentioned your private support case has already been escalated, please continue working with the Support team there and add any newer findings to that same case. Please keep sensitive logs and account details in that private request too.

Craig