Codex CLI should expose a simple option to disable WebSocket transport #28503

What happened?

Codex CLI attempts WebSocket transport first. On my macOS machine, WebSocket connections appear to time out, then Codex retries several times before falling back to HTTPS.

The visible behavior is:

Reconnecting... 2/5
Request timed out

After the retry sequence, Codex falls back and continues, but every reconnect wastes time.

Environment

macOS: Tahoe 26.5.1 (25F80)
Codex CLI: 0.140.0
Install path: npm global install, @openai/codex

Network context:

scutil --proxy

shows no active HTTP/HTTPS/SOCKS proxy, only default exceptions.

However, Proton VPN is installed and macOS reports active Network Extensions:

Proton VPN Split Tunneling (experimental) [activated enabled]
Proton VPN WireGuard                      [activated enabled]

The split tunneling extension is a transparent proxy. This may be interfering with WSS/WebSocket upgrade behavior even when Proton VPN is disconnected.

Why this is a Codex UX issue

Even if a local VPN/proxy/network extension is the root cause, Codex currently makes this painful because it retries WebSocket several times before falling back to HTTPS.

The only workaround I found is defining a custom model provider:

model_provider = "openai_https"

[model_providers.openai_https]
name = "OpenAI HTTPS only"
base_url = "https://api.openai.com/v1"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

This works conceptually, but it is too obscure and cumbersome for a simple transport fallback problem.

Requested fix

Please add a simple top-level option and/or CLI flag to disable WebSockets, for example:

codex --disable-websockets

or:

transport = "https"

or:

disable_websockets = true

Codex should also consider falling back to HTTPS faster when WebSocket connection attempts time out repeatedly.

Expected behavior

Users on networks where WebSockets are blocked or broken should be able to force HTTPS without defining a custom model provider.