Windows Codex App: apply_patch fails because codex-windows-sandbox-setup.exe cannot launch from package path

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

26.616.3767.0

What subscription do you have?

Redacted / not included

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Summary

On Windows, every apply_patch call in the Codex desktop app fails, even for a normal temporary file inside the workspace. The failure is reproducible and is not related to patch content or the target file.

Observed Codex error

apply_patch verification failed: Failed to read file to update <workspace>\.tmp-apply-patch-diagnostic.txt: fs sandbox helper failed with status exit code: 1: windows sandbox failed: orchestrator_helper_launch_canceled: ShellExecuteExW failed to launch setup helper: 1223

Observed Windows dialog

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

The specified module could not be found.

What has already been verified

The helper file exists at the package path.
Restarting Codex does not fix the problem.
Reinstalling Codex does not fix the problem.
Normal shell read/write in the workspace still works.
apply_patch fails for any target file, not just one specific repository file.
Launching the helper directly from the package path is blocked by package ACLs, but copying the exact same binary to a normal workspace path allows it to start and print argument parsing errors.
The copied helper has the same SHA256 hash as the packaged helper.

Important observation

Copying codex-windows-sandbox-setup.exe out of C:\Program Files\WindowsApps to a normal writable path allows it to run. For example, running the copied binary without arguments prints:

Error: helper_request_args_failed: expected payload argument

This suggests the helper binary itself is not generally broken and does not have a universal missing-DLL problem. The issue appears to happen specifically when Codex launches the helper from the packaged WindowsApps / AppContainer context.

Chinese version

在 Windows 上，Codex 桌面版中的所有 apply_patch 调用都会失败，即使目标只是工作区里的一个普通临时文件。这个问题可以稳定复现，和补丁内容或目标文件本身无关。

已观察到的 Codex 错误：

apply_patch verification failed: Failed to read file to update <workspace>\.tmp-apply-patch-diagnostic.txt: fs sandbox helper failed with status exit code: 1: windows sandbox failed: orchestrator_helper_launch_canceled: ShellExecuteExW failed to launch setup helper: 1223

Windows 弹窗：

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

找不到指定的模块。

已确认：

helper 文件本体存在。
重启 Codex 无法修复。
重装 Codex 无法修复。
普通 shell 对工作区文件的读写正常。
apply_patch 对任意文件都失败，不是某个仓库文件的个例。
直接从包路径启动 helper 会被包权限限制，但把同一个二进制复制到普通工作区路径后可以正常启动，并输出参数解析错误。
复制后的 helper 与包内 helper 的 SHA256 完全一致。

关键信息：把 codex-windows-sandbox-setup.exe 从 C:\Program Files\WindowsApps 复制到普通可写路径后，它是可以运行的，例如无参数运行会输出：

Error: helper_request_args_failed: expected payload argument

这说明 helper 二进制本体并没有普遍性损坏，也不像是一个通用的缺 DLL 问题。问题更像发生在 Codex 从 WindowsApps / AppContainer 上下文中启动该 helper 的这条集成链路上。

What steps can reproduce the bug?

Open Codex desktop app on Windows.
In any workspace, invoke apply_patch on a normal file, including a temporary text file.
Observe that the tool fails immediately before patch application.
A Windows dialog may appear referencing codex-windows-sandbox-setup.exe and saying that the specified module could not be found.

Minimal reproduction target used during debugging:

.tmp-apply-patch-diagnostic.txt

Anonymous reproduction notes:

Personal account identifiers removed
Local workspace path redacted in the main error excerpt

What is the expected behavior?

apply_patch should be able to edit normal workspace files successfully. If the helper cannot be launched from the packaged environment, Codex should either recover gracefully or provide a more actionable error that identifies the exact failing dependency or launch condition.

Additional information

Likely scope based on local investigation:

The helper binary itself can run when copied outside the package path.
The failure appears specific to the packaged WindowsApps / AppContainer launch path.
This may point to helper launch integration, working directory or environment setup, or package-context resource resolution rather than a corrupted helper binary.

Potential developer debugging directions:

Check the exact helper launch parameters and working directory used by the app
Check whether the helper depends on relative resources when launched from the package
Trace file and DLL lookups during helper startup from the packaged environment

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

Windows app 26.616.3767.0: elevated sandbox setup helper still fails with “The specified module could not be found” #29053
Windows app 26.616.3309.0: native sandbox setup helper fails with “The specified module could not be found #28982

Powered by Codex Action

Potential duplicates detected

They aren't duplicates since the #28982 is pointing to the 26.616.3309.0 version, but the newest 26.616.3767.0 still have this issue. Here is my comment about the current app version #28982 (comment)

I experience the same issue since yesterday, but the popup Windows error is different: COM HRESULT 0x80110474: “COM+ registry database detected a system error.

@eliotcougar

@eliotcougar I think you need to create a new issue, because this issue is about specific apply_patch error

Update after installing Codex Windows app 26.616.4196.0:

The issue still reproduces on my machine.

I used /feedback in all chats where I have this error. Feedback IDs:

019edf2b-4a04-7490-9fd0-2fd746beb640
019eb0d0-55a8-7b71-95c5-1167902c4a60
019e9e55-653c-7410-8d93-92c98e2311c9
019edf2b-4a04-7490-9fd0-2fd746beb640

Still reproducible after updating to Codex App 26.616.4196.0.

The Windows dialog still reports:
codex-windows-sandbox-setup.exe
"The specified module could not be found."

Normal shell commands work, but apply_patch hangs/fails.

See if you have "proxy_ports": [] array set to anything other than empty in .codex\.sandbox\setup_marker.json.
In my case, setting it to empty fixed very similar apply_patch failures that started happening after update to 26.616

One caveat: I have a proxy set in .codex\.env and every time Codex runs any elevated shell command, the port gets added back to setup_marker.json and apply_patch stops working again.

The solution was found by Codex after about 30 minutes of investigating its own failures on extra-high.

@eliotcougar

@eliotcougar

The solution was found by Codex after about 30 minutes of investigating its own failures on extra-high.

This is just crazy, because I also spent 2% of my limit tracking this problem.

See if you have "proxy_ports": [] array set to anything other than empty in .codex\.sandbox\setup_marker.json

In my file, the port was set to 2080 (the default port for the Throne app), and I can confirm that removing it helps, but it's required for the Codex mobile app to work due to my specific network setup. Everything worked fine before, so this is a bug that OpenAI needs to fix.

@eliotcougar

The solution was found by Codex after about 30 minutes of investigating its own failures on extra-high.

This is just crazy, because I also spent 2% of my limit tracking this problem.

See if you have "proxy_ports": [] array set to anything other than empty in .codex\.sandbox\setup_marker.json

In my file, the port was set to 2080 (the default port for the Throne app), and I can confirm that removing it helps, but it's required for the Codex mobile app to work due to my specific network setup. Everything worked fine before, so this is a bug that OpenAI needs to fix.

You are right.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.

This proxy-exclude setup works for me! Here's my summarized workaround solution:
#30009 (comment)

See if you have "proxy_ports": [] array set to anything other than empty in .codex\.sandbox\setup_marker.json. In my case, setting it to empty fixed very similar apply_patch failures that started happening after update to 26.616

One caveat: I have a proxy set in .codex\.env and every time Codex runs any elevated shell command, the port gets added back to setup_marker.json and apply_patch stops working again.

The solution was found by Codex after about 30 minutes of investigating its own failures on extra-high.

thanks

alright that may sound stupid but here's what fixed the issue on my end :
i didn't wanted to disable the elevated sandbox. furthermore, the shell_environment_policy.exclude workaround didn't work for me, probably because it doesn't exist.
i just ended up disabling features.network_proxy and emptying one last time proxy_ports in the setup_marker.json, and that fixed it. network_proxy is an experimental feature anyway and idk why it seemed to be enabled by default in my config while it shouldn't had (i probably messed up with the /experimental command and thought to myself like a dumbass "oh yeah surely this is cool"). after reading its doc i don't think i have any use case for it personally so better keep it off

shell_environment_policy.exclude workaround didn't work for me, probably because it doesn't exist.

What do you mean it doesn't exist? It's right there in the table you linked. And btw, you need to clear the proxy port from the setup_marker.json manually after you add the exclude setting. That's what actually helped your case, probably.

my bad, I looked at network_proxy.exclude lol
I did indeed had all config keys setup properly and did clean the array but after any tool call (like apply_patch) it would be filled right back

here is my test:
windows codex cli, since version v0.140.0 to latest(2026-7-7). if sandbox='evleated', apply_patch will fail and popup that sandbox error window.
If you don't want to take the risk of unelevated sandbox setting,
temp solution: roll back to v0.139.0.

modify ".codex\config.toml",change sandbox = "elevated" to "unelevated",this may help

The update to 26.623.141536 was supposed to fix this, but it didn't. However, in my case the COM+ crash disappeared on one machine, but it kept crashing on another machine. So, I looked to see what was different...

sandbox = "elevated"
sandbox_mode = "workspace-write"
sandbox_workspace_write.network_access = true
http_proxy and https_proxy env variables present
shell_environment_policy.exclude workaround removed

Here's what helped:
sandbox_workspace_write.network_access = true
After that, apply_patch works, no COM+ errors, no proxy port being added to setup_marker.json when shell commands run.
It still crashes with network_access = false after the proxy port is written to setup_marker.json.

I reproduced one concrete helper-launch failure mode and prepared a focused red-to-green patch. I initially suspected spaces in the user-profile path, but the failure appears to be in sandbox-helper startup instead.

Reproduction

Using the packaged codex-cli 0.144.0-alpha.4 with:

a fresh isolated CODEX_HOME (no setup marker or cached sandbox state),
elevated workspace-write,
a real Git workspace under C:\Users\Dell Optiplex 7080\codex cli main repro, and
an instruction requiring apply_patch only,

both patch attempts failed before the target file could be read:

apply_patch verification failed: Failed to read
C:\Users\Dell Optiplex 7080\codex cli main repro\probe.txt:
fs sandbox helper failed with status exit code: 1:
windows sandbox failed:
orchestrator_helper_launch_canceled:
ShellExecuteExW failed to launch setup helper: 1223

The file remained unchanged and the fresh home never received a completed setup marker.

As a viability check, the same packaged binaries successfully patched the same spaced workspace from a normal filesystem location after sandbox setup completed. This does not isolate the inherited cwd, but it shows that neither the binaries nor spaces alone cause the failure.

Root cause found

In current source, run_setup_refresh_inner creates Command::new(&exe) for codex-windows-sandbox-setup.exe without setting current_dir. The setup helper therefore inherits the active workspace as its process cwd.

The helper must prepare sandbox access, but it is launched from the workspace before that access is ready.

Proposed fix

Set the setup helper's process cwd independently of the workspace:

use the helper executable's parent directory when its path is resolved;
for a bare helper filename, fall back to the current Codex executable's directory;
retain CODEX_HOME as the final fallback.

The real workspace remains in the setup payload, so this changes only the bootstrap process cwd, not the sandbox policy or target workspace.

I also prepared regression coverage that:

removes the existing Windows skip from the unified-exec apply_patch test;
creates a real Git workspace beneath a long-form Windows path containing spaces;
enables the elevated Windows sandbox with an explicit workspace-write root;
verifies patch begin/end events, successful output, and resulting file contents; and
adds a reusable TestCodexBuilder::with_cwd fixture hook so Windows tests do not silently collapse to an 8.3 short temp path.

Before rebasing, I verified:

elevated spaced-path apply_patch regression: passes after the fix;
Windows sandbox setup tests: 31 passed;
cargo fmt --all -- --check: passed;
cargo clippy --tests -p codex-windows-sandbox -- -D warnings: passed;

After verification, the branch was cleanly rebased onto current main and contains one commit.

This patch addresses the inherited-working-directory failure mode. It may not cover the separate proxy, refresh-race, WindowsApps ACL, or COM+ failures discussed above.

I understand external PRs are invitation-only. Would a maintainer like me to submit this focused patch?

The update to 26.623.141536 was supposed to fix this, but it didn't. However, in my case the COM+ crash disappeared on one machine, but it kept crashing on another machine. So, I looked to see what was different...

sandbox = "elevated" sandbox_mode = "workspace-write" sandbox_workspace_write.network_access = true http_proxy and https_proxy env variables present shell_environment_policy.exclude workaround removed

Here's what helped: sandbox_workspace_write.network_access = true After that, apply_patch works, no COM+ errors, no proxy port being added to setup_marker.json when shell commands run. It still crashes with network_access = false after the proxy port is written to setup_marker.json.

Apply Patch in Codex suddenly stopped working for me and adding this line in the config.toml file seems to have fixed it for me. Thank you!

Reproduced on a newer Microsoft Store/AppX build during first elevated-sandbox setup on a fresh standard local Windows account.

Environment

Windows 10 Home 22H2, build 19045, x64
AppX package: OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0
Package status: Ok
Fresh standard-user profile with no prior sandbox setup state
Elevated Windows sandbox selected; network access intentionally disabled

Observed behavior

The first setup attempt shows the Windows dialog naming:

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

The specified module could not be found.

Setup stops before a sandbox log is created.

Checks performed

The exact helper path exists inside the registered package.
Helper size: 8,803,120 bytes.
SHA-256: 400CF60D47A8F865E33E43815ECADF3369FE71C4AB830C712AA9E949D6B06AE1.
Authenticode status: Valid.
Signer: OpenAI OpCo, LLC.
%USERPROFILE%\.codex\.sandbox\sandbox.log does not exist after the failed setup.
No machine-wide CODEX_HOME or CODEX_SQLITE_HOME override is present.
Windows reports the AppX volume and package as online/healthy.

We did not manually execute or copy the helper, use Repair/Reset/reinstall, take ownership of WindowsApps, change ACLs, disable Defender, alter the sandbox/network settings, or test against existing workspaces.

This confirms that the WindowsApps/helper-launch failure still occurs in AppX 26.721.3996.0, with a present, readable, validly signed helper, and can occur before sandbox diagnostic logging initializes.

guys disable just disable features.network_proxy in your codex.toml, this genuinely fixes it. Network proxy is still experimental (you can also disable it by running codex, /experimental and disable "Network proxy")

I reproduced and investigated what appears to be an additional WindowsApps launch failure mode for this issue. The findings below are privacy-sanitized.

Environment and A/B evidence

Codex is installed as the Windows AppX/Desktop package under C:\Program Files\WindowsApps\....
Launching the packaged codex.exe or codex-windows-sandbox-setup.exe as a child process from its package path fails before the helper payload runs (Access is denied / the Windows “specified module could not be found” dialog, depending on the launch path).
Copying the exact same executable outside WindowsApps allows it to start. The copied setup helper reaches its expected argument-validation error when invoked without a payload. The source and copied files have identical hashes.
A temporary PowerShell apply_patch alias that dispatches to the executable outside WindowsApps successfully applied a real multiline patch to a workspace file. The existing batch alias also loses/corrupts literal multiline patch arguments in PowerShell, while the .ps1 alias preserves them.

This suggests the executable itself is valid and that the package location/child-launch context is the important difference.

Current source paths

I checked current main at 2ca575026cef066a58c70f6bdee4feafa6e63d3a on August 15, 2026.

In codex-rs/arg0/src/lib.rs, the Windows apply_patch.bat alias is still generated against std::env::current_exe() directly. For a Desktop/AppX launch, that can leave the alias pointing at the packaged WindowsApps codex.exe:

let exe = std::env::current_exe()?;
let batch_script = path.join(format!("{filename}.bat"));

The repository already has executable materialization support in windows-sandbox-rs/src/helper_materialization.rs, including resolve_exe_for_launch, but it is not used by this arg0 alias path.

In codex-rs/windows-sandbox-rs/src/setup.rs, both setup launch paths still resolve the packaged helper directly through find_setup_exe():

let exe = find_setup_exe();

The non-elevated/refresh Command path does not set current_dir, and the elevated ShellExecuteExW path does not set SHELLEXECUTEINFOW.lpDirectory. Therefore the setup helper can both launch from WindowsApps and inherit the active workspace as its process working directory. This complements the inherited-cwd failure mode already reported in this thread.

Suggested focused fix

Detect executables located below a WindowsApps path.
Before generating the Windows arg0 alias, materialize the current codex.exe into CODEX_HOME\.sandbox-bin using the existing helper-copy logic and dispatch the alias to that copy.
Materialize codex-windows-sandbox-setup.exe into the same user-owned helper directory before both refresh and elevated setup launches.
Give setup-helper processes an explicit bootstrap cwd: helper parent first, current Codex executable parent second, and CODEX_HOME as the final fallback.
Set .current_dir(...) for Command and lpDirectory for ShellExecuteExW.
Generate a PowerShell apply_patch.ps1 alias in addition to the compatibility .bat alias so literal multiline patch arguments survive PowerShell command resolution.

I prepared a local focused implementation covering those source paths and unit tests, but have not submitted a PR because external code contributions are invitation-only. I can provide the patch if a maintainer would like to review or integrate it.

This does not claim to replace the proxy-state fixes, refresh coalescing, or other failure modes discussed above; it specifically addresses package-path child launches, helper bootstrap cwd, and PowerShell multiline argument forwarding.

Prototype patch uploaded: https://gist.github.com/LDmoxeii/00358d25f598bc56cc4720198a52e62d

Direct raw patch: https://gist.githubusercontent.com/LDmoxeii/00358d25f598bc56cc4720198a52e62d/raw/codex-windows-apply-patch-fix.patch

SHA-256: CFF48A5C2A5BD9DFBB6BE125B9C6A2C330064DBEBF596AF0E35331BDCFB3EEC8
Base commit: 3360f4a

It covers WindowsApps executable materialization, a PowerShell apply_patch alias, setup-helper materialization, explicit Command cwd and ShellExecuteExW lpDirectory, plus focused unit tests. git diff --check passes and the patch is privacy-sanitized.

It is still a prototype: full Rust compile, clippy and nextest validation have not been completed, and it should be rebased onto current main before integration.

For Windows apply_patch failures with the codex-windows-sandbox-setup.exe launch dialog, the state that matters is in %USERPROFILE%\.codex\.sandbox\setup_marker.json.

Method:

Open %USERPROFILE%\.codex\.sandbox\setup_marker.json and inspect the proxy_ports array.
If it is non-empty, set it to [] and retry apply_patch.
If the port is re-added after every elevated shell call, stop the source that rewrites it: set features.network_proxy = false in config.toml (or drop HTTP_PROXY/HTTPS_PROXY from the elevated environment), then clear proxy_ports once more.
Alternative when the proxy must stay: set [windows] sandbox = "unelevated" in config.toml to bypass the elevated helper launch path.

Evidence: verified locally on Codex Desktop 26.810.7004.0 — with proxy_ports: [] the helper launches from the package path and completes (setup binary completed in the sandbox log), and the thread confirms clearing a non-empty proxy_ports restores apply_patch. Independent community workaround; not an official OpenAI fix.

Navigation Menu

Repository navigation

Windows Codex App: apply_patch fails because codex-windows-sandbox-setup.exe cannot launch from package path #29072

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

21 remaining items

Reproduction

Root cause found

Proposed fix

Environment

Observed behavior

Checks performed

Environment and A/B evidence

Current source paths

Suggested focused fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows Codex App: apply_patch fails because codex-windows-sandbox-setup.exe cannot launch from package path #29072

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jun 19, 2026

Batarbin commented on Jun 19, 2026

eliotcougar commented on Jun 19, 2026

Batarbin commented on Jun 19, 2026

CZH0919 commented on Jun 19, 2026

Batarbin commented on Jun 19, 2026

kurohu commented on Jun 19, 2026

eliotcougar commented on Jun 19, 2026

Batarbin commented on Jun 19, 2026

CZH0919 commented on Jun 19, 2026

21 remaining items

alexzhuustc commented on Jul 2, 2026

ZhuWenxuan123code commented on Jul 2, 2026

EDM115 commented on Jul 2, 2026

eliotcougar commented on Jul 2, 2026

EDM115 commented on Jul 2, 2026

uncleyoung commented on Jul 7, 2026

lemoray commented on Jul 7, 2026

eliotcougar commented on Jul 8, 2026

dizruptr commented on Jul 12, 2026

Reproduction

Root cause found

Proposed fix

jmarcel12 commented on Jul 22, 2026

CTheRain commented on Jul 24, 2026

Environment

Observed behavior

Checks performed

EDM115 commented on Jul 24, 2026

LDmoxeii commented on Aug 15, 2026

Environment and A/B evidence

Current source paths

Suggested focused fix

LDmoxeii commented on Aug 15, 2026

naipi11 commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions