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

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

• #29053
• #28982

Powered by Codex Action

Potential duplicates detected

They aren't duplicates since the https://github.com/openai/codex/issues/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 https://github.com/openai/codex/issues/28982#issuecomment-4750312054

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 I think you need to create a new issue, because this issue is about specific apply_patch error

<img width="1140" height="404" alt="Image" src="https://github.com/user-attachments/assets/016ccc4f-f042-4a23-9bcc-3201f92b35e5" />
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

<img width="561" height="198" alt="Image" src="https://github.com/user-attachments/assets/76e84ffb-ae60-4099-aa9b-f3f6b952e677" />

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

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:

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

Adding another Windows data point that may connect this issue with #25488.

On my machine, apply_patch was failing while normal shell read/write in the workspace still worked. The important difference from the original report is that my config had an old workaround from the node_repl / Computer Use sandbox failure class:

[windows]
sandbox = "unelevated"

With that setting active, apply_patch could create a new file, but update/delete operations on existing files failed with:

apply_patch verification failed: Failed to read file to update <workspace>\work\sandbox_probe\apply_patch_probe.txt: failed to prepare fs sandbox: failed to prepare windows sandbox wrapper: windows unelevated restricted-token sandbox cannot enforce split writable root sets directly; refusing to run unsandboxed

I then changed the Windows sandbox setting to the elevated path and fully restarted Codex:

[windows]
sandbox = "elevated"

After restart, the same sandbox probe passed:

• apply_patch update on an existing file succeeded
• apply_patch delete succeeded
• apply_patch add succeeded
• normal workspace PowerShell writes still succeeded
• temp writes still succeeded
• outside-workspace writes were still blocked with access denied

So this may be a separate failure path from the package-path helper launch error in the issue description, but it produces the same user-visible pattern: shell filesystem operations work, while apply_patch fails. The connection to #25488 is that sandbox = "unelevated" was previously useful as a workaround for Windows sandbox setup / Computer Use failures, but it can break apply_patch in workspace-write sessions with multiple writable roots.

@codex Same here, quite annoying. Please fix this bug.

feedback ID : 019eee8f-25da-76c3-b940-fca1e4de3de1

Removing "proxy_ports" in setup_marker.json and "http.proxy" in VS code settings solved for me, at least, still valid after several runs.

I hit the same codex-windows-sandbox-setup.exe / The specified module could not be found issue on Windows.

A workaround that fixed apply_patch for me was switching the native Windows sandbox from elevated to unelevated in the Codex config:

[windows]
sandbox = "unelevated"

COM+ registry database detected a system error

same on me , after vscode codex extension updated to 26.616 it appears to show everytime apply_patch

+1

+1

+1

+1

+1

+1

Additional reproduction and local diagnostics (privacy-sanitized):

Environment

• Codex Windows app: 26.623.5546.0 (the issue still reproduces on this newer build)
• Windows 11 x64, build 26200
• sandbox_mode = "workspace-write"
• approval_policy = "on-request"
• [windows] sandbox = "elevated"

Observed failure

windows sandbox failed: orchestrator_helper_launch_canceled:
ShellExecuteExW failed to launch setup helper: 1223

Windows repeatedly shows a modal dialog for the packaged codex-windows-sandbox-setup.exe saying:

The specified module could not be found.

Trigger pattern

• The dialog appears intermittently during bursts of local tool calls.
• Rapid or concurrent tool calls make it appear repeatedly in batches.
• The same operation can fail once and succeed immediately afterward.
• On one diagnostic run, the sandbox log recorded 112 successful setup refresh: processed ...; errors=[] entries on the same day, while the failing ShellExecuteExW attempts were absent from that sandbox log. This suggests those attempts fail before the helper starts and can log for itself.
• The log also contains near-simultaneous duplicate/interleaved setup refresh: spawning ... entries, which may indicate concurrent refresh attempts.

Local checks completed

• Packaged helper exists and is 8,832,304 bytes.
• Authenticode signature is valid and signed by OpenAI OpCo, LLC.
• SHA-256: 2FD812AC28D942461640B7251BF566A7960433253274119CDC9709CF25FDA5E7.
• Helper and parent package directory grant read/execute access to normal users and restricted identities.
• Required Microsoft VCLibs and Windows App Runtime packages are installed.
• Appinfo service is running normally.
• Codex sandbox users exist and are enabled; the offline user successfully logged on during the test.
• Codex sandbox firewall rules exist, are enabled, and parse successfully.
• No relevant Defender detection, Controlled Folder Access block, ASR rule, AppLocker event, or Code Integrity event was found.
• AppModel-Runtime records normal Codex AppContainer creation and process launches.

Current assessment

This looks more like an intermittent race or packaged-launch/context problem in the elevated sandbox setup-refresh orchestration than a missing helper binary, corrupted installation, universal missing DLL, or local security-product block. Reinstalling runtime components or changing package ACLs does not appear justified by the evidence.

It would help if the app could serialize/deduplicate concurrent setup refreshes, capture the precise loader/module failure before returning 1223, retry without showing repeated modal dialogs, and log failures in the outer orchestrator when the helper never starts.

No personal paths, usernames, account identifiers, conversation data, or raw logs are included in this report.

I've solved by trying this post on my machine -> https://www.reddit.com/r/codex/comments/1uccr76/comment/otvxpcs/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

@NoNormalCreeper it worked for me, thanks a lot! So it were proxy vars!

+1. this error only occurs when apply_patch

@NoNormalCreeper sadly this keeps happening for me :(

+1 I hope OpenAI team gives Windows user a little bit more attention

@NoNormalCreeper sadly this keeps happening for me :(

Have you tried the method in the thread below my post? This also seems useful. (temp fix)

this is merely a fix, keeping the sandbox as elevated is ultimately the goal

Judging by some of the commits, I believe the fix is prepared to be included in 0.143.0, but for some reason they're not releasing it yet… Probably will be released together with 5.6...

The better temporary workaround is to add

[shell_environment_policy]
exclude = ["ALL_PROXY", "all_proxy", "HTTP_PROXY", "http_proxy", "HTTPS_PROXY", "https_proxy"]

to the config.toml
But that means shell commands like curl won't use proxy. At least apply_patch will work, though…
You may try instructing Codex to append proxy envs before any shell requests that require network access. In my testing it makes elevated shell commands run with proxy without causing apply_patch to fail afterwards…

This proxy-exclude setup works for me! Here's my summarized workaround solution:
https://github.com/openai/codex/issues/30009#issuecomment-4863258508

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:

1. use the helper executable's parent directory when its path is resolved;
2. for a bare helper filename, fall back to the current Codex executable's directory;
3. 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

1. Detect executables located below a WindowsApps path.
2. 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.
3. Materialize codex-windows-sandbox-setup.exe into the same user-owned helper directory before both refresh and elevated setup launches.
4. Give setup-helper processes an explicit bootstrap cwd: helper parent first, current Codex executable parent second, and CODEX_HOME as the final fallback.
5. Set .current_dir(...) for Command and lpDirectory for ShellExecuteExW.
6. 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: 3360f4a909a920d2e534a63c508d98e91fe6655a

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:

1. Open %USERPROFILE%\.codex\.sandbox\setup_marker.json and inspect the proxy_ports array.
2. If it is non-empty, set it to [] and retry apply_patch.
3. 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.
4. 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.