Skip to content

Feature Request: Add HTTPS-only Transport Option #27381

Open
Open
Feature Request: Add HTTPS-only Transport Option#27381
Labels
CLIIssues related to the Codex CLIconnectivityIssues involving networking or endpoint connectivity problems (disconnections)enhancementNew feature or request

Description

@itqiankun
itqiankun
opened on Jun 10, 2026

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.

Activity

  1. github-actions
    added
    enhancementNew feature or request
    CLIIssues related to the Codex CLI
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Jun 10, 2026

  2. cyrusmg commented on Jun 18, 2026

    @cyrusmg
    cyrusmg
    on Jun 18, 2026

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

  3. karlicoss commented on Jun 24, 2026

    @karlicoss
    karlicoss
    on Jun 24, 2026

    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.

  4. simfor99 commented on Jun 26, 2026

    @simfor99
    simfor99
    on Jun 26, 2026

    +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.

  5. karlicoss commented on Jun 26, 2026

    @karlicoss
    karlicoss
    on Jun 26, 2026

    Follow up for this: #27381 (comment)

    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

  6. bbednarski9 commented on Sep 2, 2026

    @bbednarski9
    bbednarski9
    on Sep 2, 2026

    +1 to this issue from the gateway/proxy angle, plus offering a patch. (against Codex CLI 0.152.0)

    We route Codex through a local enterprise gateway. The only way to keep Codex's built-in openai provider - which we need, because the provider id is recoded per-thread and drives resume/picker listing - is openai-base-url. That provider is WebSocket-capable, our gateway doesn't implement the Responses WebSocket transport, so every session pays the full backoff (to HTTP) cost: ~5-7sec. Users see ERROR codex_api::endpoint::responses_websocket seven times and then a warning attributing it to OpenAI demand, which is misleading.

    Attempted Result
    [model_providers.openai] supports_websockets = false model_providers contains reserved built-in provider IDs: 'openai'
    Same via -c on the command line Identical — the guard runs on the merged config
    [features] responses_websockets = false / _v2 Accepted silently, no effect (stage removed, per #38638)
    Answering the upgrade 404 rather than 500 Still 7 attempts; only the warning text changes

    Per @karlicoss 's comment above, we can define a custom provider with supports_websockets = false and hit exactly the problem they described: threads get tagged with the custom provider id in ~/.codex/state_5.sqlite, and since selection filters on model_provider (there's an index on it), pre-existing sessions vanish from codex resume --last and the picker. Resume by explicit id still works and loads full history; it's the listing that filters.

    Therefore, the current tradeoff today is fast startup or your session history showing up, not both.

    Suggested fix

    Matching what this issue already suggests: allow model_providers.openai to override only supports_websockets and nothing else. This pattern has already been demonstrated with field-limited overide in amazon-bedrock providers for merged_configured_model_providers.

    I have this implemented and tested against tag rust-v0.152.0 and can open a PR if the shape sounds right — branch: https://github.com/bbednarski9/codex/tree/ask-b-ws-override

    • validate_openai_provider_override enforces the single-field limit, wired into both the merge path and validate_model_providers so a bad override fails at config write/load rather than during merge
    • supports_websockets becomes Option<bool> with a supports_websockets() accessor, matching the existing request_max_retries() pattern on that struct. This matters: as a plain bool with #[serde(default)], an empty or misspelled [model_providers.openai] table is indistinguishable from supports_websockets = false and would silently disable the transport
    • Tests: explicit false disables, explicit true keeps it, empty table and misspelled key leave it untouched, any other field is rejected. Verified end-to-end against a loopback listener: 0 upgrade attempts with the override, 7 without

    Notes

  7. jfscoertzen commented on Sep 17, 2026

    @jfscoertzen
    jfscoertzen
    on Sep 17, 2026
    Image This is really an annoying problem.

  8. ionescu77 commented on Sep 18, 2026

    @ionescu77
    ionescu77
    on Sep 18, 2026

    This is really annoying problem for me too. OpenAI backend is barely usable this week.

    I am considering switching back to Claude for my Nanoclaw project.

    Never had this problems with the Nanoclaw Claude SDK based transport.

  9. chenjianjx commented on Oct 1, 2026

    @chenjianjx
    chenjianjx
    on Oct 1, 2026

    This should be high priority, Sir. Lots of people have to use a proxy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIconnectivityIssues involving networking or endpoint connectivity problems (disconnections)enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions