›_ Codex Issues
Codex Issues / #30538

Windows Codex elevated sandbox repeatedly fails when Codex is launched with HTTP_PROXY/HTTPS_PROXY to localhost proxy

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

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App: 26.623.8305.0

What subscription do you have?

Plus

What platform is your computer?

  • Codex App: 26.623.8305.0 - Command runner: 0.142.3 - Windows - config.toml: [windows] sandbox = "elevated"

What issue are you seeing?

Windows Codex elevated sandbox repeatedly fails when Codex is launched with HTTP_PROXY/HTTPS_PROXY to localhost proxy

What steps can reproduce the bug?

  1. Launch Codex normally from Start Menu.
  2. Run apply_patch or shell commands: no error.
  3. Close Codex.
  4. Launch Codex via a script that sets:

HTTP_PROXY=http://127.0.0.1:7892
HTTPS_PROXY=http://127.0.0.1:7892
NO_PROXY=localhost,127.0.0.1,::1

  1. Run apply_patch or shell commands.
  2. Windows popup appears:

codex-windows-sandbox-setup.exe 找不到指定的模块

What is the expected behavior?

Codex elevated sandbox should handle localhost proxy settings without repeatedly refreshing firewall/sandbox state or launching a broken setup helper.

Additional information

Workaround:

  • Launch Codex normally without proxy script, or
  • Set [windows] sandbox = "unelevated" when using the proxy launcher.

sandbox.2026-06-29.log

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29938
  • #29178
  • #30253

Powered by Codex Action

codeOct · 1 month ago

I may be hitting a closely related issue, although my trigger is TUN mode rather than explicit HTTP_PROXY / HTTPS_PROXY environment variables.

Environment:

  • Windows
  • Codex Desktop: 26.623.13972.0
  • Command runner: 0.142.5
  • [windows] sandbox = "elevated"
  • Local proxy is enabled through TUN mode
  • A TUN adapter is active
  • The default route is taken over the TUN interface:
  • 0.0.0.0/0 -> 198.18.0.2
  • No HTTP_PROXY, HTTPS_PROXY, or NO_PROXY environment variables are set
  • Windows system proxy is disabled
  • WinHTTP proxy is direct access
  • Codex model endpoint is local:
  • base_url = "http://127.0.0.1:15721/v1"

Observed behavior:

After reboot, the first launch of Codex Desktop often asks me to configure the sandbox again. After that first launch, subsequent launches usually work normally.

This makes me suspect that the root cause may be the same class of issue as this one: elevated Windows sandbox setup/helper refresh interacting badly with local proxy/network state during startup. In my case the proxy is not injected through environment variables, but through a TUN interface that owns the default route shortly after boot.

I checked the sandbox logs, and I can see multiple setup refresh runs, usually ending with:

errors=[]
setup binary completed

Current sandbox marker also shows:

{
  "proxy_ports": [],
  "allow_local_binding": false
}

So this may not be limited to HTTP_PROXY / HTTPS_PROXY; elevated sandbox setup may also be sensitive to local TUN-mode proxy routing or startup timing after reboot.

A possible repro path:

  1. Enable a local proxy in TUN mode.
  2. Keep Codex configured with [windows] sandbox = "elevated".
  3. Reboot Windows.
  4. Launch Codex Desktop immediately after login.
  5. Observe whether Codex asks to configure sandbox again on the first launch.
  6. Relaunch Codex after the proxy/TUN route is stable and compare behavior.
codeOct · 1 month ago

I reviewed the suggested duplicates. #29938 looks like the closest related issue, but my case is not an exact duplicate: I do not have HTTP_PROXY / HTTPS_PROXY set, and my current setup_marker.json has "proxy_ports": []. The trigger appears to be TUN-mode routing plus Windows elevated sandbox startup timing after reboot, rather than an observed stored_ports / desired_ports mismatch during apply_patch.