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.

This looks like a helper-launch support boundary, not only an apply_patch failure.

The runtime should separate:

apply_patch requested
≠
sandbox helper launch path is supported

In the report, the helper binary appears to exist and is not generally broken:

• the helper exists at the packaged WindowsApps path
• normal shell read/write still works
• apply_patch fails for every target file
• copying the same helper binary outside WindowsApps lets it start
• the copied helper has the same SHA256 hash
• the failure appears only when Codex launches it from the packaged WindowsApps / AppContainer context

So the required support for apply_patch is not only:

workspace file is writable

It is also:

sandbox helper can be launched from the current package context.

Minimal invariant:

ApplyPatchDispatch is valid only if:

• target path is inside writable workspace
• patch parses successfully
• fs sandbox helper path resolves
• helper binary exists
• helper launch context is supported
• helper dependencies/resources are resolvable from that context
• helper terminal outcome is observable

A useful local classifier:

def classify_apply_patch_support(env):
required = {
"target_inside_writable_workspace",
"patch_parse_supported",
"helper_path_resolved",
"helper_binary_exists",
"helper_launch_context_supported",
"helper_dependencies_resolvable",
"helper_terminal_outcome_supported",
}

supported = set(env.get("supported", []))
missing = required - supported

if missing:
return {
"decision": "block_apply_patch",
"reason": "apply_patch_support_missing",
"missing_support": sorted(missing),
}

return {
"decision": "dispatch_apply_patch",
"missing_support": [],
}

Regression cases:

1. helper exists in WindowsApps but ShellExecuteExW returns launch failure

=> local helper_launch_context_unsupported diagnostic

1. same helper copied outside WindowsApps starts successfully

=> classify binary as present, not corrupted

1. normal shell read/write succeeds but helper launch fails

=> do not classify as generic workspace write failure

1. apply_patch fails before patch application

=> do not classify as patch parse / patch content failure

1. helper launch fails from packaged context

=> report exact failing layer: launch context, dependency lookup, working directory, or resource resolution

The key boundary is:

workspace write permission and valid patch content are not enough.

apply_patch is supported only when the sandbox helper can be launched and observed from the current packaged runtime context. If that support layer is missing, Codex should emit a named local diagnostic such as helper_launch_context_unsupported instead of presenting it as a generic patch verification failure.

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 think this issue can be closed only if the fix treats apply_patch as a helper-launch support problem, not as a patch-content or workspace-write problem.
The current evidence separates the layers:
workspace file read/write can work;
patch content can be valid;
the helper binary can exist;
the same helper binary can run when copied outside WindowsApps;
failure appears when Codex launches the helper from the packaged WindowsApps / AppContainer context;
on some machines, sandbox_workspace_write.network_access = true changes the outcome, which suggests that setup/proxy/network/resource initialization may be coupled to the helper launch path.
So the final fix should not be only “retry apply_patch” or “tell users to change sandbox mode.”
The runtime should explicitly validate the support chain before dispatching apply_patch.
Minimal support chain:
target file is inside writable workspace;
patch parses successfully;
helper path resolves;
helper binary exists;
helper binary hash/signature matches expected package version;
helper launch context is supported from the current runtime context;
helper dependencies/resources are resolvable from that context;
working directory/environment are explicitly set;
proxy/setup_marker/network initialization is not required for local patching unless explicitly supported;
helper terminal outcome is observable and mapped to a named diagnostic.
Definitive implementation direction:
Add a preflight check before apply_patch.
Before attempting to patch, Codex should test whether the packaged helper can be launched from the current context with a harmless diagnostic/preflight argument.
If preflight launch fails, do not report a generic patch verification failure.
Report a named local support failure such as:
helper_launch_context_unsupported
or, if the failing layer is known:
helper_dependency_resolution_failed
helper_working_directory_invalid
helper_proxy_setup_requires_network_support
helper_appcontainer_launch_blocked
Separate patch validity from helper launch validity.
The diagnostic should distinguish:
patch parse failure;
target file not writable;
helper not found;
helper exists but cannot launch from packaged context;
helper launched but dependency/resource lookup failed;
helper launched but returned patch failure;
network/proxy/setup_marker dependency unavailable.
Right now these layers can collapse into one user-facing “apply_patch verification failed” path, which hides the real missing support.
Stage the helper into a supported per-user execution location if packaged launch is unsupported.
If direct launch from WindowsApps is unreliable, Codex should use an app-managed helper staging path such as:
%LOCALAPPDATA%\OpenAI\Codex\helpers\<app_version>\<helper_sha256>\codex-windows-sandbox-setup.exe
Required safeguards:
copy only from the packaged helper;
verify SHA256/signature after copy;
preserve versioned path;
set working directory explicitly;
copy or locate required adjacent resources/dependencies;
never use an arbitrary user-supplied helper;
invalidate the staged helper on app update or hash mismatch.
This avoids treating WindowsApps package-path launch as mandatory support when the same signed helper can run from a normal executable context.
Decouple local apply_patch from network/proxy setup where possible.
A local workspace patch should not require network support unless the helper initialization path truly depends on it.
If sandbox_workspace_write.network_access = false causes the helper path to crash because proxy/setup metadata is written to setup_marker.json, that should be represented as a separate support dependency, not as a patch failure.
Either:
make local patch helper launch independent from proxy/network setup;
or:
explicitly block with a named diagnostic explaining that helper setup requires a support layer that is disabled.
Add regression cases.
Suggested regression matrix:
Helper exists in WindowsApps, but ShellExecuteExW returns launch failure
Expected: helper_launch_context_unsupported, not generic patch failure.
Same helper copied to managed cache path runs successfully
Expected: staged helper path is used after hash/signature verification.
Workspace read/write succeeds but helper launch fails
Expected: not classified as workspace-write failure.
Patch content is valid but helper cannot launch
Expected: not classified as patch-parse failure.
Network access disabled and proxy/setup_marker initialization is required
Expected: named diagnostic, not generic COM+ / patch verification failure.
Helper launches but patch fails internally
Expected: true patch failure diagnostic.
The key invariant is:
apply_patch is supported only when the sandbox helper can be launched, resolved, observed, and completed from the current packaged runtime context.
Workspace write permission and valid patch content are necessary but not sufficient.
So the user-facing rule should become:
If patch content and target writability are valid, but the helper cannot launch from the packaged runtime context, Codex should either use a verified staged helper path or stop with a named helper-launch support diagnostic.
That would close the issue structurally: not by relying on a user workaround, but by making apply_patch dispatch conditional on the actual support required by the helper execution path.
Best,
Massimiliano Brighindi

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?