Codex not work in WSL

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.

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!

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)

@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?

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.

<img width="521" height="505" alt="Image" src="https://github.com/user-attachments/assets/93e2f5d7-6be1-4464-9eec-42a3af827e16" />

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. <img alt="Image" width="521" height="505" src="https://private-user-images.githubusercontent.com/213682634/528115340-93e2f5d7-6be1-4464-9eec-42a3af827e16.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjYwNjczMDcsIm5iZiI6MTc2NjA2NzAwNywicGF0aCI6Ii8yMTM2ODI2MzQvNTI4MTE1MzQwLTkzZTJmNWQ3LTZiZTEtNDQ2NC05ZWVjLTQyYTNhZjgyN2UxNi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMjE4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTIxOFQxNDEwMDdaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zYTFjNTk4ZTc5ODc4YTA3NjM5NGNlZjhlODA2NzNiNjZiYzI0ODI3ZWU0NzFmMzNkNmNlYTMzMzM0YjRhNzVjJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.A5bl9GNLCLnSQPGr_h_Q8fnJ1WLTl22rLPs_R32yyBQ">

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

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.

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.