›_ Codex Issues
Codex Issues / #15447

Codex Desktop does not use the Windows system proxy for the codex process it launches inside WSL2

Open 💬 3 comments Opened Mar 22, 2026 by AotianNeo
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

When Windows system proxy is enabled, Codex Desktop does not appear to pass that proxy configuration through to the codex process it launches inside WSL2.

In my testing, the WSL2-side codex process also did not start using the proxy path even after I manually set proxy environment variables inside WSL.

Expected behavior

If Codex Desktop launches codex inside WSL2, and Windows system proxy is enabled, the WSL-side codex process should be able to use that proxy path for outbound network access.

At minimum, I would expect one of these behaviors:

  1. Codex Desktop propagates effective proxy settings into the WSL environment
  2. Codex running under WSL uses explicit HTTP_PROXY / HTTPS_PROXY when they are manually set
  3. Codex running under WSL falls back to Windows system proxy settings
  4. This setup is clearly documented if manual WSL proxy configuration is required

Actual behavior

Windows-side browser traffic works with system proxy enabled, but the codex process launched inside WSL2 does not use that proxy automatically.

Inside WSL2, proxy env vars were empty by default:

  • HTTP_PROXY=
  • HTTPS_PROXY=
  • NO_PROXY=

I then manually set proxy env vars inside WSL to the Windows-reachable proxy address, but Codex still did not behave as expected.

Environment

  • Codex Desktop on Windows
  • codex launched inside WSL2
  • Windows system proxy enabled
  • WSL2

Concrete observation

The WSL-side process did not automatically use the Windows proxy configuration.

The Windows-reachable proxy address from WSL in my setup is:

http://172.31.224.1:7890

I also manually exported:

export HTTP_PROXY=http://172.31.224.1:7890
export HTTPS_PROXY=http://172.31.224.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

However, that still did not make the WSL-side Codex networking behave correctly.

Reproduction

  1. Enable Windows system proxy
  2. Launch Codex Desktop
  3. Open or run a workspace through WSL2
  4. Let Codex Desktop launch codex inside WSL2
  5. Observe that the WSL-side codex process does not inherit usable proxy settings
  6. Manually set HTTP_PROXY / HTTPS_PROXY inside WSL
  7. Observe that Codex still does not behave correctly

Result

codex inside WSL2 does not use the Windows system proxy automatically, and manual proxy env configuration inside WSL also does not solve the issue.

Suggested direction

  • Propagate effective Windows proxy settings into the WSL environment when launching codex
  • Verify that the WSL-side codex process actually honors explicit proxy env vars in Desktop-managed sessions
  • Add logging / diagnostics for which proxy settings Codex actually sees and uses under WSL2

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 5 months ago

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

  • #15325

Powered by Codex Action

proletariat64 · 2 months ago

I am hitting the same class of issue, and in this case the failure mode is very concrete.

Environment:

  • Windows Codex Desktop: recent Windows Store build
  • WSL distro: Ubuntu 24.04, WSL2
  • WSL CLI Codex works when launched directly from a properly configured WSL shell
  • Desktop-managed WSL app-server is launched separately by Codex Desktop

My Windows network uses a local proxy. On Windows, this kind of configuration is valid and works:

HTTP_PROXY=http://127.0.0.1:<windows-local-proxy-port>
HTTPS_PROXY=http://127.0.0.1:<windows-local-proxy-port>
NODE_EXTRA_CA_CERTS=<windows-ca-cert-path>

For WSL, the usable proxy path is different. WSL cannot use Windows 127.0.0.1 as-is; it must use a WSL-reachable Windows host/gateway address, for example:

WSL -> http://<wsl-windows-host-gateway>:<wsl-reachable-proxy-port> -> Windows proxy -> Internet

So the WSL-side environment should be something like:

HTTP_PROXY=http://<wsl-windows-host-gateway>:<wsl-reachable-proxy-port>
HTTPS_PROXY=http://<wsl-windows-host-gateway>:<wsl-reachable-proxy-port>
ALL_PROXY=http://<wsl-windows-host-gateway>:<wsl-reachable-proxy-port>
NODE_EXTRA_CA_CERTS=<wsl-ca-cert-path>
CODEX_HOME=/home/<wsl-user>/.codex

This is exactly how the WSL CLI is configured, and plain WSL CLI usage works. A direct WSL-side curl -x http://<wsl-windows-host-gateway>:<wsl-reachable-proxy-port> https://chatgpt.com/backend-api/codex/responses reaches the endpoint and returns the expected 405 Allow: POST.

The problem is Codex Desktop. When Desktop launches the WSL app-server, it appears to bypass the normal WSL shell/login environment and starts the Desktop-managed binary directly under a Windows .codex/bin/wsl/<hash>/codex app-server ... path.

The process environment I observed for that WSL app-server contained Windows-side values like:

HTTP_PROXY=http://127.0.0.1:<windows-local-proxy-port>
HTTPS_PROXY=http://127.0.0.1:<windows-local-proxy-port>
CODEX_HOME=/mnt/c/Users/<windows-user>/.codex

That is wrong for WSL:

  • 127.0.0.1 inside WSL is WSL localhost, not Windows localhost.
  • The usable WSL proxy is the WSL-reachable Windows host/gateway address.
  • Pointing WSL app-server at the Windows .codex directory also mixes Windows and Linux Codex configuration/state, which should be separate.

The visible user-facing failure is:

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

Codex Desktop logs also showed remote-control refresh failures like:

failed to refresh remote control server at https://chatgpt.com/backend-api/wham/remote/control/server/refresh: error sending request for url ...

This is very frustrating because the user can have both sides configured correctly:

  • Windows CLI works with the Windows-local proxy on 127.0.0.1
  • WSL CLI works with a WSL-reachable Windows host/gateway proxy address
  • Desktop still breaks because it carries Windows localhost proxy semantics into WSL without translation

I do not think users should have to patch Desktop-managed binaries or create fragile wrappers under .codex/bin/wsl/<hash>/codex. That file is managed by Codex Desktop and gets restored/replaced, so it is not a reliable configuration surface.

What Codex Desktop should do when launching a WSL app-server:

  1. Do not blindly pass Windows HTTP_PROXY / HTTPS_PROXY values containing 127.0.0.1 or localhost into WSL.
  2. Either translate Windows localhost proxies into a WSL-reachable gateway address, or provide an explicit config key for WSL app-server environment variables.
  3. Do not set WSL app-server CODEX_HOME to the Windows home .codex path by default. WSL should use the Linux-side home, e.g. /home/<wsl-user>/.codex, unless the user explicitly opts into sharing state.
  4. Add diagnostics showing the effective app-server env values used for proxy and CODEX_HOME, because right now the failure looks like a generic stream disconnect.

This is not a missing WSL proxy setup problem. It is a Desktop WSL launch-environment problem.

TeweiLuo · 1 month ago

You can add the environment variables to /DISK/Users/username/.codex/.env