Windows Desktop update churn reintroduces codex-windows-sandbox-setup.exe failures by invalidating the RUNASINVOKER workaround #29771

The Windows sandbox helper currently feels like a regression subscription: every Codex Desktop update ships a new absolute WindowsApps path, invalidates the only known per-path RUNASINVOKER workaround, and then rewards users with the same native codex-windows-sandbox-setup.exe dialog. That is not an update mechanism; it is a maintenance treadmill for a bundled helper.

Closing these as duplicates without fixing the helper/launcher does not make the bug disappear; it just turns users into unpaid AppCompatFlags maintainers. OpenAI ships this helper, so OpenAI should make it launch reliably across ordinary Desktop updates.

What issue are you seeing?

After updating Codex Desktop on Windows, the sandbox setup helper path changed to a new MSIX/WindowsApps package path:

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

The helper exists, but the new absolute path did not inherit the previously applied per-path RUNASINVOKER compatibility workaround. That means the next Desktop update can reintroduce the same helper launch failure even after the user has already worked around it once.

The visible failure is the native Windows dialog for codex-windows-sandbox-setup.exe saying:

The specified module could not be found.

On a Chinese Windows install this is shown as:

找不到指定的模块。

In this user's case, the dialog can appear after a prior Codex use, even when the user is no longer actively invoking Codex, which makes the failure feel like a background/update-time regression rather than a single command failure.

Why this is a product bug, not a user config issue

• The helper is a bundled Codex Desktop executable.
• The helper name/path appears to interact poorly with Windows setup/elevation heuristics, matching earlier reports around ShellExecuteExW 1223, os error 740, and setup-helper launch cancellation.
• The known workaround is per absolute path under:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

• MSIX/WindowsApps updates change the absolute package path.
• Therefore the workaround is inherently fragile and can be invalidated by ordinary Codex Desktop updates.
• Users should not have to rediscover and reapply registry compatibility entries for a bundled OpenAI helper after each release.

Local evidence from the latest update

Before manual repair, the app updated to:

OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0

Current helper:

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

Helper SHA256:

241FD0EC43B16C6D6B32463F39E9543D89ADD7B4CBC7AE2F2208C24C24096E25

Relevant network/proxy state was not lost, so this was not simply proxy configuration disappearing:

"proxy_ports": [7890]

User environment also still had the proxy variables pointing at http://127.0.0.1:7890.

After manually adding RUNASINVOKER for the new helper path, the current checked state is:

AppCompat Layer: RUNASINVOKER
Helper exists: true
Helper SHA256: 241FD0EC43B16C6D6B32463F39E9543D89ADD7B4CBC7AE2F2208C24C24096E25

A sandbox/apply-patch probe succeeded after the manual repair.

Expected behavior

Codex Desktop updates should not reintroduce sandbox/helper launch failures. The helper should ship with a durable manifest/launcher strategy that avoids Windows installer/elevation heuristics, or Codex should handle this setup path without requiring per-version, per-path user registry hacks.

Actual behavior

Updating Codex Desktop creates a new helper path and can invalidate the known RUNASINVOKER workaround, exposing the user again to the same codex-windows-sandbox-setup.exe modal (The specified module could not be found / 找不到指定的模块) and setup-refresh failures.

Suggested upstream fixes

• Rename the helper so it does not match Windows installer-detection heuristics, or
• embed an explicit asInvoker / correct requestedExecutionLevel manifest, or
• stop relying on setup-style ShellExecute behavior for this helper, or
• implement a durable launcher/compatibility strategy owned by Codex rather than by each user.

Related issues

This appears related to the existing Windows sandbox/helper family, but the specific regression here is update churn invalidating a per-path workaround:

• Windows sandbox failed spawn setup refresh OS error 740 #25362
• Windows Desktop node_repl fails with os error 740 due to UAC installer detection on codex-windows-sandbox-setup.exe #26477
• Windows app 26.616.3309.0: native sandbox setup helper fails with “The specified module could not be found #28982
• Cannot find the specified module codex-windows-sandbox-setup.exe #29089
• Windows Desktop: codex-windows-sandbox-setup.exe dialog appears on apply_patch after 26.616 update #29200
• [Windows] codex-windows-sandbox-setup.exe fails with "The specified module could not be found" #29418
• Windows sandbox helper launch fails after update: ShellExecuteExW 1223 #29115
• Windows Codex Desktop 26.616.4196.0 regression: apply_patch / fs-helper fails when global proxy env is set #29178