Skip to content

Windows Codex Desktop 26.616.4196.0 regression: apply_patch / fs-helper fails when global proxy env is set #29178

Open
Open
Windows Codex Desktop 26.616.4196.0 regression: apply_patch / fs-helper fails when global proxy env is set#29178
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingtool-callsIssues related to tool callingwindows-osIssues related to Codex on Windows systems

Description

@FalconIA
FalconIA
opened on Jun 20, 2026

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

26.616.4196.0 (regression observed). Rolled back to 26.611.8604.0 and the issue no longer reproduces.

What subscription do you have?

ChatGPT Pro 10x

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After upgrading Codex Desktop for Windows to 26.616.4196.0, apply_patch / fs-helper fails when Codex loads global proxy environment variables from C:\Users\<USER>\.codex\.env.

Normal sandbox shell commands can still run, but apply_patch triggers the Windows sandbox setup helper and fails.

The Windows dialog shows:

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

The specified module could not be found.

Sometimes the tool also reports:

orchestrator_helper_launch_canceled: ShellExecuteExW failed to launch setup helper: 1223

Relevant sandbox log excerpt:

START: C:\Users\<USER>\.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)

The issue is reproducible on 26.616.4196.0 and is resolved by rolling back to 26.611.8604.0, with the same proxy environment still present.

What steps can reproduce the bug?

  1. Install Codex Desktop for Windows version 26.616.4196.0.
  2. Add proxy variables to C:\Users\<USER>\.codex\.env:
HTTP_PROXY="http://127.0.0.1:7890"
HTTPS_PROXY="http://127.0.0.1:7890"
NO_PROXY="localhost,127.0.0.1,::1"
  1. Fully restart Codex Desktop.
  2. Open a local workspace with workspace-write sandbox enabled.
  3. Ask Codex to perform a small file edit that uses apply_patch, for example creating a temporary file under .tmp.
  4. Observe that normal sandbox shell commands may work, but apply_patch / fs-helper triggers the Windows sandbox setup helper and fails with the dialog:
The specified module could not be found.
  1. Roll back Codex Desktop to 26.611.8604.0.
  2. Repeat the same apply_patch operation with the same proxy env still present.
  3. The operation succeeds on 26.611.8604.0.

What is the expected behavior?

apply_patch should work on Windows even when Codex global proxy environment variables are configured, just like normal sandbox shell commands do.

The fs-helper path should keep sandbox proxy/firewall desired state consistent with the normal command-runner path, and should not launch a setup helper that fails with:

The specified module could not be found.

If this proxy configuration is unsupported, Codex should show a clear actionable error instead of failing through the Windows sandbox setup helper.

Additional information

No response

Activity

  1. FalconIA
    added
    appIssues related to the Codex desktop app
    on Jun 20, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    tool-callsIssues related to tool calling
    on Jun 20, 2026

  3. github-actions commented on Jun 20, 2026

    @github-actions
    github-actionsBot
    on Jun 20, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. LiarCoder commented on Jun 20, 2026

    @LiarCoder
    LiarCoder
    on Jun 20, 2026

    Same here!

    Image

    This waring appears after I update the Codex App to the latest version（26.616.4196.0） this morning.

    And I asked Codex how to deal with it. I tried to reboot my computer, reinstalled codex app from OpenAI official site. And I tried to repair it by Windows setting. But unfortunately, these all didn't work for me.

    Image

    Platform

    Version: Windows 10 IoT Enterprise LTSC
    Version Number: 21H2
    Installation Date: ‎2024/‎8/‎23 OS
    Internal Version: 19044.7417

  5. LiarCoder commented on Jun 20, 2026

    @LiarCoder
    LiarCoder
    on Jun 20, 2026

    @FalconIA Hey, dude, I updated the Codex to latest version just now（Version 26.616.41845 • Publishded at 2026.06.20）.
    And I let Codex check if this issue still exist, It seems disappeared.

    Image

  6. DiMY-CN commented on Jun 20, 2026

    @DiMY-CN
    DiMY-CN
    on Jun 20, 2026

    @FalconIA Hey, dude, I updated the Codex to latest version just now（Version 26.616.41845 • Publishded at 2026.06.20）.嘿，兄弟，我刚刚将法典更新到了最新版本（版本 26.616.41845，发布于 2026 年 6 月 20 日）。 And I let Codex check if this issue still exist, It seems disappeared.我让 Codex 来检查一下这个问题是否仍然存在。看起来这个问题已经消失了。

    Image

    I updated Codex as well, but the issue did not completely disappear on my machine.

    In my environment, the About page shows 26.616.41845, and the Windows App package version is 26.616.5445.0. However, with the following config:

    [windows]
sandbox = "elevated"

    apply_patch still failed with the same error:

    ShellExecuteExW failed to launch setup helper: 1223
codex-windows-sandbox-setup.exe: The specified module could not be found

    Based on the discussion in #29072 and my local testing, this does not seem to be determined by the app version alone. It appears to be related to the Windows elevated sandbox proxy/firewall state.

    On my machine, I found:

    C:\Users\<user>\.codex\.sandbox\setup_marker.json

"proxy_ports": [7897]

    And my:

    C:\Users\<user>\.codex\.env

    contains proxy settings using the same port:

    HTTP_PROXY=...:7897
HTTPS_PROXY=...:7897
ALL_PROXY=...:7897

    When proxy_ports in setup_marker.json was non-empty, apply_patch failed consistently. After backing up the file and changing it to:

    "proxy_ports": []

    apply_patch immediately started working again.

    However, if I kept using:

    [windows]
sandbox = "elevated"

    some elevated sandbox setup/sync path could write the proxy port from .codex\.env back into setup_marker.json, after which apply_patch failed again.

    As a workaround, I changed the config to:

    [windows]
sandbox = "unelevated"

    and restarted Codex. After that, even after triggering an escalated read of setup_marker.json, proxy_ports was not written back, and apply_patch could still update existing files successfully.

    So I do not think the issue is fully fixed for all environments yet. It seems to be related to this combination:

    [windows] sandbox = "elevated"
+ proxy settings in .codex\.env
+ non-empty proxy_ports in .codex\.sandbox\setup_marker.json

    If it does not reproduce for someone after updating, it may be because their proxy_ports is still empty, or because Codex has not yet triggered the elevated sandbox setup/sync path that refreshes this state.

    I think this should still be fixed on the Codex side. Switching to unelevated is only a temporary workaround, not an acceptable long-term solution, because elevated is the recommended and stronger Windows sandbox mode. Users should not have to downgrade the sandbox implementation just to keep apply_patch working when a proxy is configured.

  7. DiMY-CN commented on Jun 21, 2026

    @DiMY-CN
    DiMY-CN
    on Jun 21, 2026

    The agent commands execute normally, but pop-up windows still appear—and they appear multiple times.

    You need to empty the array of proxy_ports in 'setup
    marker.json' first, otherwise, even if you set the sandbox to 'unelevated', the pop-up error will remain unresolved.

  8. Joey9024 commented on Jun 21, 2026

    @Joey9024
    Joey9024
    on Jun 21, 2026

    @FalconIA Hey, dude, I updated the Codex to latest version just now（Version 26.616.41845 • Publishded at 2026.06.20）.嘿，兄弟，我刚刚将法典更新到了最新版本（版本 26.616.41845，发布于 2026 年 6 月 20 日）。 And I let Codex check if this issue still exist, It seems disappeared.我让 Codex 来检查一下这个问题是否仍然存在。看起来这个问题已经消失了。
    Image

    I updated Codex as well, but the issue did not completely disappear on my machine.

    In my environment, the About page shows 26.616.41845, and the Windows App package version is 26.616.5445.0. However, with the following config:

    [windows]
    sandbox = "elevated"
    apply_patch still failed with the same error:

    ShellExecuteExW failed to launch setup helper: 1223
codex-windows-sandbox-setup.exe: The specified module could not be found

    Based on the discussion in #29072 and my local testing, this does not seem to be determined by the app version alone. It appears to be related to the Windows elevated sandbox proxy/firewall state.

    On my machine, I found:

    C:\Users<user>.codex.sandbox\setup_marker.json

    "proxy_ports": [7897]
    And my:

    C:\Users\<user>\.codex\.env

    contains proxy settings using the same port:

    HTTP_PROXY=...:7897
HTTPS_PROXY=...:7897
ALL_PROXY=...:7897

    When proxy_ports 在 setup_marker.json was non-empty, apply_patch failed consistently. After backing up the file and changing it to:

    "proxy_ports": []
    apply_patch immediately started working again.

    However, if I kept using:

    [windows]
    sandbox = "elevated"
    some elevated sandbox setup/sync path could write the proxy port from .codex\.env back into setup_marker.json, after which apply_patch failed again.

    As a workaround, I changed the config to:

    [windows]
    sandbox = "unelevated"
    and restarted Codex. After that, even after triggering an escalated read of setup_marker.json， proxy_ports was not written back, and apply_patch could still update existing files successfully.

    So I do not think the issue is fully fixed for all environments yet. It seems to be related to this combination:

    [windows] sandbox = "elevated"
+ proxy settings in .codex\.env
+ non-empty proxy_ports in .codex\.sandbox\setup_marker.json

    If it does not reproduce for someone after updating, it may be because their proxy_ports is still empty, or because Codex has not yet triggered the elevated sandbox setup/sync path that refreshes this state.

    I think this should still be fixed on the Codex side. Switching to unelevated is only a temporary workaround, not an acceptable long-term solution, because elevated is the recommended and stronger Windows sandbox mode. Users should not have to downgrade the sandbox implementation just to keep apply_patch working when a proxy is configured.

    目前命令可以正常执行，但是会不断的跳弹窗。

    Image

    在命令执行成功之前还可能出现这样的提示：

    Image

    写入工具刚才被 Windows 临时取消了，我现在重试一次。

  9. TTTPOB commented on Jun 21, 2026

    @TTTPOB
    TTTPOB
    on Jun 21, 2026

    still experiencing this issue with latest version.

  10. loney123456 commented on Jun 21, 2026

    @loney123456
    loney123456
    on Jun 21, 2026

    I can reproduce what looks like the same Windows elevated sandbox/proxy oscillation issue.

    TL;DR:

    • This is not just a missing installer/file problem: the setup helper exists and is signed by OpenAI.
    • The failure is repeatedly triggered by elevated sandbox setup refreshes when proxy state differs between normal command contexts and fs-helper contexts.
    • The workaround was to switch Windows sandbox mode from elevated to unelevated; after reboot/restart, the repeated setup refreshes stopped.

    Environment:

    • Codex App: 26.616.6631.0 x64
    • Codex CLI/runtime: 0.142.0-alpha.6
    • Windows: Windows 11 10.0.26200 x64, zh-CN
    • Proxy required for Codex connectivity:
    • Initial config:
      • [windows]
      • sandbox = "elevated"

    Symptom:

    • During small file edits/apply_patch operations, Windows repeatedly shows a modal dialog from:
      ...\OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0\app\resources\codex-windows-sandbox-setup.exe
    • Dialog text in Chinese: 找不到指定的模块。
    • This blocks Codex execution until OK is clicked, and can happen several times for one small edit.

    Impact:

    • Small edits can be interrupted multiple times by a blocking Windows modal.
    • The task cannot continue until the user manually clicks OK each time.
    • This makes Codex Desktop difficult to use on Windows when a local proxy is required.

    Evidence:

    • The setup helper exists and has a valid OpenAI signature.
    • Defender Controlled Folder Access was checked and did not block Codex.
    • The sandbox log repeatedly showed:
      sandbox setup required: offline firewall settings changed (stored_ports=[10808], desired_ports=[], stored_allow_local_binding=false, desired_allow_local_binding=false)
    • Before workaround, one session had 25 setup refresh: spawning entries and 51 proxy mismatch entries.
    • This appears consistent with:
      • windows-sandbox-rs/src/setup.rs deriving proxy_ports from proxy env vars.
      • exec-server/src/fs_sandbox.rs using FS_HELPER_ENV_ALLOWLIST = ["PATH", "TMPDIR", "TMP", "TEMP"], which strips HTTP_PROXY/HTTPS_PROXY/ALL_PROXY from fs-helper launches.
    • Result: normal commands see proxy port [10808], but fs-helper contexts see no proxy, causing the elevated sandbox marker/firewall state to oscillate between [10808] and [].

    Workaround verified:

    • Changing global config to:
      [windows] sandbox = "unelevated"
    • Restarting Codex.
    • After reboot/restart and repeated create/read/apply_patch/delete tests:
      • setup refresh spawning = 0
      • proxy mismatches = 0
      • sandbox failures = 0
      • Codex doctor: 0 fail
      • 127.0.0.1:10808 still reachable/listening

    Screenshots:

    Image

    Expected:

    • Elevated Windows sandbox/fs-helper should not repeatedly re-run codex-windows-sandbox-setup.exe just because proxy env is visible in one execution context and stripped in another.
    • File edits/apply_patch should not show a blocking OS modal.

  11. loney123456 commented on Jun 21, 2026

    @loney123456
    loney123456
    on Jun 21, 2026

    使用最新版本仍然存在此问题。

    I am also using the latest version, and I just encountered this issue. I asked Codex to fix it myself

  12. a-rookie-of-C-language commented on Jun 21, 2026

    @a-rookie-of-C-language
    a-rookie-of-C-language
    on Jun 21, 2026

    I reproduced the same proxy-state mismatch locally and prepared a minimal fix branch here:

    main...a-rookie-of-C-language:fix/windows-fs-helper-proxy-env

    Root cause: codex-rs/exec-server/src/fs_sandbox.rs builds the fs-helper environment from a narrow allowlist (PATH, temp vars). On Windows elevated sandbox, that strips proxy env such as HTTP_PROXY / HTTPS_PROXY / ALL_PROXY and CODEX_NETWORK_ALLOW_LOCAL_BINDING before the fs-helper path goes through Windows sandbox setup validation. Normal command paths see the proxy port, but fs-helper sees desired_ports=[], matching the observed log:

    sandbox setup required: offline firewall settings changed (stored_ports=[...], desired_ports=[])

    The branch preserves those proxy-related env vars only on Windows for the fs-helper launch path, keeps the non-Windows helper env behavior unchanged, and adds a Windows unit test covering this propagation while still filtering secrets like OPENAI_API_KEY.

    Validation on Windows:

    cargo fmt --check
cargo test -p codex-exec-server helper_env

    Repo reject my pr because this repo only collaborators can create a pr

  13. neil1123-vip commented on Jun 22, 2026

    @neil1123-vip
    neil1123-vip
    on Jun 22, 2026

    Adding another data point from Codex Windows App 26.616.6631.0 that may help narrow the proxy/sandbox precedence issue.

    This looks like the same elevated Windows sandbox proxy-state mismatch, but with one extra twist: even after disabling Codex's network proxy feature, the running Codex App process can still drive desired_ports=[10808] from inherited process-level proxy environment variables.

    Environment:

    OS: Windows 10 Pro 25H2, build 26200.8655
Codex Windows App package: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
Windows sandbox: elevated
Workspace: Windows-native path

    Relevant config:

    [sandbox_workspace_write]
network_access = true

[windows]
sandbox = "elevated"

[features.network_proxy]
enabled = false
domains = { "*" = "allow" }

    Proxy env state after clearing User/Machine env vars:

    Scope   Name        Value
-----   ----        -----
Process HTTP_PROXY  http://127.0.0.1:10808
Process HTTPS_PROXY http://127.0.0.1:10808
Process http_proxy  http://127.0.0.1:10808
Process https_proxy http://127.0.0.1:10808

    setup_marker.json was restored to:

    "proxy_ports": []

    But the sandbox log still showed Codex trying to refresh WFP/firewall setup because the desired port list was derived as [10808]:

    [2026-06-22 09:06:07.151 codex.exe] sandbox setup required: offline firewall settings changed (stored_ports=[], desired_ports=[10808], stored_allow_local_binding=false, desired_allow_local_binding=false)
[2026-06-22 09:07:41.903 codex.exe] sandbox setup required: offline firewall settings changed (stored_ports=[], desired_ports=[10808], stored_allow_local_binding=false, desired_allow_local_binding=false)
[2026-06-22 09:10:11.989 codex.exe] sandbox setup required: offline firewall settings changed (stored_ports=[], desired_ports=[10808], stored_allow_local_binding=false, desired_allow_local_binding=false)
[2026-06-22T01:10:15.249273900+00:00] WFP setup succeeded for CodexSandboxOffline with 12 installed filters

    The setup helper was repeatedly spawned:

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

    User-visible impact:

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

    This caused repeated UAC prompts and made built-in functions.apply_patch Update/Delete fail, while Add File could still work.

    What seems notable here:

    • This reproduces even with [features.network_proxy].enabled = false.
    • User/Machine proxy env vars had already been cleared; only the already-running Codex process still had proxy env inherited from startup.
    • Restoring setup_marker.json to "proxy_ports": [] is not stable until all Codex App processes are fully restarted and stop inheriting the old proxy env.

    Expected behavior:

    If [features.network_proxy].enabled = false, the Windows sandbox probably should not derive desired_ports from inherited HTTP_PROXY / HTTPS_PROXY process env, or Codex should at least log an explicit diagnostic explaining that this process env is still taking precedence over the feature flag.

    This may be the same oscillation described above, just observed in the opposite direction:

    stored_ports=[], desired_ports=[10808]

    instead of:

    stored_ports=[10808], desired_ports=[]

  14. JJjyJJ7F3 commented on Jun 22, 2026

    @JJjyJJ7F3
    JJjyJJ7F3
    on Jun 22, 2026

    version 26.616.51431 still encoutering this bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingtool-callsIssues related to tool callingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions