›_ Codex Issues
Codex Issues / #13959

Windows desktop app: apply_patch fails because wrapper launches packaged resources\\codex.exe and gets "Access is denied"

Resolved 💬 7 comments Opened Mar 8, 2026 by jianzhangg Closed Mar 8, 2026
💡 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.306.996.0

What subscription do you have?

Free

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

On Windows, apply_patch consistently fails in the Codex desktop app before any patch is applied. The generated apply_patch.bat wrapper points to the packaged desktop executable under C:\Program Files\WindowsApps\..., and invoking that wrapper returns Access is denied. As a result, apply_patch exits with code 1 and no file is created. This appears to be specific to the Windows desktop app execution chain, not to patch syntax, workspace state, or Codex CLI.

What steps can reproduce the bug?

  1. Open the Codex desktop app on Windows.
  2. Ask Codex to apply a minimal patch such as:
*** Begin Patch
*** Add File: app_apply_patch_probe.txt
+probe
*** End Patch
  1. Observe that apply_patch fails with exit code 1.
  2. Confirm that app_apply_patch_probe.txt was not created.
  3. Inspect the generated wrapper script under:
%USERPROFILE%\\.codex\\tmp\\arg0\\<latest>\\apply_patch.bat
  1. The wrapper points to:
"C:\Program Files\WindowsApps\OpenAI.Codex_26.306.996.0_x64__2p2nqsd0c76g0\app\resources\codex.exe" --codex-run-as-apply-patch %*
  1. Run that wrapper manually with any dummy argument.
  2. It returns:
Access is denied.

Control comparison:

  • If the desktop app is uninstalled, the generated wrapper switches to the CLI/vendor Codex executable instead of the WindowsApps packaged executable.
  • In that state, apply_patch can at least reach normal patch parsing.
  • After reinstalling the desktop app, the issue returns immediately.

What is the expected behavior?

apply_patch should either apply the patch successfully or at least reach normal patch parsing and return a validation error if the patch is malformed. It should not fail before parsing or file writing.

Additional information

Additional evidence:

  • The desktop app itself can successfully spawn the packaged resources\\codex.exe for its own stdio app-server handshake.
  • A desktop log shows:
stdio_transport_spawned executablePath="C:\Program Files\WindowsApps\OpenAI.Codex_26.306.996.0_x64__2p2nqsd0c76g0\app\resources\codex.exe"

So the failure seems specific to the external apply_patch.bat helper path that directly launches the packaged executable.

Workaround:

  • Using Codex CLI instead of the desktop app avoids the problem.
  • The CLI/vendor Codex executable is able to handle --codex-run-as-apply-patch normally, while the desktop app generated wrapper fails when it targets the packaged WindowsApps executable.

Other notes:

  • This is reproducible on a personal Windows laptop.
  • This does not appear to be caused by patch content.
  • Reinstalling the same desktop app version did not fix it.
  • The failure reappears immediately after reinstall once the wrapper points back to the packaged WindowsApps executable.

Possibly related issues:

  • #2710
  • #2794
  • #6090
  • #7298

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 4 months ago

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

  • #13542
  • #13840
  • #13905

Powered by Codex Action

tornupgaming · 4 months ago

I'm wondering whether it's a permissions issue in Windows Store apps. For example; I can't mess about with the files in C:\Program Files\WindowsApps\OpenAI.Codex_26.305.950.0_x64__2p2nqsd0c76g0 even in an admin terminal, so perhaps there's a mismatch between the permissions the Codex app has, the permissions the Microsoft Store grants, and the permissions the spawned shell instance has. I'm completely spitballing here, but traditionally one of the few issues I have with developing on Windows is the permissions system.

etraut-openai contributor · 4 months ago

Thanks for reporting. This is a known issue, and a fix will be included in the next release.

pineconehippopotamus · 4 months ago

The files I'm trying to edit aren't even in a Program Files directory just in C:/Projects and I still get access denied. Windows Store sucks. Then I'm sure it'll take ages for them to approve the next update that may not even resolve it.

TenofHearts · 4 months ago

I also face the same issue in the VS Code extension. Also, apply_patch seems to only consistently fail for some specific projects, while working fine for others.

ZHLONG321 · 1 month ago

same in codex app after update to latest version in windows store.

MM1nd · 1 month ago

@etraut-openai

Sorry but this is _not_ fixed in Version 26.616.30709 • Released 18.06.2026 and it does not look like a duplicate of the issue you linked

User: 
What exactly is broken?

Codex (Desktop):
The Windows filesystem sandbox is failing specifically when apply_patch tries to modify existing files inside the nested Git repository.
Two failure modes occurred:
Built-in patch tool:
windows unelevated restricted-token sandbox cannot enforce split writable root sets directly

Calling the patch utility from PowerShell:
Zugriff verweigert (Access denied)

"The patch utility" is a .bat file Codex created on the fly. I think it is a red herring.

User (after some back and forth):
ignore the powershell fallback. What error did you get when using the internal apply_patch

Codex:
The internal apply_patch error was:
apply_patch verification failed:
Failed to read file to update
[redacted]

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

Not sure if we are now entering hallucination territory:

User (after some back and forth):
which permissions profile?

The managed filesystem permission profile injected into this Codex session’s environment metadata—not a file in your repository.
It declares:
read:  :root
write: [redacted]
write: :slash_tmp
write: :tmpdir
read:  [redacted]\.git
read:  [redacted]\.agents
read:  [redacted]\.codex
I should clarify: I inferred that these overlapping entries might explain “split writable root sets.” The error itself does not identify which entries caused it.