Skip to content

Codex not work in WSL #7623

Closed
Closed
Codex not work in WSL#7623
Labels
bugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@B192186-2021
B192186-2021
opened on Dec 5, 2025

What version of Codex is running?

v0.65.0

What subscription do you have?

chatgpt plus

Which model were you using?

gpt-5.1 low

What platform is your computer?

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

What issue are you seeing?

when I say "hello" to codex, then it returns following things:

Reconnecting... 1/5
Reconnecting... 2/5
Reconnecting... 3/5
Reconnecting... 4/5
Reconnecting... 5/5
stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

tips:
I can normally chat with codex with same setting in windows powershell. While receive "Reconnecting" all the time in WSL.

What steps can reproduce the bug?

Please install Codex both on Windows and WSL. Then run codex and auth by chatgpt in Windows powershell to receive the auth.json file. Copy and paste it into .codex folder in WSL. Then run codex in WSL.

Tips:
I cannot directly auth in WSL, since it will return a error in the final step of authentication. Error msg:
Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token)

What is the expected behavior?

I wanna use codex in WSL.

Additional information

No response

Activity

  1. B192186-2021
    added
    bugSomething isn't working
    on Dec 5, 2025
  2. github-actions
    added
    CLIIssues related to the Codex CLI
    windows-osIssues related to Codex on Windows systems
    authIssues related to authentication and accounts
    on Dec 5, 2025

  3. B192186-2021 commented on Dec 5, 2025

    @B192186-2021
    B192186-2021
    on Dec 5, 2025
    Author

    Best practices for WSL(https://developers.openai.com/codex/windows/#windows-experimental-sandbox) cannot work on my PC. Maybe the key issue lies in the ChatGPT authorization process within WSL.

  4. etraut-openai
    removed
    CLIIssues related to the Codex CLI
    authIssues related to authentication and accounts
    on Dec 7, 2025

  5. etraut-openai commented on Dec 7, 2025

    @etraut-openai
    etraut-openai
    on Dec 7, 2025
    Contributor

    Please use the /feedback slash command to upload a session where you're seeing this behavior and post the thread ID here. That will help us understand the conditions that lead to this problem. Thanks!

  6. B192186-2021 commented on Dec 9, 2025

    @B192186-2021
    B192186-2021
    on Dec 9, 2025
    Author

    Please use the /feedback slash command to upload a session where you're seeing this behavior and post the thread ID here. That will help us understand the conditions that lead to this problem. Thanks!

    Hi, the issue is still reproducible, and I’ve submitted the log as you suggested.

    thread: 019b0236-2098-7562-959b-2aa95471211d

    error msg:
    stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

  7. etraut-openai commented on Dec 12, 2025

    @etraut-openai
    etraut-openai
    on Dec 12, 2025
    Contributor

    @B192186-2021, thanks for uploading the session. Unfortunately, that didn't provide much help because the failure occurs before we receive any response from the model.

    The behavior you're describing is likely because you've configured WSL to have no (or limited) networking access. Are you able to access other network locations from within WSL?

  8. pmcquain commented on Dec 18, 2025

    @pmcquain
    pmcquain
    on Dec 18, 2025

    I'm running into the same issue - works in Windows/pwsh, same error as above in WSL...

    /feedback thread id: 019b31ac-bec3-75d0-9648-f44177f1a312

    From within my WSL instance, I am able to access other external resources. In our corporate environment, there is a NetSkope VPN/proxy that is replacing the SSL cert...

    ❯ wget https://openai.com
    --2025-12-18 08:46:29-- https://openai.com/
    Resolving openai.com (openai.com)... 172.64.154.211, 104.18.33.45
    Connecting to openai.com (openai.com)|172.64.154.211|:443... connected.
    ERROR: The certificate of ‘openai.com’ is not trusted.
    ERROR: The certificate of ‘openai.com’ doesn't have a known issuer.

    Image

  9. pmcquain commented on Dec 18, 2025

    @pmcquain
    pmcquain
    on Dec 18, 2025

    I'm running into the same issue - works in Windows/pwsh, same error as above in WSL...

    /feedback thread id: 019b31ac-bec3-75d0-9648-f44177f1a312

    From within my WSL instance, I am able to access other external resources. In our corporate environment, there is a NetSkope VPN/proxy that is replacing the SSL cert...

    ❯ wget https://openai.com --2025-12-18 08:46:29-- https://openai.com/ Resolving openai.com (openai.com)... 172.64.154.211, 104.18.33.45 Connecting to openai.com (openai.com)|172.64.154.211|:443... connected. ERROR: The certificate of ‘openai.com’ is not trusted. ERROR: The certificate of ‘openai.com’ doesn't have a known issuer.

    Image

    Ok, a little more investigating and I was able to fix my issue (corp. proxy injecting SSL certs) - I installed/trusted the proxy certs in WSL's instance of Firefox as well as the system itself - sudo update-ca-certificates...

  10. etraut-openai commented on Mar 16, 2026

    @etraut-openai
    etraut-openai
    on Mar 16, 2026
    Contributor

    Closing stale issue. If you're still seeing problems with the latest version of the Codex CLI, please open a new issue and provide requested details.

  11. etraut-openai
    closed this as completedon Mar 16, 2026

  12. IsoardiMarius commented on May 7, 2026

    @IsoardiMarius
    IsoardiMarius
    on May 7, 2026

    Fix: Codex and Claude Code not working in VS Code Remote WSL when VPN is enabled

    Context

    I was using:

    • Windows host
    • WSL2
    • Ubuntu 26.04 in WSL
    • VS Code Remote WSL
    • OpenAI Codex CLI / Codex VS Code extension
    • Claude Code CLI / Claude Code VS Code extension
    • Corporate VPN enabled on Windows

    Both Codex and Claude Code worked correctly without the VPN.

    As soon as the VPN was enabled, both tools started failing inside WSL / VS Code Remote WSL.

    Symptoms

    Codex error

    Codex failed with errors like:

    MCP client for `codex_apps` failed to start
HTTP request failed:
error sending request for url (https://chatgpt.com/backend-api/wham/apps)

    The Codex conversation could not start properly.

    Claude Code error

    Claude Code failed with errors like:

    ECONNABORTED timeout
Slow first byte: no stream chunk 30.0s after request sent

    At first, it looked like an OpenAI / Anthropic / VS Code extension issue, but it was actually caused by WSL2 networking with the VPN.

    Diagnosis

    From Windows PowerShell, with the VPN enabled, the Codex endpoints were reachable:

    Invoke-WebRequest -Uri "https://chatgpt.com/backend-api/wham/apps" -Method Head -TimeoutSec 20
Invoke-WebRequest -Uri "https://chatgpt.com/backend-api/codex/responses" -Method Head -TimeoutSec 20

    Both returned:

    405 Method Not Allowed

    This 405 is expected because those endpoints expect POST, not HEAD.

    The important part is that Windows could reach the endpoints through the VPN.

    However, from WSL2, the tools were failing or timing out when the VPN was enabled.

    So the real issue was:

    Windows + VPN worked.
WSL2 + default NAT networking + VPN caused Codex / Claude Code traffic to fail.

    Root cause

    The issue was caused by the default WSL2 NAT networking mode interacting badly with the Windows VPN.

    With the VPN enabled:

    • Windows networking worked.
    • WSL2 networking was partially broken.
    • Some HTTP/TLS traffic from WSL worked.
    • Codex / Claude Code traffic failed or timed out.
    • VS Code Remote WSL was affected because the extensions and CLIs were running inside WSL.

    The problem was not Codex itself, Claude Code itself, or VS Code itself.

    The problem was the WSL2 networking mode.

    Fix

    Create or edit this Windows file:

    notepad $env:USERPROFILE\.wslconfig

    Add the following configuration:

    [wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

    Then fully restart WSL:

    wsl --shutdown
wsl

    After restarting WSL, test the Codex endpoints inside WSL:

    node -e "fetch('https://chatgpt.com/backend-api/wham/apps').then(r=>console.log(r.status)).catch(console.error)"
node -e "fetch('https://chatgpt.com/backend-api/codex/responses').then(r=>console.log(r.status)).catch(console.error)"

    Expected output:

    405
405

    Again, 405 is fine here. It proves that the endpoints are reachable from WSL.

    After enabling WSL2 mirrored networking, both Codex and Claude Code worked again with the VPN enabled.

    Codex installation note

    If codex is not installed inside WSL, install it with npm, not snap.

    Check Node and npm:

    node -v
npm -v

    Install Codex:

    sudo npm install -g @openai/codex@latest

    Verify:

    which codex
codex --version

    Then log in and test:

    codex login
codex "reply only yes"

    Avoid installing Codex with snap in this setup:

    sudo snap install codex

    In my case, installing Codex through npm worked correctly after fixing WSL networking.

    Final summary

    The issue was:

    WSL2 default NAT networking + Windows VPN caused Codex and Claude Code network requests to fail.

    The fix was to enable WSL2 mirrored networking:

    [wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

    Then restart WSL:

    wsl --shutdown

    After switching WSL2 to mirrored networking, WSL used the VPN path correctly and Codex / Claude Code worked again inside VS Code Remote WSL with the VPN enabled.

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

    bugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions