functions.apply_patch fails silently when the desktop app is installed under C:\Program Files\WindowsApps

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

26.306.996.0

What subscription do you have?

bussiness

What platform is your computer?

windows 11 x64

What issue are you seeing?

On Windows, when the Codex desktop app is installed as a Store/MSIX app under C:\Program Files\WindowsApps, the built-in functions.apply_patch tool fails to apply even the smallest valid patch. The call returns Exit code: 1, produces no stdout/stderr, and does not create or modify any file.

What steps can reproduce the bug?

Open any normal writable workspace.
Call functions.apply_patch with a minimal valid patch such as:
* Begin Patch
* Add File: codex_apply_patch_probe.txt
+apply_patch probe
*** End Patch
Check whether the file was created.
Run git status --short to confirm whether any change was applied.

What is the expected behavior?

functions.apply_patch should successfully create or modify the target file.
If the operation fails, the tool should return a diagnostic error message with enough detail to investigate the cause.

Additional information

Actual Behavior
functions.apply_patch returns Exit code: 1.
No stdout or stderr is returned.
The target file is not created.
git status --short remains unchanged after the operation.
Impact
The standard patch-based editing workflow is unusable in affected Windows installations.
Any feature that depends on functions.apply_patch cannot reliably modify files.
Because the failure is silent, the issue is difficult to diagnose from the user side.
Root Cause Hypothesis
This appears to be related to the app being installed under C:\Program Files\WindowsApps, which is heavily restricted by Windows package and filesystem protections.

A likely failure mode is that the patch bridge/helper process depends on one or more of the following:

executing helper binaries from the packaged app location
creating temporary files relative to the packaged app directory
reading or writing bridge files in locations that are not accessible in the current install model
launching packaged helper tools with assumptions that do not hold inside WindowsApps
If so, the failure is environmental rather than repository-specific or patch-format-specific.

Why This Matters
This is not caused by invalid patch syntax or repository content. A minimal valid patch fails the same way, which suggests the issue is in the app runtime or packaging model rather than in the patch payload itself.