Codex Desktop does not use the Windows system proxy for the codex process it launches inside WSL2
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:
- Codex Desktop propagates effective proxy settings into the WSL environment
- Codex running under WSL uses explicit
HTTP_PROXY/HTTPS_PROXYwhen they are manually set - Codex running under WSL falls back to Windows system proxy settings
- 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
codexlaunched 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
- Enable Windows system proxy
- Launch Codex Desktop
- Open or run a workspace through WSL2
- Let Codex Desktop launch
codexinside WSL2 - Observe that the WSL-side
codexprocess does not inherit usable proxy settings - Manually set
HTTP_PROXY/HTTPS_PROXYinside WSL - 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
codexprocess actually honors explicit proxy env vars in Desktop-managed sessions - Add logging / diagnostics for which proxy settings Codex actually sees and uses under WSL2
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗