Windows 10: sandbox setup helper shows "The specified module could not be found" after updating Codex App

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

• #29115
• #29072
• #29089
• #28982
• #29053

Powered by Codex Action

I think this is because of .codex\.env
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:

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

I think this is because of .codex.env 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: Older sandbox state contains a stored proxy/firewall configuration. Newer Codex versions calculate a different desired proxy/firewall configuration. The elevated Windows sandbox repeatedly decides setup refresh is required. The setup helper launch path then fails intermittently or consistently with ShellExecuteExW 1223. apply_patch/edit operations fail as a downstream symptom.

Open AI should fix this.

Additional confirmation: this is failing before SSH auth/key selection.
Version 26.616.32156 • Released Jun 18, 2026

Inside Codex runner:

• whoami shows the new sandbox/offline runner account rather than my normal Windows user.
• ssh -G <user>@<tailnet-host> resolves the host correctly to its Tailnet IP.
• Test-NetConnection <tailnet-ip> -Port 22:
• PingSucceeded: True
• TcpTestSucceeded: False
• ssh -vvv fails at socket connect:
• finish_connect - ERROR: async io completed with error: 10013
• connect to address <tailnet-ip> port 22: Permission denied

The same target and command works from normal Administrator PowerShell as my regular user.

Windows Firewall outbound allow rules for TCP/22 to the Tailnet range, OpenSSH, and the Codex app binary did not change the behavior.

This lines up with my symptoms. In my case the visible failure is not apply_patch/editing, but network access from the Windows Codex sandbox runner.

Normal PowerShell can SSH to the Tailnet host. Codex tool execution runs under the sandbox/offline runner account. From inside that runner, DNS/Tailnet resolution works and ping succeeds, but TCP/22 fails before SSH auth with Windows socket error 10013.

I also tried explicit Windows Firewall outbound allow rules for Tailnet TCP/22, OpenSSH, and the Codex app binary; no change.

Happy to test a reset command if there is a supported way to clear/rebuild the Windows sandbox state.

Update: the issue still reproduces after updating Codex

I updated/reinstalled the Codex Windows app, but the same issue still occurs.

Environment

1. OS: Windows 10 Pro x64, build 19045
2. Subscription: ChatGPT Plus
3. Previous Codex About version: 26.616.32156
4. Previous Microsoft Store/AppX package version: 26.616.4196.0
5. Current Codex About version: 26.616.41845
6. Current Microsoft Store/AppX package version: 26.616.5445.0
7. Sandbox configuration:

[windows]
sandbox = "elevated"

The currently running executable is located under:

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

Reproduction result

The same problem was reproduced in two separate workspaces:

G:\DevProjects\Game
F:\AIs_tools\AI_KnowledgeBase

Reproduction sequence:

1. Ask Codex to create a temporary file using apply_patch.
2. The first patch may report success, and the file may actually be created.
3. At approximately the same time, Windows displays an error dialog for codex-windows-sandbox-setup.exe.
4. The dialog says:

The specified module could not be found.

1. A subsequent apply_patch operation may fail with:

apply_patch verification failed: Failed to read file to update:
fs sandbox helper failed with status exit code: 1:
windows sandbox failed:
orchestrator_helper_launch_canceled:
ShellExecuteExW failed to launch setup helper: 1223

The Windows dialog can therefore appear even when the first patch reports success.

Additional observation

A direct PowerShell operation on the same temporary file succeeds:

Remove-Item -LiteralPath "<workspace>\.codex_project_repro_probe.txt" -Force

The target file is inside the writable workspace, and its owner and ACL are valid.

This suggests that the failure is specific to the apply_patch / Windows sandbox setup-helper path, rather than a general inability to write to the workspace.

The sandbox log also repeatedly contained entries similar to:

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

The behavior is intermittent. Some later sandbox setup refreshes complete successfully, but the popup and apply_patch failure can still return.

Expected behavior

apply_patch should create, update, and delete files inside an authorized workspace without displaying a failing setup-helper dialog.

If the Windows sandbox configuration needs to be refreshed, codex-windows-sandbox-setup.exe should start successfully and should not cancel the patch operation.

Updating from package version 26.616.4196.0 to 26.616.5445.0, reinstalling Codex, and using sandbox = "elevated" did not resolve the issue.

My codex had the same problem. And I do think that could burn your tokens at a horrible speed...one request burned all my 5-hour token with hundreds of Window alerts...and tens of retries and workarounds.

BTW, although Codex CLI has the same problem, it doesn't produce aleart windows, at least.

1. Check whether the following configuration appears in the codex/config.toml file: [windows] sandbox = "elevated"
2. If it does exist, please change it to [windows] sandbox = "unelevated".