Windows apply_patch fs-helper repeatedly launches sandbox setup when proxy ports differ from setup marker

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

Summary

On Windows Codex Desktop, apply_patch / fs-helper can repeatedly fail and show a Windows error dialog from codex-windows-sandbox-setup.exe when sandbox networking uses a local proxy.

The failure appears to be caused by the normal command-runner sandbox setup and the fs-helper computing different desired offline firewall proxy ports:

stored_ports=[7890], desired_ports=[]
stored_allow_local_binding=false, desired_allow_local_binding=false

When this mismatch is detected, the fs-helper tries to launch the sandbox setup helper. That launch fails with ShellExecuteExW error 1223, and Windows shows a dialog for codex-windows-sandbox-setup.exe saying the specified module cannot be found.

Environment

  • OS: Windows 11, zh-CN locale
  • Codex Desktop app: OpenAI.Codex_26.616.3767.0_x64__2p2nqsd0c76g0
  • Codex CLI/runtime reported by doctor: 0.142.0-alpha.1
  • Sandbox mode: workspace-write / restricted filesystem
  • Approval mode: auto approval / "approve for me"
  • Sandbox network: enabled
  • Network proxy required for this host to reach OpenAI services:
  • HTTP_PROXY=http://127.0.0.1:7890
  • HTTPS_PROXY=http://127.0.0.1:7890
  • ALL_PROXY=http://127.0.0.1:7890
  • setup_marker.json records:
{
  "version": 5,
  "offline_username": "CodexSandboxOffline",
  "online_username": "CodexSandboxOnline",
  "proxy_ports": [7890],
  "allow_local_binding": false,
  "read_roots": [],
  "write_roots": []
}

Symptoms

apply_patch fails with:

apply_patch verification failed: Failed to read file to update ...
fs sandbox helper failed with status exit code: 1:
windows sandbox failed:
orchestrator_helper_launch_canceled:
ShellExecuteExW failed to launch setup helper: 1223

Windows also displays a dialog for:

C:\Program Files\WindowsApps\OpenAI.Codex_26.616.3767.0_x64__2p2nqsd0c76g0\app\resources\codex-windows-sandbox-setup.exe

with Chinese text equivalent to "The specified module could not be found."

Relevant sandbox log excerpts

Normal command-runner path works and can launch setup helper:

setup refresh: spawning C:\Program Files\WindowsApps\OpenAI.Codex_26.616.3767.0_x64__2p2nqsd0c76g0\app\resources\codex-windows-sandbox-setup.exe (... payload_len=4024)
setup refresh: processed 3 write roots (read roots delegated); errors=[]

But the fs-helper path used by apply_patch computes empty desired proxy ports:

START: C:\Users\...\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
sandbox setup required: offline firewall settings changed (stored_ports=[7890], desired_ports=[], stored_allow_local_binding=false, desired_allow_local_binding=false)

This has recurred across restarts. Examples from the logs:

[2026-06-24 13:32:39.097 codex.exe] START: C:\Users\ASUS\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-06-24 13:32:39.120 codex.exe] sandbox setup required: offline firewall settings changed (stored_ports=[7890], desired_ports=[], stored_allow_local_binding=false, desired_allow_local_binding=false)

[2026-06-25 09:07:09.459 codex.exe] START: C:\Users\ASUS\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-06-25 09:07:09.478 codex.exe] sandbox setup required: offline firewall settings changed (stored_ports=[7890], desired_ports=[], stored_allow_local_binding=false, desired_allow_local_binding=false)

[2026-06-25 09:09:03.659 codex.exe] START: C:\Users\ASUS\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
[2026-06-25 09:09:03.682 codex.exe] sandbox setup required: offline firewall settings changed (stored_ports=[7890], desired_ports=[], stored_allow_local_binding=false, desired_allow_local_binding=false)

Reproduction pattern

  1. Use Windows Codex Desktop with workspace-write sandbox.
  2. Enable sandbox network access on a host that needs a local proxy to reach OpenAI services.
  3. Configure/inherit proxy env vars such as HTTP_PROXY=http://127.0.0.1:7890.
  4. Let normal sandbox command execution run; setup marker records proxy_ports: [7890].
  5. Trigger apply_patch on any workspace file.
  6. apply_patch invokes codex.exe --codex-run-as-fs-helper.
  7. The fs-helper computes desired_ports=[], detects mismatch with marker [7890], attempts setup refresh, and fails with ShellExecuteExW failed to launch setup helper: 1223 plus a Windows dialog.

Expected behavior

The fs-helper should use the same proxy-port computation/configuration as the normal command-runner sandbox path, or should otherwise avoid launching setup refresh from the fs-helper when the mismatch is only due to proxy port propagation.

apply_patch should work under workspace-write sandbox with network proxy enabled.

Actual behavior

Normal sandbox commands work, but apply_patch fails because the fs-helper sees a proxy-port mismatch and cannot successfully launch codex-windows-sandbox-setup.exe.

Workarounds tested

The following did not permanently fix it:

  • Restarting Codex Desktop.
  • Adding [network] proxy_url = 'http://127.0.0.1:7890' to config.toml.
  • Adding [shell_environment_policy] inherit = "all".
  • Setting user-level HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY.
  • Setting WinHTTP proxy to 127.0.0.1:7890.
  • Replacing .codex\.sandbox-bin\codex.exe with a wrapper. Codex refreshes this file back from its internal cache/source.

A temporary workaround that proves the mismatch is the trigger:

  • Continuously rewriting .codex\.sandbox\setup_marker.json so proxy_ports is [] allows apply_patch to succeed.
  • After that, logs show fs-helper starts without the desired_ports mismatch line.

This is not a safe or acceptable long-term workaround, but it strongly suggests the bug is in fs-helper proxy port propagation/state comparison.

Additional notes

I searched for public reports using exact strings such as codex-windows-sandbox-setup.exe, orchestrator_helper_launch_canceled, ShellExecuteExW failed to launch setup helper, codex-run-as-fs-helper, and stored_ports desired_ports, but did not find an existing public issue.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29178
  • #29771
  • #29200

Powered by Codex Action

zaijiayoujiayou-bot · 1 month ago

This Windows sandbox proxy regression is still not fixed in the current Desktop build.

Environment:

  • OpenAI.Codex: 26.623.11225.0
  • codex-cli: 0.142.5
  • Windows
  • Local proxy: 127.0.0.1:7897
  • sandbox marker contains proxy_ports=[7897]

The same failure still reproduces with apply_patch:

fs sandbox helper failed
windows sandbox failed
orchestrator_helper_launch_canceled
ShellExecuteExW failed to launch setup helper: 1223

The sandbox log still shows:

sandbox setup required: offline firewall settings changed
stored_ports=[7897], desired_ports=[]

This appears to be the exact issue described in #29671 / #29938, but the fix does not seem to be included in the current Windows Desktop release. The app keeps launching codex-windows-sandbox-setup.exe during normal file edits, which causes repeated dialogs and breaks normal coding workflows.

Please prioritize shipping the preserve-proxy-settings fix to the Windows Desktop build. This is not a cosmetic issue; it makes normal code editing unreliable for users behind local proxies.

zaijiayoujiayou-bot · 1 month ago

Quick follow-up: this is still reproducible after the latest Desktop update.

Current environment:

  • OpenAI.Codex: 26.623.13972.0
  • codex-cli: 0.142.5
  • Windows
  • Local proxy: 127.0.0.1:7897
  • sandbox marker still contains proxy_ports=[7897]

apply_patch still fails with:

fs sandbox helper failed
windows sandbox failed
orchestrator_helper_launch_canceled
ShellExecuteExW failed to launch setup helper: 1223

The sandbox log still shows the same proxy mismatch:

sandbox setup required: offline firewall settings changed
stored_ports=[7897], desired_ports=[]

It looks like the Desktop package was updated, but the backend is still codex-cli 0.142.5, and the preserve-proxy-settings fix still does not appear to be included.

Could someone from the team confirm whether #29671 is expected to ship in a future Windows Desktop build? This issue still breaks normal file-editing workflows for users behind local proxies.

dobe233 · 1 month ago

I can reproduce the same issue on a newer Codex Windows build.

Environment

  • Codex App package: OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0
  • command runner: codex-command-runner-0.142.5.exe
  • OS: Windows 11, zh-CN locale
  • sandbox mode: workspace-write
  • Windows sandbox config: [windows] sandbox = "elevated"
  • local proxy process listening on 127.0.0.1:6789
  • Codex shell environment contains:
HTTP_PROXY=http://127.0.0.1:6789
HTTPS_PROXY=http://127.0.0.1:6789
ALL_PROXY=http://127.0.0.1:6789
NO_PROXY=localhost,127.0.0.1,::1

Minimal reproduction

In a Codex Desktop Windows thread:

*** Begin Patch
*** Add File: work/apply_patch_repro_probe.txt
+probe
*** End Patch

This succeeds.

Then:

*** Begin Patch
*** Delete File: work/apply_patch_repro_probe.txt
*** End Patch

This fails with:

apply_patch verification failed:
Failed to read ...\work\apply_patch_repro_probe.txt:
fs sandbox helper failed with status exit code: 1:
windows sandbox failed:
orchestrator_helper_launch_canceled:
ShellExecuteExW failed to launch setup helper: 1223

Relevant sandbox state

setup_marker.json is generated with:

"proxy_ports": [6789]

But each apply_patch fs-helper attempt logs:

START: ...\.codex\.sandbox-bin\codex.exe --codex-run-as-fs-helper
sandbox setup required: offline firewall settings changed (stored_ports=[6789], desired_ports=[], stored_allow_local_binding=false, desired_allow_local_binding=false)

Additional checks

  • Removing computer-use@openai-bundled and restarting did not fix the issue.
  • Deleting .codex/.sandbox/setup_marker.json and restarting did not fix it. The marker is regenerated with proxy_ports: [6789] because the shell environment still has the proxy vars.
  • Windows user environment (HKCU\Environment) does not contain these proxy variables.
  • WinHTTP proxy is direct/no proxy.
  • The issue is not project-specific; it reproduces with a temporary probe file under work/.

This still looks like the normal command-runner sandbox setup and the apply_patch fs-helper compute different desired proxy ports: normal shell setup records [6789], while fs-helper wants [], then tries to launch the elevated setup helper and fails with ShellExecuteExW ... 1223.

Showing cached comments. Read the full discussion on GitHub ↗