Codex Desktop WSL agent fails behind HTTP proxy because uppercase proxy variables become empty; .codex/.env restores connectivity

Open 💬 0 comments Opened Aug 9, 2026 by KillerQueen-dust

<html>
<body>
<html><head></head><body><h1>Codex Desktop WSL agent fails behind HTTP proxy because uppercase proxy variables become empty; <code inline="">.codex/.env</code> restores connectivity</h1><h2>Summary</h2>Codex Desktop on Windows consistently fails to complete agent requests when the agent environment is set to WSL2 and the network requires an HTTP proxy.The failure is reproducible with:<ul><li>Codex Desktop WSL agent: fails</li><li>Codex Desktop native Windows agent: works</li><li>Codex CLI launched manually inside the same WSL distribution: works</li><li>WSL <code inline="">curl</code> to the Codex backend through the same HTTP proxy: works</li><li>Codex Desktop WSL agent with proxy client TUN mode enabled: works</li></ul>Further inspection shows that the Codex Desktop-managed WSL <code inline="">app-server</code> process starts with:<pre><code class="language-text">http_proxy=http://127.0.0.1:7892
https_proxy=http://127.0.0.1:7892
HTTP_PROXY=
HTTPS_PROXY=
NO_PROXY=localhost,127.0.0.1,::1
</code></pre>Adding uppercase <code inline="">HTTP_PROXY</code> and <code inline="">HTTPS_PROXY</code> to:<pre><code class="language-text">%USERPROFILE%\.codex\.env
</code></pre>immediately restores normal Codex Desktop WSL agent operation without enabling TUN mode.This strongly suggests a proxy environment propagation / case-handling bug in the Windows Codex Desktop → WSL startup path.<hr><h2>Environment</h2><h3>Windows</h3><pre><code class="language-text">Windows 11
Codex Desktop: OpenAI.Codex_26.803.5235.0
</code></pre><h3>WSL</h3><pre><code class="language-text">Distribution: Ubuntu-24.04
WSL version: WSL2
networkingMode=mirrored
</code></pre>Codex Desktop launches the WSL app-server binary from:<pre><code class="language-text">/mnt/c/Users/.codex/bin/wsl/b5801af2ed46148d/codex
</code></pre>The app-server reports:<pre><code class="language-text">0.147.0-alpha.6.5
</code></pre><h3>Proxy</h3>The proxy client exposes an HTTP proxy at:<pre><code class="language-text">http://127.0.0.1:7892
</code></pre>Normal usage:<pre><code class="language-text">System proxy: enabled
TUN mode: disabled
</code></pre>Windows user environment variables contain lowercase proxy variables:<pre><code class="language-text">http_proxy=http://127.0.0.1:7892
https_proxy=http://127.0.0.1:7892
NO_PROXY=localhost,127.0.0.1,::1
</code></pre>There are no persistent uppercase <code inline="">HTTP_PROXY</code> or <code inline="">HTTPS_PROXY</code> user variables.<hr><h2>Symptoms</h2>When Codex Desktop is configured with:<pre><code class="language-text">Agent environment: WSL
TUN mode: OFF
</code></pre>requests repeatedly time out and eventually fail with an error similar to:<pre><code class="language-text">stream disconnected before completion:
error sending request for url
(https://chatgpt.com/backend-api/codex/responses)
</code></pre>The failure is stable and reproducible.Changing only the agent environment to native Windows restores normal operation.Enabling TUN mode also restores normal operation while keeping the agent environment set to WSL.<hr><h2>Reproduction Matrix</h2>
Configuration | Result
-- | --
Codex Desktop, native Windows agent, TUN OFF | PASS
Codex CLI manually launched inside WSL, TUN OFF | PASS
WSL curl through HTTP proxy, TUN OFF | PASS
Codex Desktop, WSL agent, TUN OFF | FAIL
Codex Desktop, WSL agent, TUN ON | PASS
Codex Desktop, WSL agent, TUN OFF + .codex/.env workaround | PASS

This appears to isolate the problem specifically to the Codex Desktop-managed WSL runtime path.<hr><h2>WSL Networking Verification</h2>From Windows PowerShell:<pre><code class="language-powershell">wsl.exe -d Ubuntu-24.04 --exec /usr/bin/env | findstr /I "PROXY"
</code></pre>Output includes:<pre><code class="language-text">http_proxy=http://127.0.0.1:7892
HTTP_PROXY=http://127.0.0.1:7892
https_proxy=http://127.0.0.1:7892
HTTPS_PROXY=http://127.0.0.1:7892
</code></pre>The non-interactive WSL environment can therefore receive proxy configuration correctly.The actual Codex backend endpoint is also reachable through the proxy:<pre><code class="language-powershell">wsl.exe -d Ubuntu-24.04 --exec curl -sv --max-time 10 https://chatgpt.com/backend-api/codex/responses -o /dev/null
</code></pre>Relevant output:<pre><code class="language-text">Uses proxy env variable https_proxy == 'http://127.0.0.1:7892'
Trying 127.0.0.1:7892...
Connected to 127.0.0.1 port 7892

CONNECT chatgpt.com:443 HTTP/1.1

HTTP/1.1 200 Connection established

TLSv1.3
SSL certificate verify ok.
ALPN: server accepted h2
using HTTP/2

GET /backend-api/codex/responses HTTP/2

HTTP/2 405
allow: POST
</code></pre>The 405 response is expected because the diagnostic request uses GET while the endpoint requires POST.This confirms that:<ul><li>WSL can reach the Windows localhost proxy</li><li>HTTP CONNECT works</li><li>TLS works</li><li>HTTP/2 works</li><li><code inline="">chatgpt.com</code> is reachable</li><li><code inline="">/backend-api/codex/responses</code> is reachable</li></ul>Therefore the failure does not appear to be caused by basic WSL networking, DNS, mirrored networking, or inability to access <code inline="">127.0.0.1:7892</code>.<hr><h2>Actual Codex Desktop WSL App-Server Environment</h2>While Codex Desktop is running with WSL as the agent environment:<pre><code class="language-bash">ps -eo pid,args | grep '[c]odex.*app-server'
</code></pre>Example:<pre><code class="language-text">1224 /mnt/c/Users/.codex/bin/wsl/b5801af2ed46148d/codex \
-c features.code_mode_host=true \
app-server \
--analytics-default-enabled
</code></pre>Inspecting the environment inherited by that actual process:<pre><code class="language-bash">tr '\0' '\n' < /proc/1224/environ \
| grep -iE '^(http|https|all|no)_proxy='
</code></pre>produces:<pre><code class="language-text">no_proxy=192.168.,172.31.,172.30.,172.2,172.19.,172.18.,172.17.,172.16.,10.,127.,*.local,localhost,...
https_proxy=http://127.0.0.1:7892
NO_PROXY=localhost,127.0.0.1,::1
HTTPS_PROXY=
HTTP_PROXY=
http_proxy=http://127.0.0.1:7892
</code></pre>The important difference is:<pre><code class="language-text">http_proxy=http://127.0.0.1:7892
https_proxy=http://127.0.0.1:7892

HTTP_PROXY=
HTTPS_PROXY=
</code></pre>This differs from the normal <code inline="">wsl.exe --exec env</code> result, where both lowercase and uppercase variants are populated.<hr><h2>Additional Inspection of the Desktop WSL Launcher</h2>Inspection of the locally installed Codex Desktop startup logic indicates that the WSL launcher explicitly adds the following names to <code inline="">WSLENV</code>:<pre><code class="language-text">HTTP_PROXY
HTTPS_PROXY
NO_PROXY
</code></pre>but does not include:<pre><code class="language-text">http_proxy
https_proxy
no_proxy
</code></pre>The Windows user environment on this system contains lowercase:<pre><code class="language-text">http_proxy
https_proxy
</code></pre>but not uppercase <code inline="">HTTP_PROXY</code> / <code inline="">HTTPS_PROXY</code>.The launcher then invokes WSL roughly through:<pre><code class="language-text">wsl.exe ... /usr/bin/bash -lc "... exec codex ... app-server"
</code></pre>I did not find code explicitly performing:<pre><code class="language-text">unset HTTP_PROXY
unset HTTPS_PROXY
</code></pre>Therefore one plausible explanation is:<pre><code class="language-text">Windows environment contains lowercase http_proxy / https_proxy
↓
Codex Desktop WSLENV explicitly refers to uppercase HTTP_PROXY / HTTPS_PROXY
↓
the WSL launch boundary introduces empty uppercase variables
↓
lowercase variables remain populated
↓
some Codex networking path does not fall back correctly from an empty
uppercase variable to the lowercase proxy variable
</code></pre>This section is a root-cause hypothesis based on the observed launcher behavior and environment state, not a confirmed internal root cause.<hr><h2>Workaround</h2>The issue is fully resolved by adding the following to:<pre><code class="language-text">C:\Users\.codex\.env
</code></pre>equivalently:<pre><code class="language-text">%USERPROFILE%\.codex\.env
</code></pre>Contents:<pre><code class="language-dotenv">HTTP_PROXY=http://127.0.0.1:7892
HTTPS_PROXY=http://127.0.0.1:7892
NO_PROXY=localhost,127.0.0.1,::1
</code></pre>After completely restarting Codex Desktop:<pre><code class="language-text">Agent environment: WSL
TUN mode: OFF
</code></pre>works normally.No changes were required to:<pre><code class="language-text">WSL networking mode
DNS configuration
proxy port
TUN mode
plugins
Codex agent permissions
</code></pre><hr><h2>Note About <code inline="">/proc/<pid>/environ</code></h2>After applying the workaround, <code inline="">/proc/<app-server-pid>/environ</code> still reports:<pre><code class="language-text">HTTP_PROXY=
HTTPS_PROXY=
</code></pre>even though Codex networking works correctly.This appears consistent with <code inline="">.codex/.env</code> being loaded by Codex after process startup and subsequently updating the process environment internally. <code inline="">/proc/<pid>/environ</code> represents the initial environment from process execution and does not necessarily reflect later environment mutations performed by the application.Therefore the unchanged <code inline="">/proc/<pid>/environ</code> output does not appear to contradict the successful <code inline="">.env</code> workaround.<hr><h2>Related App-Server Queue Symptoms</h2>Before applying the proxy workaround, Codex Desktop logs also showed repeated long-running app/plugin requests.Examples:<pre><code class="language-text">plugin/list ~30 s
plugin/installed ~31–32 s
app/read ~30 s
mcpServerStatus/list ~34 s
</code></pre>There were also queue expiration errors such as:<pre><code class="language-text">app_server_client_request_queue_rejected
inFlightRequestCount=6
method=plugin/list
queueWaitMs=30003
reason=queue-expired
</code></pre>and:<pre><code class="language-text">App server request expired while queued
</code></pre><code inline="">app/read</code> repeatedly failed with:<pre><code class="language-text">failed to read app metadata: Failed to send request
</code></pre>After restoring uppercase proxy variables through <code inline="">.codex/.env</code>, normal WSL agent conversations recovered without disabling plugins.This suggests that the plugin/app queue congestion may be downstream of failed or stalled network requests, although I have not performed a full factorial test to prove causality.<hr><h2>Expected Behavior</h2>Codex Desktop should preserve or normalize proxy settings correctly when launching its WSL app-server.In particular, a valid proxy configuration such as:<pre><code class="language-text">http_proxy=http://127.0.0.1:7892
https_proxy=http://127.0.0.1:7892
</code></pre>should allow the Desktop-managed WSL Codex runtime to behave the same way as:<pre><code class="language-text">Codex CLI launched manually inside WSL
</code></pre>and should not require:<pre><code class="language-text">TUN mode
</code></pre>or a duplicate uppercase proxy configuration in <code inline="">.codex/.env</code>.Ideally the Windows → WSL launcher should handle proxy variable names case-insensitively on the Windows side and export consistent non-empty values into the Linux environment, for example normalizing both:<pre><code class="language-text">HTTP_PROXY
HTTPS_PROXY
NO_PROXY
</code></pre>and:<pre><code class="language-text">http_proxy
https_proxy
no_proxy
</code></pre>as appropriate.<hr><h2>Actual Behavior</h2>Codex Desktop's WSL app-server starts with:<pre><code class="language-text">HTTP_PROXY=
HTTPS_PROXY=
</code></pre>despite a functioning HTTP proxy configuration being available through lowercase proxy variables.The Desktop-managed WSL agent then times out, while the same WSL environment and Codex CLI work normally.Restoring uppercase proxy variables through <code inline="">%USERPROFILE%\.codex\.env</code> resolves the issue completely.<hr><h2>Suggested Areas to Investigate</h2>Possible areas worth checking:<ol><li>Construction of <code inline="">WSLENV</code> by Codex Desktop.</li><li>Windows environment-variable case normalization before passing variables to WSL.</li><li>Behavior when <code inline="">WSLENV</code> names an uppercase variable but the Windows environment contains only the lowercase spelling.</li><li>Whether an empty <code inline="">HTTP_PROXY</code> / <code inline="">HTTPS_PROXY</code> should override a valid lowercase <code inline="">http_proxy</code> / <code inline="">https_proxy</code>.</li><li>Whether all HTTP clients used by Codex app-server, plugins, Apps, and the Responses endpoint apply proxy environment variables consistently.</li><li>Whether Desktop should explicitly normalize proxy configuration before launching the WSL runtime.</li></ol><hr><h2>Impact</h2>This can make Codex Desktop's WSL agent unusable for users whose networks require an HTTP proxy, while providing misleading symptoms that resemble:<pre><code class="language-text">WSL networking failure
DNS failure
mirrored networking failure
proxy connectivity failure
or OpenAI backend instability
</code></pre>In reality, normal WSL networking and the same proxy can be fully functional.The current practical workarounds are:<pre><code class="language-text">Enable TUN mode
</code></pre>or:<pre><code class="language-text">manually duplicate proxy variables in %USERPROFILE%\.codex\.env
</code></pre>Neither should ideally be required.<hr><h2>Assistance Disclosure</h2>This bug report was investigated interactively using local diagnostics and was organized and refined with assistance from OpenAI GPT-5.6 Sol.The diagnostic commands, observed environment values, Codex Desktop logs, reproduction matrix, and workaround were obtained from the affected machine. Root-cause statements explicitly marked as hypotheses are inferences from those observations rather than confirmed implementation details.</body></html>
</body>
</html>

View original on GitHub ↗