Windows app 26.616.3309.0: native sandbox setup helper fails with “The specified module could not be found

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

• #28278

Powered by Codex Action

<img width="1100" height="368" alt="Image" src="https://github.com/user-attachments/assets/a4aee832-347b-45c3-93a1-83320cf18248" />

I found several related Windows sandbox/helper issues: #28278, #24490, #18845, #27125, #28457, #27367. My case appears to be the same subsystem, but the specific difference is that it happens in Codex Windows app 26.616.3309.0 and Windows shows “The specified module could not be found” for the Microsoft Store app path under OpenAI.Codex_26.616.3309.0.

I can confirm this also reproduces on Codex Windows app 26.616.3767.0.

Environment:

• Windows x64, Chinese locale
• Codex app package path:

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

• Config before workaround:

``toml
[windows]
sandbox = "elevated"
``

Observed behavior:

• Any tool call that needs the Windows sandbox setup path can trigger the dialog.
• I first noticed it when apply_patch ran.
• Plain shell commands could also trigger the same popup.
• Windows dialog message in Chinese:

找不到指定的模块。

• This matches the English “The specified module could not be found.”
• The executable exists at the reported path, so this looks like a launch/load failure in the elevated sandbox setup helper path, not a missing file.

Workaround that fixed it for me:

[windows]
sandbox = "unelevated"

After fully restarting Codex Desktop, I validated:

• Get-Location succeeded.
• Native apply_patch could create/modify a temporary file under work/.
• Native apply_patch could delete that temporary file.
• No codex-windows-sandbox-setup.exe dialog appeared.
• No ShellExecuteExW, orchestrator_helper_launch_canceled, or “specified module could not be found” error appeared.

So this appears to be specific to the elevated Windows sandbox setup path in the recent Windows app build. The unelevated sandbox path is a working temporary workaround.

Update: after updating Codex, this still reproduces on Codex Windows app 26.616.3767.0.

The Windows dialog now points to:

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

The dialog message is still:

The specified module could not be found.
Chinese Windows: 找不到指定的模块。

I retested with a minimal health check in the current workspace:

• Normal PowerShell commands work.
• Node works.
• Python works.
• Creating and deleting a temporary file with normal PowerShell works.
• apply_patch can create a temporary file successfully.
• apply_patch fails when deleting the temporary file.

The Codex-side error is still:

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

So the issue is not fixed in 26.616.3767.0. It still appears specific to the Windows native/elevated sandbox setup helper path. The helper executable appears to exist, but launching/loading it fails.

<img width="1164" height="438" alt="Image" src="https://github.com/user-attachments/assets/95bba618-39ee-482e-afda-37a877ee1e55" />

I also tested the VS Code Codex extension on the same machine.

VS Code extension:

• Extension version: openai.chatgpt@26.616.31447
• Bundled codex CLI: codex-cli 0.140.0-alpha.2
• codex.exe path:

C:\Users\<user>\.vscode\extensions\openai.chatgpt-26.609.30741-win32-x64\bin\windows-x86_64\codex.exe

In the VS Code extension, the same minimal apply_patch create/delete test succeeds:

• normal shell create/delete succeeds
• apply_patch create succeeds
• apply_patch delete succeeds
• no Windows dialog
• no codex-windows-sandbox-setup.exe popup
• no ShellExecuteExW 1223
• no “The specified module could not be found”

So the issue appears specific to the Codex Windows Desktop app / Microsoft Store WindowsApps package path, not the general Codex CLI or apply_patch mechanism on this machine.

I have the same issue

<img width="558" height="178" alt="Image" src="https://github.com/user-attachments/assets/68f5b9b3-f3a9-4163-a0cb-cc04d97f0fc4" />

This is crazy:

<img width="765" height="399" alt="Image" src="https://github.com/user-attachments/assets/2e528186-8c9b-4bc7-bc40-df4025dac5a0" />

---

Codex app 26.616.3767.0 on Windows.

Relevant config:

• sandbox_mode = "workspace-write"
• [windows] sandbox = "elevated"
• No project-local .codex/config.toml override
• The setup helper exists and has a valid OpenAI signature

Observed apply_patch behavior:

• apply_patch can create a file successfully
• apply_patch fails when deleting the same file

Exact error from apply_patch delete:

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

Sanitized sandbox log excerpt:

[2026-06-19 09:54:25.886 codex.exe] setup refresh: spawning CODEX_APP_DIR\resources\codex-windows-sandbox-setup.exe (cwd=CODEX_APP_DIR, payload_len=3656)
[2026-06-19T06:54:25.934107700+00:00] setup refresh: processed 2 write roots (read roots delegated); errors=[]
[2026-06-19 09:54:25.934 codex-windows-sandbox-setup.exe] setup binary completed
[2026-06-19 09:54:25.940 codex.exe] helper copy: validating command-runner source=CODEX_APP_DIR\resources\codex-command-runner.exe destination=CODEX_HOME\.sandbox-bin\codex-command-runner-0.142.0-alpha.1.exe
[2026-06-19 09:54:25.942 codex.exe] helper copy: recopied command-runner source=CODEX_APP_DIR\resources\codex-command-runner.exe destination=CODEX_HOME\.sandbox-bin\codex-command-runner-0.142.0-alpha.1.exe
[2026-06-19 09:54:25.943 codex.exe] helper launch resolution: using copied command-runner path CODEX_HOME\.sandbox-bin\codex-command-runner-0.142.0-alpha.1.exe
[2026-06-19 12:17:24.353 codex.exe] setup refresh: spawning CODEX_APP_DIR\resources\codex-windows-sandbox-setup.exe (cwd=CODEX_APP_DIR, payload_len=3448)
[2026-06-19T09:17:24.377898200+00:00] setup refresh: processed 2 write roots (read roots delegated); errors=[]
[2026-06-19 12:17:24.377 codex-windows-sandbox-setup.exe] setup binary completed
[2026-06-19 12:17:24.382 codex.exe] helper copy: using in-memory cache for command-runner -> CODEX_HOME\.sandbox-bin\codex-command-runner-0.142.0-alpha.1.exe
[2026-06-19 12:17:24.382 codex.exe] helper launch resolution: using copied command-runner path CODEX_HOME\.sandbox-bin\codex-command-runner-0.142.0-alpha.1.exe
[2026-06-19 12:19:27.650 codex.exe] setup refresh: spawning CODEX_APP_DIR\resources\codex-windows-sandbox-setup.exe (cwd=CODEX_APP_DIR, payload_len=3448)
[2026-06-19T09:19:27.677588200+00:00] setup refresh: processed 2 write roots (read roots delegated); errors=[]
[2026-06-19 12:19:27.677 codex-windows-sandbox-setup.exe] setup binary completed

Important note:
The sandbox log repeatedly shows setup helper completion with errors=[], but apply_patch still fails with ShellExecuteExW failed to launch setup helper: 1223.

This is really bad. Open AI should fix this problem immediately.

Update after installing Codex Windows app 26.616.4196.0:The issue still reproduces on my machine.

• Normal PowerShell file create/read/delete in the workspace works correctly.
• apply_patch can create a temporary file successfully.
• apply_patch fails when deleting the same file.
• The failure is still:

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

Temporary test files were cleaned up successfully using normal PowerShell.

<img width="1140" height="404" alt="Image" src="https://github.com/user-attachments/assets/1d8845cf-fce5-40dc-999d-b1d52f91e6e7" />

I am using the VSCode Codex plugin, and I have the same issue.
dialog:
[Window Title]
c:\Users\ltxhhz\.vscode\extensions\openai.chatgpt-26.616.31447-win32-x64\bin\windows-x86_64\codex-windows-sandbox-setup.exe

[Content]
c:\Users\ltxhhz\.vscode\extensions\openai.chatgpt-26.616.31447-win32-x64\bin\windows-x86_64\codex-windows-sandbox-setup.exe

找不到指定的模块。（The specified module could not be found.）

[确定]

I have already tried reloading and reinstalling the plugin. It still doesn't work.

I've encountered this problem too.

I've encountered this problem too.

Hi, just wondering if you're a developer from China—I've noticed this issue mostly occurs among Chinese users.

Hi, just wondering if you're a developer from China—I've noticed this issue mostly occurs among Chinese users.

My codex (US/english) is having issues with using apply_patch, so it's not China only

> Hi, just wondering if you're a developer from China—I've noticed this issue mostly occurs among Chinese users. My codex (US/english) is having issues with using apply_patch, so it's not China only

Thank you for your response. I asked whether you are a Chinese developer because Chinese users often configure the .env file to specify ports, and during my current troubleshooting, I've found that this issue might be the cause of the bug.

Based on the current evidence, this issue appears to be related to a state mismatch in the Windows elevated sandbox setup after recent Codex updates.

In my environment, Codex uses a configured proxy and the Windows sandbox state file records a proxy port in its stored sandbox setup marker. However, the newer Codex runtime appears to sometimes compute the desired proxy port list as empty. As a result, the sandbox repeatedly detects an offline firewall configuration mismatch, with logs showing a pattern like:

offline firewall settings changed (stored_ports=[...], desired_ports=[])

After that, Codex repeatedly attempts to refresh or relaunch the Windows sandbox setup helper. In the affected versions, this elevated helper launch path can fail with:

ShellExecuteExW failed to launch setup helper: 1223

and may also trigger a Windows popup for codex-windows-sandbox-setup.exe saying that the specified module could not be found.

This would explain why normal shell file operations may still work, why apply_patch can sometimes create a file successfully, and why later edit/delete operations fail. It also explains why the issue can appear after an update without any project-level configuration change.

So my current hypothesis is:

1. Older sandbox state contains a stored proxy/firewall configuration.
2. Newer Codex versions calculate a different desired proxy/firewall configuration.
3. The elevated Windows sandbox repeatedly decides setup refresh is required.
4. The setup helper launch path then fails intermittently or consistently with ShellExecuteExW 1223.
5. apply_patch/edit operations fail as a downstream symptom.

1.
Was using Codex vscode extension.

got a pop up window.

[Window Title]
c:\Users\nshln\.vscode\extensions\openai.chatgpt-26.616.32156-win32-x64\bin\windows-x86_64\codex-windows-sandbox-setup.exe

[Content]
c:\Users\nshln\.vscode\extensions\openai.chatgpt-26.616.32156-win32-x64\bin\windows-x86_64\codex-windows-sandbox-setup.exe

The specified module could not be found.


[OK]

1.
Then I tried to do more testing and output the problem:

• v

``````

Worked for 1m 8s

I’m going to check this without touching your source files. The checks are: 1) confirm Git can inspect the repo using a one-command safe-directory override, 2) test whether apply_patch still fails using a disposable probe file, and 3) report exact risk from my earlier PowerShell edits.

Ran git -c safe.directory=D:/usp/uhpsj/study/build_llm_wsp/build_llm status --short

Shell
$ git -c safe.directory=D:/usp/uhpsj/study/build_llm_wsp/build_llm status --short

M src/build_llm_learn/p_10p_segformer/model_exec/train/todo.md

Success

Git inspection works when I pass -c safe.directory=... on the command, so the Git issue is controllable without admin and without changing global config. I’m testing apply_patch now with a disposable file so this does not alter your model code.

Created a fileCreated.codex_apply_patch_probe.tmp+1-0

apply_patch succeeded on the disposable add test. I’m deleting the probe with apply_patch as the second half of the check.

Deleting a fileDeleting a file

The failure is still present, but intermittent: apply_patch could add the probe file, then failed deleting the same probe with the same Windows sandbox helper error. I created that disposable file, so I’m removing only that probe now to leave your tree clean.

Ran Remove-Item -LiteralPath .\.codex_apply_patch_probe.tmp

Shell
$ Remove-Item -LiteralPath .\.codex_apply_patch_probe.tmp

No output

Success

The probe file is removed. I’m checking status once more so I can report exactly what remains changed.

Ran git -c safe.directory=D:/usp/uhpsj/study/build_llm_wsp/build_llm status --short

Shell
$ git -c safe.directory=D:/usp/uhpsj/study/build_llm_wsp/build_llm status --short

M src/build_llm_learn/p_10p_segformer/model_exec/train/todo.md

Success

``````

``````

You are right. I did not explain the most important part clearly enough: how I edited the files and what risk that created.

Here is the exact state.

What I Just Checked

1. Git status with a safe-directory override:

``powershell
git -c safe.directory=D:/usp/uhpsj/study/build_llm_wsp/build_llm status --short
``
Result: Git works with this override.

1. apply_patch probe:

• Add disposable .codex_apply_patch_probe.tmp: succeeded
• Delete same file with apply_patch: failed again with:

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

1. Removed the probe file with PowerShell.

1. Final status:

``text
M src/build_llm_learn/p_10p_segformer/model_exec/train/todo.md
`
So there is no leftover probe file. Only your todo.md` is modified after your commit.

What The Problem Is
apply_patch is still unreliable. It is not fully dead, but it is unsafe because it can succeed once and fail next time on the same file path. That means I should not rely on it blindly for real source edits right now.

Git is not actually blocked if I use:
``powershell
git -c safe.directory=D:/usp/uhpsj/study/build_llm_wsp/build_llm ...
``

No admin access is needed for that.

How I Edited The Files Earlier
Because apply_patch failed, I used PowerShell commands like:

``powershell
$text = Get-Content -Raw -Path $path
$text = $text.Replace(...)
Set-Content -Path $path -Value $text -NoNewline
``

That was the “hack.”

Risk You Are Facing From That
The risk is not hidden model corruption magic. It is these concrete risks:

1. A string replacement may hit the wrong matching block.
2. A failed replacement may leave a partially threaded variable path, for example boundary_loss added in one place but not another.
3. Set-Content -NoNewline may alter final newline behavior.
4. PowerShell writing may normalize encoding or line endings depending on version/settings.
5. Because I did multiple mechanical replacements, review/diff is required before trusting the code.

Compile and a small runtime smoke test passed earlier, but that does not prove the implementation is clean.

What I Need From You
For future source edits in this repo:

``text
Use git -c safe.directory=... for diff/status.
Use apply_patch first.
If apply_patch fails, STOP and ask before using any PowerShell edit fallback.
``

If you want me to continue the boundary-loss task safely, I need this explicit permission:

``text
Do one cleanup pass. If apply_patch fails, stop and ask before fallback.
``

Then I will only inspect/diff, fix obvious issues, compile, and stop.

``````

1.

the diagnostic is unhelpful,
so my solution is:

revert the codex extension version to

C:\Users\nshln\.vscode\extensions\openai.chatgpt-26.519.32039-win32-x64

dont use

C:\Users\nshln\.vscode\extensions\openai.chatgpt-26.616.31447-win32-x64
C:\Users\nshln\.vscode\extensions\openai.chatgpt-26.616.32156-win32-x64

1.

I remember I faced the problem in Codex App.

AI did mention something about using sandbox = "unelevated". But i didnt do that.
AI also mention something about WSL, thats why old version works? I have no idea.

Update: I tried the temporary workaround of changing the Windows sandbox mode from elevated to unelevated:

[windows]
sandbox = "unelevated"

After restarting Codex, I reran a minimal test:

1. Normal shell create/delete of a temporary file: succeeded
2. apply_patch create of a temporary file: succeeded
3. apply_patch delete of the same file: succeeded
4. No ShellExecuteExW failed to launch setup helper: 1223 error appeared

This suggests that the failure is indeed concentrated in the Windows elevated sandbox/helper launch path. The unelevated mode works as a temporary workaround, but I do not consider it a root-cause fix.

Based on earlier read-only inspection, the sandbox logs repeatedly showed a mismatch between stored_ports and desired_ports, so my current suspicion is that this may be related to proxy port / firewall state reconciliation in the Windows elevated sandbox after recent Codex updates.

The bug still exists in version 26.616.41845

<img width="801" height="289" alt="Image" src="https://github.com/user-attachments/assets/6288bcee-c58c-47e5-b97f-1cfdead010c3" />

我也遇到了这个问题，还没办法解决

> > Hi, just wondering if you're a developer from China—I've noticed this issue mostly occurs among Chinese users. > > > My codex (US/english) is having issues with using apply_patch, so it's not China only Thank you for your response. I asked whether you are a Chinese developer because Chinese users often configure the .env file to specify ports, and during my current troubleshooting, I've found that this issue might be the cause of the bug.

I deleted the .env file under ~/.codex, and the issue was fixed.apply_patch works again.thank you

2026 06 21 china user
Codex在执行任务时发生报错（C:\ProgramFiles\WindowsApps\OpenAI.Codex_26.616.663...\codex-windows-sandbox-setup.exe COM+ 注册表数据库检测到一个系统错误）
.env设置了7890端口代理规则。是否与此有关？有没有了解真实状况的告知解决办法及原因。

2026 06 21 china user Codex在执行任务时发生报错（C:\ProgramFiles\WindowsApps\OpenAI.Codex_26.616.663...\codex-windows-sandbox-setup.exe COM+ 注册表数据库检测到一个系统错误） .env设置了7890端口代理规则。是否与此有关？有没有了解真实状况的告知解决办法及原因。

（1）Enable TUN (such as Clash) mode so that network traffic is handled at the system routing layer.
（2）Comment out HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, WS_PROXY, WSS_PROXY, NO_PROXY in Codex user directory's .env.
（3）Clear proxy_ports in sandbox state, setting it to [].
（4）Restore [windows] sandbox = "elevated" — do not rely on unelevated long-term.
（5）If PowerShell shows shell snapshot errors, add shell_snapshot=false under [features].

我也遇到了这个问题，还没办法解决

（1）Enable TUN (such as Clash) mode so that network traffic is handled at the system routing layer.
（2）Comment out HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, WS_PROXY, WSS_PROXY, NO_PROXY in Codex user directory's .env.
（3）Clear proxy_ports in sandbox state, setting it to [].
（4）Restore [windows] sandbox = "elevated" — do not rely on unelevated long-term.
（5）If PowerShell shows shell snapshot errors, add shell_snapshot=false under [features].

### What version of the Codex App are you using (From “About Codex” dialog)? 26.616.3309.0 ### What subscription do you have? ChatGPT Plus ### What platform is your computer? Windows x64 ### What issue are you seeing? After updating to Codex Windows app 26.616.3309.0, Codex fails when launching the Windows native/elevated sandbox setup helper. Windows shows an error dialog for: C:\Program Files\WindowsApps\OpenAI.Codex_26.616.3309.0_x64__2p2nqsd0c76g0\app\resources\codex-windows-sandbox-setup.exe The dialog message is: The specified module could not be found. In Chinese Windows, this appears as: 找不到指定的模块。 Codex reports the related error: windows sandbox failed: orchestrator_helper_launch_canceled ShellExecuteExW failed to launch setup helper: 1223 The issue appears when Codex uses apply_patch, for example when trying to delete a temporary file. Normal PowerShell commands, file reads, Node, Python, and npm tests still work. I have already tried restarting Codex, restarting Windows, running workspace dependency diagnostics, resetting/reinstalling workspace dependencies, repairing Codex from Windows Settings, and fully uninstalling/reinstalling Codex. The issue still persists. The executable exists at the path above and appears to have a valid OpenAI signature. ### What steps can reproduce the bug? Feedback ID: no-active-thread-019edc9c-474a-7f12-91ca-94e33521d229 ### What is the expected behavior? Codex should be able to launch the Windows native/elevated sandbox setup helper successfully and complete apply_patch operations such as creating, modifying, or deleting files inside the workspace. The sandbox setup helper should not show a Windows error dialog, and apply_patch should work normally in the current workspace. ### Additional information This started after updating Codex. I have seen another user report showing the same OpenAI.Codex_26.616.3309.0 path and the same codex-windows-sandbox-setup.exe error dialog. This may be a regression in the latest Codex Windows app related to the Windows native/elevated sandbox setup helper. I have not switched the sandbox setting to unelevated yet, because I wanted to report the default/native elevated sandbox failure first.

Config.toml设置以下
model_provider = "openai_http"

[model_providers.openai_http]
name = "OpenAI HTTP only"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

[windows]
sandbox = "unelevated" # 将此行从 "elevated" 改为 "unelevated"

<img width="838" height="275" alt="Image" src="https://github.com/user-attachments/assets/cfd911e8-28bb-4d49-a7eb-f976573eb9ea" />
我也遇到了同样的问题

@codex Please fix this bug!

我遇到了同样的问题

我遇到了同样的问题

上面有人发解决办法了，我是把.env删了，然后清除沙盒状态下的proxy_ports残留，就好了。

> 我遇到了同样的问题 上面有人发解决办法了，我是把.env删了，然后清除沙盒状态下的proxy_ports残留，就好了。

我也这么做了，但可能是我在使用代理的缘故，还是会有同样的问题出现

把配置文件中沙盒改为un开头的就好了
---- Replied Message ----
@.>Date06/23/2026 11:21 @.> CcYuwei @.*>,
@.*>SubjectRe: [openai/codex] Windows app 26.616.3309.0: native sandbox setup helper fails with “The specified module could not be found (Issue #28982)
JJjyJJ7F3 left a comment (openai/codex#28982)
我遇到了同样的问题
上面有人发解决办法了，我是把.env删了，然后清除沙盒状态下的proxy_ports残留，就好了。
我也这么做了，但可能是我在使用代理的缘故，还是会有同样的问题出现
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

把配置文件中沙盒改为un开头的就好了 ---- Replied Message ---- @.>Date06/23/2026 11:21 @.> CcYuwei @.>, @.>SubjectRe: [openai/codex] Windows app 26.616.3309.0: native sandbox setup helper fails with “The specified module could not be found (Issue #28982) JJjyJJ7F3 left a comment (openai/codex#28982) 我遇到了同样的问题 上面有人发解决办法了，我是把.env删了，然后清除沙盒状态下的proxy_ports残留，就好了。 我也这么做了，但可能是我在使用代理的缘故，还是会有同样的问题出现 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

这个我是知道的，不过看官方推荐用 sandbox = "elevated"，所以就去没改

so my solution is: revert the codex extension version to `` C:\Users\nshln\.vscode\extensions\openai.chatgpt-26.519.32039-win32-x64 ` dont use ` C:\Users\nshln\.vscode\extensions\openai.chatgpt-26.616.31447-win32-x64 C:\Users\nshln\.vscode\extensions\openai.chatgpt-26.616.32156-win32-x64 ``

https://github.com/openai/codex/issues/28982#issuecomment-4756105087

---

is this problem fixed?

For vscode extension

Installation
Identifier
openai.chatgpt
Version
26.707.31428

I dont see the problem anymore?

I dont think i used any workaround like sandbox = "elevated".