Cannot find the specified module codex-windows-sandbox-setup.exe

English translation:

What version of the Codex App are you using (From “About Codex” dialog)?

26.616.32156

What subscription do you have?

plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Cannot find the specified module codex-windows-sandbox-setup.exe

<img width="834" height="283" alt="Image" src="https://github.com/user-attachments/assets/43d1a111-2693-483b-abc0-fad33fbb230c" />

019edfe9-d109-7920-a40d-0e8cc3df7e30

What steps can reproduce the bug?

Feedback ID: 019edfe9-d109-7920-a40d-0e8cc3df7e30

What is the expected behavior?

_No response_

Additional information

_No response_

<!-- codex-issue-translator -->

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

• #29072
• #28982
• #29053

Powered by Codex Action

same here, quite annoying

I can reproduce the same codex-windows-sandbox-setup.exe dialog, and I think there is a clearer root-cause / graceful-degradation case here.

Environment

• Codex Desktop MSIX package: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
• Helper path shown in the Windows dialog:

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

• OS from systeminfo:

Microsoft Windows 11 Home, 10.0.26200, x64

• Windows dialog text, zh-CN:

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

The helper executable exists on disk. Its static import table only references normal Windows DLLs such as KERNEL32.dll, advapi32.dll, user32.dll, ws2_32.dll, etc.; no obvious third-party runtime DLL is missing.

Key finding

On this machine, Windows Sandbox is not just disabled. The feature is unknown to the OS image:

dism.exe /Online /Get-FeatureInfo /FeatureName:Containers-DisposableClientVM

Output:

Error: 0x800f080c
Feature name Containers-DisposableClientVM is unknown.
A Windows feature name was not recognized.

This matches the machine being Windows 11 Home, where the Windows Sandbox feature is not available in the image.

Current behavior

Codex still tries to launch:

app\resources\codex-windows-sandbox-setup.exe

Then Windows shows the raw loader dialog:

The specified module could not be found.

The user gets no actionable message explaining that Windows Sandbox is unavailable on this edition/image.

Expected behavior

Codex should detect this before launching the sandbox setup helper:

• Check whether Containers-DisposableClientVM / the required Windows sandbox capability exists and is enabled.
• If the capability is unavailable, do not launch codex-windows-sandbox-setup.exe in a way that produces a raw Windows modal error.
• Gracefully degrade by disabling only sandbox-dependent functionality, or fall back to a non-sandbox path where safe.
• Show a clear Codex-level diagnostic, for example:

Windows Sandbox is not available on this Windows edition/image. Some sandbox-dependent Codex Desktop features are unavailable.

This issue is less about making Windows Home support Windows Sandbox, and more about Codex handling unsupported Windows environments cleanly instead of surfacing an opaque native Windows error dialog.

I was able to fix this issue on my machine.

Environment:

• Windows 11 Home
• Codex Desktop App: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
• Error dialog: codex-windows-sandbox-setup.exe / “The specified module could not be found.”

In my case, the problem was related to the proxy settings stored in Codex’s user directory.

I had proxy variables configured in:

C:\Users\<username>\.codex\.env

For example:

HTTP_PROXY="http://127.0.0.1:7897"
HTTPS_PROXY="http://127.0.0.1:7897"
ALL_PROXY="socks5://127.0.0.1:7897"

And the sandbox state file also had the same proxy port recorded:

C:\Users\<username>\.codex\.sandbox\setup_marker.json

Before:

"proxy_ports": [
  7897
]

What fixed it for me:

1. Close Codex completely.
2. Rename .env to .env.bak, or remove/comment out the proxy variables.
3. Edit .codex\.sandbox\setup_marker.json.
4. Change proxy_ports to an empty array:

"proxy_ports": []

1. Restart Codex.

After doing this, Codex stopped launching codex-windows-sandbox-setup.exe, and file editing / apply_patch started working again.

So this seems to be related to a mismatch between proxy settings in .codex\.env and the Windows elevated sandbox state in .codex\.sandbox\setup_marker.json.

For users who still need a proxy, using a system-level/TUN proxy mode may be safer than setting HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY directly in Codex’s .env until this bug is fixed.

@Lggyy9 Thanks mate, that works for me

Has anyone tried just running VS Code as an administrator first? That actually solved the issue for me.

> For users who still need a proxy, using a system-level/TUN proxy mode may be safer than setting HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY directly in Codex’s .env until this bug is fixed.

What other ways are there to solve the problem without using a system-level/TUN proxy mode?

I fixed this by setting the sandbox option in the Codex config to unelevated:

[windows]
sandbox = "unelevated"

I'm using Windows 11, WebStorm, and codex-cli in the terminal. Once I ran WebStorm as an administrator, this error stopped appearing.

I can reproduce this on another Windows 11 machine, and I have one extra data point that may help narrow it down.

Environment

• Codex Desktop/App package observed in the sandbox log: OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0
• codex-windows-sandbox-setup.exe path shown in the Windows dialog after switching CODEX_CLI_PATH to the bundled app CLI:

C:\Users\Samsen\AppData\Local\OpenAI\Codex\bin\38dff8711e296435\codex-windows-sandbox-setup.exe

• OS from systeminfo: Microsoft Windows 11 Home / 10.0.26200 / x64
• Dialog text: 找不到指定的模块。 / The specified module could not be found.
• Config:

```toml
sandbox_mode = "workspace-write"

[windows]
sandbox = "elevated"
```

Interesting behavior

The Windows modal dialog appears, but the sandbox log shows the setup helper completing successfully in the same time window.

From C:\Users\Samsen\.codex\.sandbox\sandbox.2026-07-03.log:

setup refresh: spawning C:\Users\Samsen\AppData\Local\OpenAI\Codex\bin\38dff8711e296435\codex-windows-sandbox-setup.exe
(cwd=C:\Program Files\WindowsApps\OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0\app, payload_len=3332)

setup refresh: processed 2 write roots (read roots delegated); errors=[]
codex-windows-sandbox-setup.exe setup binary completed

helper copy: using in-memory cache for command-runner ->
C:\Users\Samsen\.codex\.sandbox-bin\codex-command-runner-0.142.0.exe

helper launch resolution: using copied command-runner path
C:\Users\Samsen\.codex\.sandbox-bin\codex-command-runner-0.142.0.exe

read-acl-only mode: applying read ACLs
read ACL run completed

This matches the confusing user-visible behavior: apply_patch can create the file successfully, while Windows still shows the native codex-windows-sandbox-setup.exe modal dialog. So at least one setup path is succeeding, while another concurrent/loader/elevated path appears to surface the modal.

Proxy-related data point

This machine does not have C:\Users\Samsen\.codex\.env, but the Codex process environment has proxy variables:

HTTP_PROXY=http://127.0.0.1:10808
HTTPS_PROXY=http://127.0.0.1:10808
ALL_PROXY=socks5h://127.0.0.1:10808
NO_PROXY=localhost,127.0.0.1,::1

And C:\Users\Samsen\.codex\.sandbox\setup_marker.json contains:

{
  "version": 5,
  "offline_username": "CodexSandboxOffline",
  "online_username": "CodexSandboxOnline",
  "proxy_ports": [10808],
  "allow_local_binding": false,
  "read_roots": [],
  "write_roots": []
}

So this may be consistent with the proxy/setup-marker angle mentioned above, even without a .codex/.env file.

Other checks

• dumpbin /imports on codex-windows-sandbox-setup.exe only showed normal Windows DLL imports (KERNEL32.dll, advapi32.dll, ntdll.dll, oleaut32.dll, bcrypt*.dll, crypt32.dll, ole32.dll, user32.dll, ws2_32.dll, fwpuclnt.dll, netapi32.dll, etc.).
• The ordinary system DLLs are present under C:\Windows\System32 / SysWOW64.
• The copied command runner in .codex\.sandbox-bin\codex-command-runner-0.142.0.exe has the same SHA256 as the bundled codex-command-runner.exe.

This looks less like a simple missing DLL on the host and more like an issue in the Windows sandbox setup / elevated spawn / proxy-port setup path. The main request from my side would be: if the setup helper can complete with errors=[], Codex should not also surface a raw Windows loader modal to the user, or should log which secondary spawn/load path produced it.

I’m seeing the same issue on Windows.

My setup:

• Windows
• Codex with a local proxy always enabled for development
• Proxy is injected from the terminal environment, e.g. PowerShell profile:

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

What I observed:

• As soon as Codex detects the local proxy, .codex/.sandbox/setup_marker.json is regenerated with proxy_ports, for example:

"proxy_ports": [7890]

• Manually editing or clearing setup_marker.json does not help, because Codex rewrites it on the next run.
• Putting proxy variables in .codex/.env also triggers the same sandbox-related behavior.
• This caused codex-windows-sandbox-setup.exe / sandbox setup failures for me.

Current workaround:

[windows]
sandbox = "unelevated"

Together with terminal-level proxy variables, this currently works around both problems for me:

1. the repeated reconnecting/network issue without proxy, and
2. the Windows sandbox setup failure when proxy is detected.

So this looks like a Windows sandbox/proxy interaction bug rather than a user config issue. Hope this helps with debugging.

You can try the method mentioned here:
https://github.com/openai/codex/issues/29418#issuecomment-4831792926

I can reproduce this on the current Windows release, and the impact is much broader than a single failed helper launch.

Environment

• ChatGPT/Codex desktop app: 26.707.3748.0
• Codex CLI: 0.144.1
• Windows 11 x64, build 26200
• ChatGPT Plus
• Date reproduced: 2026-07-12

What happened
After the forced migration/rename from the standalone Codex app to the new ChatGPT desktop app, the new app stopped launching entirely. Windows creates the OpenAI.Codex process and AppX container, then immediately destroys the container. AppModel-Runtime records events 201/210/211/217, but there is no corresponding Application Error or Windows Error Reporting crash entry.

The same machine then reproduces this issue in the officially installed CLI: setup blocks and Windows reports that it cannot find codex-windows-sandbox-setup.exe.

Recovery attempts that did not fix the desktop app

• terminated all ChatGPT/Codex processes
• restarted Windows
• Windows App settings: Repair, Terminate, and Reset
• uninstalled and clean-installed the current ChatGPT app from Microsoft Store
• closed ChatGPT Classic completely
• tested with the existing .codex directory moved aside
• confirmed the window was not opening off-screen

The only way to regain access to existing work was to install Codex CLI separately, select the non-admin sandbox / use a full-access workaround, point CODEX_HOME at the preserved data, and run codex resume --all. That is not an acceptable replacement for the desktop product or for a migration that was supposed to preserve working access.

User impact
Important running work had to be interrupted. Several hours were lost recovering access to existing projects and sessions. This is not the first stability incident. The user is ending their use of GPT/Codex and moving to Claude Code because they need a stable production tool, not repeated recovery work after product updates.

Because this is a paid service and the failure made the purchased functionality unavailable while causing a measurable loss of working time, the user also requests a formal response explaining what compensation or consumer redress is available under applicable law and OpenAI's terms. Please do not treat this only as a cosmetic Windows bug: the direct cost to the user is lost work time.

Requested action

1. Fix or roll back the broken Windows migration/startup path.
2. Guarantee preservation and automatic recovery of projects, sessions, permissions, and running tasks.
3. Publish a clear status/workaround for affected Windows build 26200 users.
4. Provide a support route for compensation/redress relating to paid-service downtime and lost working time.