Windows Desktop: codex-windows-sandbox-setup.exe dialog appears on apply_patch after 26.616 update

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

• #29127
• #29115
• #29072
• #28982
• #29178

Powered by Codex Action

• Exactly the same as this issue: #29178
• Try to update the codex, It seems to be fixed.

Update after retesting on a newer Codex Desktop build:

• Codex Desktop AppX package: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
• BROWSER_USE_CODEX_APP_VERSION: 26.616.51431
• Config remains [windows] sandbox = "elevated"
• .sandbox-bin contains codex-command-runner-0.142.0-alpha.6.exe and codex.exe

Result: the issue still reproduces. A minimal apply_patch add-file operation reports success and creates the file, but Windows still shows the codex-windows-sandbox-setup.exe modal error dialog. The temp file was then removed with PowerShell to avoid triggering apply_patch again.

So the update to AppX 26.616.6631.0 did not resolve the Windows sandbox helper dialog issue.

Additional verification:

I tested whether the issue was caused by stale local sandbox marker state.

Before the test, %USERPROFILE%\.codex\.sandbox\setup_marker.json still contained:

"proxy_ports": [10808, 10809]

while the current sandbox log repeatedly reported:

sandbox setup required: offline firewall settings changed (stored_ports=[10808, 10809], desired_ports=[], stored_allow_local_binding=false, desired_allow_local_binding=false)

I backed up the marker and changed proxy_ports to an empty array, then stopped the current codex-command-runner process so the next operation would start fresh.

Result: a minimal apply_patch add-file operation still reported success but still produced the same Windows modal dialog:

C:\Program Files\WindowsApps\OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0\app\resources\codex-windows-sandbox-setup.exe
找不到指定的模块。

So the issue is not resolved by clearing stale proxy_ports in setup_marker.json; it still appears to be specific to the apply_patch / filesystem-helper path launching the WindowsApps sandbox setup helper.

Impact update / priority request:

This is a hard blocker for continuing real coding work in Codex Desktop on Windows.

The affected workflow is not optional for this project: apply_patch is the required safe edit path used for code changes. Since every apply_patch invocation triggers a modal Windows error dialog from codex-windows-sandbox-setup.exe, continuing development causes repeated OS-level popups and makes the editing workflow impractical.

Current practical impact:

• Safe code editing in Codex Desktop is blocked.
• We have paused ongoing Unity/C# project optimization work because using apply_patch repeatedly triggers the dialog.
• Build and normal shell commands appear healthy; the blocker is specifically the filesystem edit/helper path.
• The issue persists after update/reinstall/restart/AppX re-registration/sandbox cache reset/marker cleanup.

Request: please treat this as high priority / blocker for Windows Desktop users affected by this sandbox helper regression.

Follow-up after trying the workaround suggested in #29178:

I applied the workaround:

1. Set config to:

[windows]
sandbox = "unelevated"

1. Cleared %USERPROFILE%\.codex\.sandbox\setup_marker.json so that:

"proxy_ports": []

1. Restarted Codex Desktop.

Result:

• The modal codex-windows-sandbox-setup.exe dialog no longer appears.
• apply_patch can add a new file successfully.
• However, apply_patch still cannot update or delete existing files.

Both update and delete operations fail with:

failed to prepare fs sandbox: failed to prepare windows sandbox wrapper: windows unelevated restricted-token sandbox cannot enforce split writable root sets directly; refusing to run unsandboxed

So the workaround avoids the modal dialog, but it does not restore usable code-editing functionality for this Desktop workspace because the session has split/multiple writable roots. This still blocks normal safe code editing: most real edits require updating existing files, not only adding new files.

Current state:

• elevated: supports this workspace shape but triggers the WindowsApps sandbox setup modal dialog.
• unelevated: avoids the modal dialog, but cannot handle the current split writable root setup and fails on update/delete patch operations.

This means there is currently no working Windows Desktop sandbox mode for safe apply_patch editing in this environment.

@codex Same here. Quite annoying. Please fix this bug.

I'm seeing the same issue. :/

same issue

please treat this as high priority / blocker for Windows Desktop users affected by this sandbox helper regression.

same

For the same problem, I found a possible solution:

1. I asked Codex test the usability of codex-windows-sandbox-setup.exe, and the report results were normal, but a special prompt called administrator privileges was required;
2. In the work conversation, I explicitly asked that codex call the codex-windows-sandbox-setup.exe with administrator privileges. Codex prompted, "Administrator call has been approved, but WindowsApps still directly refuses to execute (error code 5), which corresponds exactly to the directory restriction you were reminded about. Next, I will first verify the OpenAI digital signature, then copy it to a regular temporary directory and run the same verified program; The content of the request remains unchanged. " and " The copied program has passed signature check and started successfully, but the current boost channel has not obtained the real administrator token, so creating a local group still reports code 5. The final feasible step is to trigger the Windows UAC's "Run as administrator" dialog box; Please confirm in the pop-up that I will wait for the process exit code. "
3. After manually agreeing, codex runs normally without errors.
4. It seems you have to prompt codex "All calls to codex-windows-sandbox-setup.exe require administrator privileges" for it to work properly, which seems to be a permission issue.

I can still reproduce this on a newer Windows Desktop package:

• OS: Windows x64, zh-CN locale
• Codex Desktop AppX package observed in the error path: OpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0
• Approx. local time observed: 2026-06-23 afternoon, Asia/Shanghai
• Error dialog target: codex-windows-sandbox-setup.exe
• Dialog text: 找不到指定的模块。
• English meaning: The specified module could not be found.

The same class of failure appears when Codex tries to use the Windows filesystem sandbox/helper path. I have also seen the related structured error:

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

I checked Windows Security / Protection history and did not find any Codex/OpenAI/codex-windows-sandbox-setup.exe quarantine or block entry. The only recent item shown there was a OneDrive ransomware-protection recovery suggestion, so this does not look like a Defender quarantine case on my machine.

This started after the recent 26.616 update series and still reproduces on 26.616.9593.0, which is newer than several reports already listed here. That suggests the Windows sandbox setup/helper regression is not fully fixed in this build.

This looks related to #29072 as well: the helper exists under the WindowsApps package path, but the failure seems to occur when Codex launches it from the packaged WindowsApps/AppContainer context.

Paid-user impact escalation:

The affected user is a ChatGPT Plus paid user and this issue is blocking the main value they use Codex Desktop for: safe code editing on a real Unity/C# project.

This is not a cosmetic popup only. In practice:

• elevated mode triggers the WindowsApps codex-windows-sandbox-setup.exe modal dialog / helper launch failure.
• The #29178 workaround (sandbox = "unelevated" + proxy_ports = []) avoids the modal dialog, but apply_patch update/delete operations fail with the split writable root error.
• Administrator launch with elevated does not resolve it; the same modal/helper error returns.
• The user has effectively paused all code optimization and feature development because apply_patch is the required safe edit path.

This makes Codex Desktop unusable for the user's paid monthly development workflow on Windows. Please prioritize either a fix or an official safe workaround for Windows Desktop users affected by this regression.

Still reproduces on OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0.

Current reproduction result

Inside Codex Desktop on Windows, using apply_patch:

• Add File succeeds.
• Update File fails.
• A Windows modal dialog appears multiple times for:

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

Dialog text:

找不到指定的模块。

English meaning: The specified module could not be found.

Tool error after the dialog:

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

Local verification of the setup helper

I also checked the setup helper directly.

Resolved path:

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

Findings:

• The file exists.
• Authenticode signature is valid.
• Signer: CN="OpenAI OpCo, LLC"
• Issuer: Microsoft ID Verified CA
• Launching the helper directly from the WindowsApps package path with elevation fails with Access is denied.
• Copying the exact same signed binary to a normal writable directory allows it to launch through UAC.
• The copied binary has the same SHA256 as the original package binary:

241FD0EC43B16C6D6B32463F39E9543D89ADD7B4CBC7AE2F2208C24C24096E25

• The copied binary's Authenticode signature is still valid.
• Running the copied binary without Codex payload returns EXIT_CODE=1.
• Running the copied binary with --help also returns EXIT_CODE=1.

This appears expected because static strings suggest the helper requires serialized payload from the Codex orchestrator, and bare/manual invocation goes through a helper_request_args_failed-style error path.

So the helper binary itself does not appear to be missing, unsigned, corrupted, or tampered with. The problem looks more like the Desktop orchestrator's launch/elevation path for the packaged WindowsApps helper.

Additional possibly related symptom

Codex may also create a literal %SystemDrive% directory inside the workspace, for example:

%SystemDrive%\ProgramData\SogouInput\Components\Picface\Cloud\

This suggests the Windows sandbox environment may be leaking or failing to expand system paths correctly. I am not claiming this is the direct cause of the setup-helper dialog, but it may be another symptom in the same Windows sandbox layer.

Impact

This still blocks normal safe editing on Windows Desktop because apply_patch update operations fail, and the Windows modal dialog appears repeatedly.

I get the same OS popup dialog and restricted apply_patch behavior in Codex CLI. I have cleared the user .sandbox and .sandbox-bin related directories and launched Codex CLI from an elevated prompt, then ran /setup-default-sandbox but the tool was unable to create the elevated sandbox and gave the following two options: quit the program, or use the unelevated sandbox.

Same here, this is really an annoying bug.

same question ,but i try to modify sandbox from “elevated” to "unelevated".it can be useful

I can reproduce a very similar issue on Windows.

Environment

• OS: Windows 10 Pro 22H2, Build 19045
• Codex About dialog version: 26.623.31443
• Windows AppX package version from Get-AppxPackage OpenAI.Codex: 26.623.3763.0
• AppX install path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.623.3763.0_x64__2p2nqsd0c76g0

• Sandbox command runner:

C:\Users\Lenovo\.codex\.sandbox-bin\codex-command-runner-0.142.2.exe

• Git installed globally:

C:\Program Files\Git\cmd\git.exe

• Git version:

git version 2.54.0.windows.1

Error

A Windows native dialog appears for:

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

The Chinese Windows dialog says:

找不到指定的模块。

English equivalent:

The specified module could not be found.

Trigger

The issue appears during Codex file-editing operations, especially:

• creating a file
• deleting a file
• applying a patch
• apply_patch
• temporary probe files such as patch_probe.txt

What works normally

The following commands work normally and do not trigger the dialog:

where.exe git
git --version
git status
git branch --show-current

A Playwright GUI test also worked:

• JavaScript + Chromium
• headless: false
• opened https://www.baidu.com
• screenshot saved successfully
• no sandbox setup dialog during that test

Sandbox modes tested

I tested both:

[windows]
sandbox = "elevated"

and:

[windows]
sandbox = "unelevated"

The issue still reproduced in both modes. I reverted to elevated.

Already tried

• Reinstalled Git globally under C:\Program Files\Git
• Verified Codex can find Git
• Renamed/rebuilt .sandbox-bin
• Renamed/rebuilt plugins\.plugin-appserver
• Renamed/rebuilt cache
• Restarted Codex
• Killed stale Codex-related processes
• Tested normal shell commands
• Tested Git commands
• Tested Playwright GUI

The issue still occurs specifically during file-editing / apply_patch operations.

Additional note

The issue seems specific to the Windows native sandbox / fs-helper / apply_patch path rather than Git, Node, Playwright, or the project itself.

目前我的解决方案：.codex\.sandbox\setup_marker.json中的代理端口删除，同时使用proxifier进行codex对应的进程转发到代理端口（避免重连的问题），就正常了。

非常感谢，对我有所帮助！

t1ck-h @.***> 于2026年6月30日周二 10:54写道：

t1ck-h left a comment (openai/codex#29200) <https://github.com/openai/codex/issues/29200#issuecomment-4839438520> 目前我的解决方案：.codex.sandbox\setup_marker.json中的代理端口删除，同时使用proxifier进行codex对应的进程转发到代理端口（避免重连的问题），就正常了。 — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/29200?email_source=notifications&email_token=BENBZL4VP454JSJMDLT7DT35CMTWNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBTHE2DGOBVGIYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4839438520>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BENBZL2E3OJJI7TM3QA6EID5CMTWNAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TINZQGYYDIOBZHE3KC5QC> . You are receiving this because you commented.Message ID: @.***>