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

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

• #29127
• #29115
• #29072
• #28982
• #29089

Powered by Codex Action

Same here!

<img width="836" height="285" alt="Image" src="https://github.com/user-attachments/assets/38f33501-a968-4558-af8f-c5fdf69bddb0" />

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.

<img width="834" height="839" alt="Image" src="https://github.com/user-attachments/assets/ac37f62d-4a8f-4faa-8cbc-dc5ef704243c" />

Platform

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

@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.

<img width="1307" height="1086" alt="Image" src="https://github.com/user-attachments/assets/a5dc827d-0535-42b1-8625-38c3f6927124" />

@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 来检查一下这个问题是否仍然存在。看起来这个问题已经消失了。 <img alt="Image" width="822.4420166015625" height="683.366943359375" src="https://private-user-images.githubusercontent.com/79459348/610768117-a5dc827d-0535-42b1-8625-38c3f6927124.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODE5NjMzODgsIm5iZiI6MTc4MTk2MzA4OCwicGF0aCI6Ii83OTQ1OTM0OC82MTA3NjgxMTctYTVkYzgyN2QtMDUzNS00MmIxLTg2MjUtMzhjM2Y2OTI3MTI0LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA2MjAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNjIwVDEzNDQ0OFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWM4ZDRjZDE5YTkzNDJjYTlhN2U4OTgyYTI4Yjg5NzZhNzA2YTgzNDI2MmI2YjhmNjkwOWU1ZWVlMTIxZmViODEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.AnBiSdeP3ZmQGZY-ruPhyeLSB2V2qz_dZIFiA4-n3WU">

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.

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.

> @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 来检查一下这个问题是否仍然存在。看起来这个问题已经消失了。 > <img alt="Image" width="822.4420166015625" height="683.366943359375" src="https://private-user-images.githubusercontent.com/79459348/610768117-a5dc827d-0535-42b1-8625-38c3f6927124.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODE5NjMzODgsIm5iZiI6MTc4MTk2MzA4OCwicGF0aCI6Ii83OTQ1OTM0OC82MTA3NjgxMTctYTVkYzgyN2QtMDUzNS00MmIxLTg2MjUtMzhjM2Y2OTI3MTI0LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA2MjAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNjIwVDEzNDQ0OFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWM4ZDRjZDE5YTkzNDJjYTlhN2U4OTgyYTI4Yjg5NzZhNzA2YTgzNDI2MmI2YjhmNjkwOWU1ZWVlMTIxZmViODEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.AnBiSdeP3ZmQGZY-ruPhyeLSB2V2qz_dZIFiA4-n3WU"> 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](https://github.com/openai/codex/issues/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.

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

<img width="1245" height="411" alt="Image" src="https://github.com/user-attachments/assets/cc9944a9-f02d-406b-9cf9-d06ee7eee16f" />

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

<img width="1275" height="633" alt="Image" src="https://github.com/user-attachments/assets/16e7c27e-e3c6-45d5-a5df-33ec065cc5bf" />

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

still experiencing this issue with latest version.

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:
• HTTP_PROXY=http://127.0.0.1:10808
• HTTPS_PROXY=http://127.0.0.1:10808
• ALL_PROXY=socks5://127.0.0.1:10808
• WinINET and WinHTTP also point to 127.0.0.1:10808
• 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:

<img width="886" height="295" alt="Image" src="https://github.com/user-attachments/assets/42999596-35d5-47e4-872b-fc78f82dadf3" />

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.

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

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

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

https://github.com/openai/codex/compare/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

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=[]

version 26.616.51431 still encoutering this bug.