Windows sandbox elevated setup helper fails with ShellExecuteExW 1223 / codex-windows-sandbox-setup.exe popup

Summary

On Windows, when Codex is configured with:

[windows]
sandbox = "elevated"

Codex can fail during Windows sandbox setup with:

ShellExecuteExW failed to launch setup helper: 1223

I also observed a Windows popup involving:

codex-windows-sandbox-setup.exe
The specified module could not be found.

Switching the Windows sandbox mode from elevated to unelevated avoids the 1223 failure in my environment.

This issue is separate from apply_patch. File editing has already been worked around separately, but the elevated Windows sandbox setup helper path can still trigger the popup / ShellExecuteExW 1223.

---

Environment

OS: Windows
Codex CLI: codex-cli 0.143.0
Permission mode: auto review / "approve for me"
Original Windows sandbox config:
  [windows]
  sandbox = "elevated"

Relevant config:

[windows]
sandbox = "elevated"

A/B test config:

[windows]
sandbox = "unelevated"

UAC registry values observed:

EnableLUA = 0x1
ConsentPromptBehaviorAdmin = 0x0
ConsentPromptBehaviorUser = 0x3

Defender query via Get-MpPreference failed with:

0x800106ba

Additional service state:

WinDefend = Stopped
WinDefend startup type = Manual
SecurityHealthService = Running

---

Observed behavior

With:

[windows]
sandbox = "elevated"

Codex can emit:

ShellExecuteExW failed to launch setup helper: 1223

I also observed a Windows popup referencing this executable:

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

The popup text was:

The specified module could not be found.

The popup appears to come from the Windows sandbox setup helper path, not from the patch application path.

---

Helper binary exists

The helper executable is not simply missing. It exists in multiple locations:

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

C:\Users\bart\AppData\Roaming\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe

Both files were present.

The helper import table appeared to reference standard Windows DLLs:

KERNEL32.dll
advapi32.dll
ntdll.dll
user32.dll
shell32.dll
ws2_32.dll
crypt32.dll
winhttp.dll

I did not find an obvious missing third-party DLL.

---

Sandbox logs

The sandbox log frequently shows successful setup refreshes, for example:

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

This suggests the helper does not fail every time and is not globally unusable.

However, under the elevated sandbox path I still reproduced:

ShellExecuteExW failed to launch setup helper: 1223

This makes the issue look more like a specific elevated / runas / ShellExecuteExW launch-path problem rather than a simple missing helper binary.

---

Event logs

Application and System event logs did not show a clear matching error for the popup / module error at the observed time.

So the popup may happen before regular logging captures it, or it may be shown directly by Windows without a useful Application/System log entry.

---

A/B test: elevated vs unelevated

Elevated

With:

[windows]
sandbox = "elevated"

I reproduced:

ShellExecuteExW failed to launch setup helper: 1223

This strongly suggests the failing path is related to the elevated / runas / ShellExecuteExW setup helper branch.

Unelevated

Changing the config to:

[windows]
sandbox = "unelevated"

avoided the 1223 failure in my environment.

Under unelevated, a minimal file edit succeeded and no 1223 appeared.

---

Validation under unelevated mode

After switching to:

[windows]
sandbox = "unelevated"

I validated common Codex operations in real codex exec sessions.

The following worked:

• Creating a file via Codex
• Reading a text file
• Listing a directory
• Running git status
• Running git diff
• Reading image bytes from a PNG file

Example successful command:

codex exec -C C:\codex-sandbox-probe "Use apply_patch to create phase10-codex-edit.txt with exactly: phase 10 unelevated codex edit works. Then stop."

Result:

C:\codex-sandbox-probe\phase10-codex-edit.txt
phase 10 unelevated codex edit works.

Image read also worked:

codex exec -C C:\codex-sandbox-probe "Read the file b2428bc19255.png and report its byte length. Then stop."

Result:

20686

Workspace boundary also remained in place.

This command attempted to write outside the workspace:

codex exec -C C:\codex-sandbox-probe "Try to create C:\\codex-outside-probe.txt with the text outside workspace probe, then stop."

It was denied:

Access to the path 'C:\codex-outside-probe.txt' is denied.

So in my environment, unelevated avoided the elevated helper failure while still preserving a meaningful workspace write boundary.

---

Latest log check after switching to unelevated

After switching to unelevated, a fresh sandbox log/artifact check did not find:

1223
The specified module could not be found
找不到指定的模块
Access is denied
Access denied
ShellExecuteExW failed

The sandbox log tail only showed normal setup refresh / setup binary completed / read ACL completed style entries.

---

Expected behavior

With:

[windows]
sandbox = "elevated"

Codex should be able to launch the Windows sandbox setup helper successfully without a popup and without:

ShellExecuteExW failed to launch setup helper: 1223

If elevation is required, the elevated helper launch path should either complete successfully or produce a clear actionable error.

---

Actual behavior

With:

[windows]
sandbox = "elevated"

Codex can fail with:

ShellExecuteExW failed to launch setup helper: 1223

A Windows popup involving codex-windows-sandbox-setup.exe may also appear, with:

The specified module could not be found.

Switching to:

[windows]
sandbox = "unelevated"

avoids this failure in my environment.

---

Current workaround

I am currently using:

[windows]
sandbox = "unelevated"

This avoids the ShellExecuteExW 1223 failure in my environment.

I am also using a separate workaround for apply_patch, but this issue is focused only on the Windows sandbox setup helper popup / elevated helper launch failure.

---

Suspected area

The issue appears related to the elevated Windows sandbox setup helper launch path, likely involving:

ShellExecuteExW
runas / elevation
codex-windows-sandbox-setup.exe
WindowsApps packaged Codex resources

The 1223 result suggests the elevated launch may be cancelled, blocked, or unable to complete in this environment.

---

Suggested investigation

Please investigate the elevated Windows sandbox setup helper launch path.

Specific areas that may be relevant:

1. Whether the elevated helper is launched via ShellExecuteExW with runas.
2. Whether the helper path can resolve to the WindowsApps packaged resource path.
3. Whether the elevated helper launch can fail with ERROR_CANCELLED / 1223 even when UAC is configured to auto-consent for administrators.
4. Whether Codex can provide a clearer error message when this setup helper launch fails.
5. Whether Codex can safely fall back to unelevated or another setup path when elevated setup fails.