›_ Codex Issues
Codex Issues / #28393

apply_patch points to WindowsApps codex.exe, causing "Access is denied" on Windows

Open 💬 3 comments Opened Jun 15, 2026 by scyllor
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.609.41114

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

apply_patch is unusable in my Codex Desktop environment on Windows.

The wrapper exists and is found in PATH, but it points to an old codex.exe under C:\Program Files\WindowsApps\..., and invoking it fails with Access is denied.

At the same time, a newer Codex CLI binary exists under C:\Users\<USER>\AppData\Local\OpenAI\Codex\bin\... and works correctly, including --codex-run-as-apply-patch.

This means the Desktop/runtime is still generating a stale apply_patch.bat that targets the wrong executable.

Environment

  • OS: Windows 11
  • Codex Desktop runtime appears to launch from WindowsApps
  • Current date observed: 2026-06-16

What I expected

apply_patch should invoke the current working Codex binary and apply patches normally.

What happened

apply_patch resolves successfully, but execution fails because the generated wrapper points to an old WindowsApps path.

Reproduction details

Get-Command apply_patch shows:

Source      : C:\Users\<USER>\.codex\tmp\arg0\codex-arg0WOzis3\apply_patch.bat
Definition  : C:\Users\<USER>\.codex\tmp\arg0\codex-arg0WOzis3\apply_patch.bat
CommandType : Application

### What steps can reproduce the bug?

1. Install or reinstall Codex Desktop on Windows.
2. Launch Codex Desktop and open a thread/workspace.
3. In the Codex environment, run Get-Command apply_patch and inspect the generated wrapper.
4. Observe that apply_patch.bat points to C:\Program Files\WindowsApps\...\codex.exe.
5. Try invoking apply_patch with even an empty/minimal patch.
6. Observe that it fails with Access is denied.

### What is the expected behavior?

apply_patch should invoke the currently active Codex runtime and apply the patch successfully. After reinstalling or restarting Codex Desktop, the generated apply_patch wrapper should point to the current working Codex binary, not a stale WindowsApps path.

### Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27389

Powered by Codex Action

RolandVyens · 2 months ago

I can reproduce this on Codex App 26.616.3767.0 (codex-cli 0.142.0-alpha.1). I collected a little more evidence that narrows this to the packaged helper launch path rather than a corrupt/stale binary or ordinary NTFS ACL issue.

A freshly generated wrapper points to the package-internal helper:

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

Observed behavior:

  • Calling the generated apply_patch.bat from the integrated PowerShell returns Access is denied (Win32 error 5).
  • Calling that packaged app\resources\codex.exe directly from PowerShell also returns Access is denied.
  • The app package status is Ok, the executable signature is valid, and its ACL includes BUILTIN\Users: ReadAndExecute.
  • No matching Code Integrity or AppLocker denial event is emitted.
  • The manifest registers only app/Codex.exe as Windows.FullTrustApplication; app/resources/codex.exe is not a registered application entry.
  • The working process chain is app/Codex.exe -> app/resources/codex.exe app-server -> powershell.exe. The PowerShell token has no package/capability SID groups, so the subsequent powershell.exe -> apply_patch.bat -> app/resources/codex.exe launch crosses back into the package and is denied.
  • Native functions.apply_patch calls hang in this state, while invoking the wrapper directly exposes the error 5 failure.

There is also a current unpackaged copy at %LOCALAPPDATA%\OpenAI\Codex\bin\5d35d2790d1d3d7b\codex.exe. The packaged and unpackaged binaries have the exact same SHA256:

A5198A90336E5EC5B295819FBB392034B90647B95505142169FD5000EAF433FC

The unpackaged copy runs normally from PowerShell and enters --codex-run-as-apply-patch mode. This suggests the wrapper should target the current unpackaged CLI copy (and be regenerated after app updates), or patch execution should be routed through the already-running app-server instead of re-launching the package-internal helper from an unpackaged shell.

Current workaround: apply the same unified diff with git apply. Related stale-wrapper report: #27389.

yihao5un · 2 months ago

Still reproducing on Codex Desktop (MSIX) 26.616.5445.0 on Windows 11, PowerShell 7.6.2.

The generated shim at C:\Users\<me>\.codex\tmp\arg0\codex-<id>\apply_patch.bat contains:

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

Invoking it (from any shell, including a direct cmd /c "...\codex.exe" --codex-run-as-apply-patch) returns Access is denied. (exit 1). This is the documented Windows behavior for CreateProcess against an exe inside an MSIX package — packaged apps must be launched via their AUMID / execution alias, not by absolute path from an external process.

Confirmed not a permission issue:

  • File ACL grants BUILTIN\Users ReadAndExecute on the exe.
  • Running the same --codex-run-as-apply-patch against the non-Store CLI build at

C:\Users\<me>\AppData\Roaming\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe
succeeds (Success. Updated the following files: M ...).

So the MSIX build of Codex Desktop currently has no working apply_patch path on Windows. The only workarounds I found:

  1. Use the npm/CLI install instead of the Store app.
  2. Or have the agent skip the shim and call codex.exe --codex-run-as-apply-patch <patch> directly (only works for the CLI build; the MSIX exe still gets Access is denied.).

Suggested fix: have the shim launch the packaged app via its execution alias rather than the absolute WindowsApps\...\codex.exe path, or ship a separate non-packaged codex.exe for apply_patch use (similar to how some MSIX apps ship a sidecar tool outside the package).