Skip to content

Unable to disable WebSocket transport #13103

Closed

Description

@hanx-hep

Description

I am encountering an issue where configuring:

supports_websockets = false

in config.toml does not take effect.

Specifically, the model_providers.openai provider appears to be immutable or internally defined in a way that prevents overriding transport capabilities. As a result, Codex CLI continues attempting to establish WebSocket connections even when explicitly disabled in configuration.


Observed Behavior

  • Codex CLI attempts WebSocket transport by default.
  • Even after setting supports_websockets = false, WebSocket connections are still attempted.
  • There appears to be no reliable way to force HTTPS-only transport via configuration.

Expected Behavior

One of the following should be possible:

  1. supports_websockets = false should correctly disable WebSocket usage for model_providers.openai, or
  2. A CLI flag should exist to explicitly force HTTPS transport as the preferred (or exclusive) transport method.

For example:

codex --transport https

or

codex --prefer-https

Environment

  • OS: Linux
  • Codex CLI version: 0.106.0
  • Network: Proxy environment (HTTP / SOCKS / Reality-based proxy)
  • Issue reproducible: Yes

Activity

  1. added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    on Feb 28, 2026
  2. github-actions commented on Feb 28, 2026

    @github-actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. etraut-openai commented on Feb 28, 2026

    @etraut-openai
    Contributor

    Can you describe the behavior that you're seeing that's causing you to want to disable websocket transport? The feature flag was in place for development, but we typically remove feature flags once features are rolled out and stable.

  4. hanx-hep commented on Feb 28, 2026

    @hanx-hep
    Author

    Can you describe the behavior that you're seeing that's causing you to want to disable websocket transport? The feature flag was in place for development, but we typically remove feature flags once features are rolled out and stable.

    Hi, Currently, I am running codex in an internal network environment (at a research institute's computing node), so I used a proxy. It worked normally before version v0.106.0, but after upgrading to that version, it started to encounter

    {"type":"thread.started","thread_id":"xxx"}
    {"type":"item.completed","item":{"id":"item_0","type":"error","message":"Under-development features enabled: realtime_conversation, responses_websockets_v2, voice_transcription. Under-development features are incomplete and may behave unpredictably. To suppress this warning, set `suppress_unstable_features_warning = true` in /home/xxx/.codex/config.toml."}}
    {"type":"turn.started"}
    {"type":"error","message":"Reconnecting... 2/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)"}
    {"type":"error","message":"Reconnecting... 3/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)"}
    {"type":"error","message":"Reconnecting... 4/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)"}
    {"type":"error","message":"Reconnecting... 5/5 (stream disconnected before completion: failed to send websocket request: Connection closed normally)"}
    {"type":"item.completed","item":{"id":"item_1","type":"error","message":"Falling back from WebSockets to HTTPS transport. stream disconnected before completion: failed to send websocket request: Connection closed normally"}}
    

    This is similar to #13041

    I'm not sure if the issue is with the proxy I'm using (I tried both socks and http), or a bug in this version itself, so I want to disable it first.

  5. hanx-hep commented on Feb 28, 2026

    @hanx-hep
    Author

    Hi, I just tried again without using a proxy, on a completely new virtual machine, and the same error still occurs.

    Thread ID 019ca306-15e2-7dc0-8951-198b7e6d1616

  6. kali113 commented on Feb 28, 2026

    @kali113

    @hanx-hep if you want, you can close this one and talk in #13041

  7. hanx-hep commented on Feb 28, 2026

    @hanx-hep
    Author

    @hanx-hep if you want, you can close this one and talk in #13041

    @kali113 My issue is a bit different; I hope to provide an option to modify whether to use WS. Therefore, this might still be kept?

  8. kali113 commented on Feb 28, 2026

    @kali113

    @hanx-hep can you do codex features list in cli

  9. user753 commented on Feb 28, 2026

    @user753

    I have the same problem and also would like to disable websocket

  10. AdiRishi commented on Feb 28, 2026

    @AdiRishi

    I am also running into this. Afaik this was the timeline of events for me
    I tried to turn on the responses_websockets_v2 feature via ~/.codex/config.toml. This did not work, both on the Codex app + CLI (both at the latest versions as of today) I saw

    Reconnecting 1..2..3..4..5
    stream disconnected before completion: failed to send websocket request: Connection closed normally
    

    I then went back to the config file and commented out the responses_websockets_v2 feature.
    However, this was never turned off, even today after a hard close + refersh of the apps, terminal and system it still seems to be using the websocket setting.

  11. Weaverzhu commented on Feb 28, 2026

    @Weaverzhu

    Can you describe the behavior that you're seeing that's causing you to want to disable websocket transport? The feature flag was in place for development, but we typically remove feature flags once features are rolled out and stable.

    In 100% cases I met websocket error and fallback to https (with about 1min wasted). I would like to disable websocket for convenience.

  12. kali113 commented on Feb 28, 2026

    @kali113
  13. takina0802 commented on Mar 18, 2026

    @takina0802

    Hi, I found a solution in #13041: #13041 (comment).

    Add the following configuration in ~/.codex/config.toml:

      model_provider = "openai_http"
    
      [model_providers.openai_http]
      name = "OpenAI HTTP only"
      wire_api = "responses"
      requires_openai_auth = true
      supports_websockets = false
      base_url = "https://chatgpt.com/backend-api/codex"
  14. hanx-hep commented on Mar 18, 2026

    @hanx-hep
    Author

    Hi, I found a solution in #13041: #13041 (comment).

    Add the following configuration in ~/.codex/config.toml:

    model_provider = "openai_http"

    [model_providers.openai_http]
    name = "OpenAI HTTP only"
    wire_api = "responses"
    requires_openai_auth = true
    supports_websockets = false
    base_url = "https://chatgpt.com/backend-api/codex"

    Hello, indeed this method can be used, but this provider may not fully inherit all the features of the official codex provider.

    However, it seems that the wss bug in version v0.106.0 has been fixed in subsequent updates, so at least I don't need this requirement anymore.

  15. Somebi commented on Aug 5, 2026

    @Somebi

    So how this was eventually solved?

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 CLIbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions