codex - 💡(How to fix) Fix Allow ChatGPT login users to force HTTPS/SSE transport [2 comments, 2 participants]

What happened?

I use Codex CLI with ChatGPT subscription login, not API-key billing. In my network environment, the WebSocket connection path appears to fail repeatedly before Codex eventually falls back to HTTPS/SSE. This creates a fixed delay every time the CLI starts or sends a request.

For ChatGPT subscribers, using an API key is not an acceptable workaround because it moves the user onto a separate billing path. The ChatGPT login path should provide a reliable non-WebSocket transport option.

Expected behavior

Codex should provide a user-facing configuration option to disable WebSocket transport and use HTTPS/SSE directly for ChatGPT-authenticated sessions.

For example:

[network]
transport = "https"

or:

[network]
disable_websocket = true

Additionally, if WebSocket fails once in a session or network environment, Codex should cache that failure and immediately use the fallback transport instead of retrying the same failing path several times on every attempt.

Actual behavior

Codex appears to attempt WebSocket first, retries multiple times, and only then falls back to HTTPS/SSE. I could not find a documented or discoverable way to force HTTPS-only transport.

Environment

• Codex CLI version: 0.125.0
• Auth mode: ChatGPT subscription login
• Platform: macOS arm64

codex features list reports:

responses_websockets      removed  false
responses_websockets_v2   removed  false
realtime_conversation     under development  false

codex --help does not show an option such as --transport https, --no-websocket, or an equivalent configuration key.

Why this matters

Users on networks where WebSocket is blocked or unreliable should not need to switch to API-key billing to make Codex usable. A HTTPS-only transport option would make the ChatGPT subscription path reliable in those environments and avoid repeated startup/request latency.