Windows Desktop regression: generated `apply_patch.bat` calls inaccessible WindowsApps `codex.exe` instead of local `CODEX_CLI_PATH`

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

26.616.51431

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0

What issue are you seeing?

### This may be related to existing Windows sandbox/apply_patch issues such as #29200, but I am opening this separately because I found a more specific root-cause signal: the generated temporary apply_patch.bat wrapper points to the protected WindowsApps-packaged codex.exe, which returns Access is denied when run directly, while the local cached Codex CLI path from CODEX_CLI_PATH runs successfully.

Summary

On Codex Desktop for Windows, apply_patch fails because the generated temporary apply_patch.bat wrapper points to the packaged codex.exe under C:\Program Files\WindowsApps\..., which cannot be executed directly from my user/shell context and returns Access is denied.

A local cached Codex CLI binary exists and runs successfully from:

C:\Users\a******\AppData\Local\OpenAI\Codex\bin\8e55c2dd143b6354\codex.exe

So the issue appears to be that the generated apply_patch.bat wrapper is using an inaccessible WindowsApps package path instead of the accessible local cached CLI path / CODEX_CLI_PATH.

Environment
OS: Microsoft Windows 10.0.26200.8655
Codex Desktop app version seen in config: 26.616.51431 / later package path 26.616.6631.0
Codex CLI local cached version: codex-cli 0.142.0-alpha.6
Windows sandbox config:
[windows]
sandbox = "unelevated"

Relevant config value from ~\.codex\config.toml:

CODEX_CLI_PATH = 'C:\Users\a***\AppData\Local\OpenAI\Codex\bin\8e55c2dd143b6354\codex.exe'
Symptoms**

When Codex tries to use apply_patch, it reports that the Windows sandbox wrapper / local apply_patch tool refused to run. The fallback also fails.

Example Codex output:

The local apply_patch tool technically refused to run in the new Windows sandbox profile; I will apply the same unified patch via git apply without expanding the file scope.

Then git apply fails because the input is in apply_patch format, not standard diff --git format:

error: No valid patches in input (allow with "--allow-empty")

When Codex tries the generated apply_patch.bat directly, it fails with:

Access is denied.
Investigation

Codex generated this temporary wrapper:

C:\Users\a*****\.codex\tmp\arg0\codex-arg0vPR7Mj\apply_patch.bat

Get-Command apply_patch resolves to:

Get-Command apply_patch -ErrorAction SilentlyContinue | Select-Object -ExpandProperty Source

Output:

C:\Users\a*****\.codex\tmp\arg0\codex-arg0vPR7Mj\apply_patch.bat

The contents of the generated wrapper are:

@echo off
"C:\Program Files\WindowsApps\OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0\app\resources\codex.exe" --codex-run-as-apply-patch %*

Running this wrapper manually also fails:

& "C:\Users\a*****\.codex\tmp\arg0\codex-arg0vPR7Mj\apply_patch.bat"

Output:

Access is denied.

The wrapper file itself appears to have correct ACLs:

icacls "C:\Users\a*****\.codex\tmp\arg0\codex-arg0vPR7Mj\apply_patch.bat"

Output:

C:\Users\a****\.codex\tmp\arg0\codex-arg0vPR7Mj\apply_patch.bat NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
DESKTOP-**\a***:(I)(F)

Successfully processed 1 files; Failed processing 0 files

There is also no Zone.Identifier stream on the wrapper:

Get-Item "C:\Users\a*****\.codex\tmp\arg0\codex-arg0vPR7Mj\apply_patch.bat" -Stream *

Output only shows:

Stream: :$DATA

So the .bat itself does not seem to be blocked.

The failing executable appears to be the WindowsApps-packaged codex.exe referenced inside the wrapper.

Running the packaged WindowsApps codex.exe directly fails:

& "C:\Program Files\WindowsApps\OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0\app\resources\codex.exe" --version

Output:

Program 'codex.exe' failed to run: Access is denied.
CategoryInfo : ResourceUnavailable: (:) [], ApplicationFailedException
FullyQualifiedErrorId : NativeCommandFailed

But the local cached CLI binary runs successfully:

& "C:\Users\a*****\AppData\Local\OpenAI\Codex\bin\8e55c2dd143b6354\codex.exe" --version

Output:

codex-cli 0.142.0-alpha.6
What I already tried

I checked and/or cleared the usual local causes:

• No ~/.codex/.env file exists
• No proxy env vars from set | findstr /I proxy
• Cleared ~/.codex/.sandbox
• Cleared ~/.codex/.sandbox-bin
• Cleared ~/.codex/.sandbox-secrets
• Checked Windows Defender Protection History; no recent blocks
• The generated apply_patch.bat has correct ACLs
• The generated apply_patch.bat has no Zone.Identifier stream

The issue remains.

Expected behavior

The generated apply_patch.bat should call an executable path that is accessible from the current sandbox/session/user context.

For example, it could use the local cached CLI path already present in config / environment:

C:\Users\a******\AppData\Local\OpenAI\Codex\bin\8e55c2dd143b6354\codex.exe

instead of the protected WindowsApps package path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
Actual behavior

The generated apply_patch.bat points to the WindowsApps packaged codex.exe, which fails with Access is denied, causing apply_patch to fail.

Possible root cause

The apply_patch.bat wrapper generation may be using the packaged app resource path instead of the accessible local cached CODEX_CLI_PATH.

This seems related to Windows packaged app / WindowsApps execution restrictions. The packaged binary exists but cannot be launched directly from the user context, while the local cached CLI binary works.

Possible fix

When generating apply_patch.bat on Windows Desktop, prefer the accessible local cached Codex CLI path, such as CODEX_CLI_PATH, instead of the protected WindowsApps package path.

Temporary manual workaround that appears logically correct:

@echo off
"C:\Users\a*******\AppData\Local\OpenAI\Codex\bin\8e55c2dd143b6354\codex.exe" --codex-run-as-apply-patch %*

instead of:

@echo off
"C:\Program Files\WindowsApps\OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0\app\resources\codex.exe" --codex-run-as-apply-patch %*

However, this is only a temporary workaround because Codex regenerates these wrappers under ~\.codex\tmp\arg0\codex-arg0....

Possible trigger / correlation:

I also noticed this started around the time Windows updated/installed “Windows App Runtime Main.2” on my machine. I am not claiming that this is definitely the root cause, but it may have changed or exposed packaged app / WindowsApps execution behavior.

However, the direct evidence is that the generated apply_patch.bat points to the WindowsApps-packaged codex.exe, and that executable cannot be launched directly from PowerShell (Access is denied), while the local cached Codex CLI path runs successfully.

What steps can reproduce the bug?

All you have to do is ask Codex to edit an existing file

What is the expected behavior?

_No response_

Additional information

Possible fix:

The issue may be in the Windows apply_patch.bat wrapper generator. It currently writes the protected WindowsApps codex.exe path into the wrapper, but that executable cannot be launched directly and returns Access is denied.

Using the local cached CLI path from CODEX_CLI_PATH instead may fix it, since that binary runs successfully on the same machine.