Windows app 26.616.3767.0: elevated sandbox setup helper still fails with “The specified module could not be found”
What version of the Codex App are you using (From “About Codex” dialog)?
26.616.3767.0
What subscription do you have?
GPT Plus
What platform is your computer?
Windows x64
What issue are you seeing?
After updating Codex, the Windows native/elevated sandbox setup helper still fails to launch/load.
Windows shows an error dialog for:
C:\Program Files\WindowsApps\OpenAI.Codex_26.616.3767.0_x64__2p2nqsd0c76g0\app\resources\codex-windows-sandbox-setup.exe
The dialog says:
The specified module could not be found.
Chinese Windows: 找不到指定的模块。
What steps can reproduce the bug?
Feedback ID: 019ed527-cdcc-7363-8c3d-ef720e5a3a24
What is the expected behavior?
- Open a normal local workspace in Codex Desktop on Windows.
- Run a minimal workspace health check.
- Normal PowerShell commands work.
- Node and Python work.
- Creating/deleting a temporary file with normal PowerShell works.
- Use apply_patch to create a temporary file. This succeeds.
- Use apply_patch to delete the same temporary file. This fails and triggers the Windows dialog.
Observed Codex error:
windows sandbox failed: orchestrator_helper_launch_canceled:
ShellExecuteExW failed to launch setup helper: 1223
Expected behavior:
Codex should be able to launch the Windows native/elevated sandbox setup helper successfully, and apply_patch should be able to create, modify, and delete files inside the current workspace without showing a Windows error dialog.
Actual behavior:
The helper launch/load still fails in Codex Windows app 26.616.3767.0. The file path points to the Microsoft Store app package under WindowsApps. The executable appears to exist, but Windows reports that a required module could not be found when Codex tries to launch the helper.
Additional information
This looks like the same elevated Windows sandbox helper problem reported for 26.616.3309.0, still reproducible after updating to 26.616.3767.0. It does not appear to be caused by Node, Python, PowerShell, or normal workspace file permissions, because those all work in the same workspace.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗