›_ Codex Issues
Codex Issues / #27381

Feature Request: Add HTTPS-only Transport Option

Open 💬 4 comments Opened Jun 10, 2026 by itqiankun

Summary

Please add a way to force Codex to use HTTPS transport directly without attempting WebSocket connections first.

Problem

In some network environments (corporate proxies, Clash/Mihomo, VPNs, restricted networks), WebSocket connections frequently fail or time out.

Current behavior:

  1. Codex attempts WebSocket transport.
  2. Connection times out.
  3. Codex retries multiple times.
  4. Codex falls back to HTTPS.
  5. Request finally succeeds.

Example log:

Falling back from WebSockets to HTTPS transport
Reconnecting... 4/5
Request timed out

Although HTTPS works correctly, users must wait through several failed WebSocket attempts before the request is processed.

Expected Behavior

Allow users to explicitly disable WebSocket transport.

Examples:

codex --transport=https

or

transport = "https"

or

supports_websockets = false

Benefits

  • Faster startup in restricted network environments.
  • Better compatibility with enterprise proxies.
  • Reduced connection delays.
  • More predictable behavior.

Environment

  • Codex CLI: v0.139.0
  • Platform: macOS
  • Network: Proxy / Clash environment
  • HTTPS works correctly after WebSocket fallback.

View original on GitHub ↗

4 Comments

cyrusmg · 2 months ago

This also happens on my Hetzner VM. Having a way to disable websockets transport would be great.

karlicoss · 2 months ago

I'm getting random Codex freezes for 4 minutes when it's not doing anything after a prompt.
After some debugging seems like it's caused by websockets somehow, i.e. with this bit of config I never have freezes.

model_provider = "chatgpt-http"

[model_providers.chatgpt-http]
name = "ChatGPT HTTP"
base_url = "https://chatgpt.com/backend-api/codex"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false
stream_idle_timeout_ms = 60000
stream_max_retries = 5
##

However the problem is that it messes with codex resume TUI -- it doesn't display my previous sessions, seems like sessions are tied to a model_provider. Even though you can resume explicitly by session id and it works fine with new provider.
Would be great to have an option to disable websockets.

simfor99 · 2 months ago

+1 for an official HTTPS/SSE-only transport option.

Concrete data point from a recent Codex CLI session:

  • Codex CLI 0.142.2
  • WSL2 Ubuntu via Windows Terminal
  • Built-in OpenAI provider / ChatGPT auth, model gpt-5.5, high reasoning
  • No explicit HTTP_PROXY / HTTPS_PROXY env vars in the shell when inspected

In this setup, the WebSocket path intermittently fails with:

stream disconnected before completion: failed to send websocket request: IO error: Broken pipe (os error 32)

The important part: HTTP/SSE fallback succeeds, but only after the TUI spends several minutes on Reconnecting... 5/5. In one affected high-context session, the turn had ~4m56s time to first token and ~6m27s full duration. The local transcript was about 623 MB / 12,050 JSONL lines, with roughly 222k input tokens against a 258,400 context window.

For that kind of session, the retry budget is a very expensive tax on every affected turn. We would use a built-in option immediately, for example:

  • codex --transport=https
  • transport = "https" in config
  • or supports_websockets = false for the built-in OpenAI provider

The custom-provider workaround is not a great fit when the existing setup uses the built-in OpenAI provider / ChatGPT auth and shared project config. A first-class HTTPS-only switch would make Codex much more usable in environments where WebSockets are flaky but HTTPS/SSE works reliably.

karlicoss · 2 months ago

Follow up for this: https://github.com/openai/codex/issues/27381#issuecomment-4784643955

After some debugging, seemed like the problem was with ipv6 specifically for some reason. I solved that by pinning ipv4 addresses in /etc/hosts.

104.18.32.47 chatgpt.com
172.64.155.209 chatgpt.com