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

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 ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗