5.3 apply_patch fails under sandboxed default permission on Windows

[EarzuChan]

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

0.108.0-alpha.8

What subscription do you have?

$200

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

This report was generated by 5.3-codex itself, and confirmed by me: It fails to apply any patches under the default permission mode, showing "Refused" on the UI. However, patches can be applied with highest permissions. Meanwhile, Codex on macOS can correctly apply patches with default permissions. Therefore, I suspect this is a bug. I conducted a test with 5.3-codex and got the following report:

Summary
When running in workspace-write (not read-only), built-in apply_patch fails for both Add File and Update File with:

• Exit code: 1
• Empty output

No permission/grant prompt is shown, and no actionable error message is returned.

Environment

• Workspace: E:\c_misc\tmp\testspace
• Mode shown: workspace-write
• Shell not used for repro (built-in tool only)
• Network restriction status is irrelevant for this repro

Reproduction Steps

1. Try creating a file via apply_patch:
   • Add File: ap_test_create.txt
   • content: apply_patch create test
2. Try updating an existing file via apply_patch:
   • Update File: daipaibulaodi.ja.md
   • replace first line with another line
3. (Control) Try deleting the not-created file:
   • Delete File: ap_test_create.txt

Expected Behavior

• In workspace-write, Add File and Update File should succeed in workspace paths.
• If blocked, the tool should return a clear permission/validation error.

Actual Behavior

• Add File: Exit code 1, empty output
• Update File: Exit code 1, empty output
• Delete File: returns a normal verification error (file not found), indicating path checks still work

Raw Observations

• No escalation/permission prompt appeared for failed Add/Update.
• Failures are reproducible and opaque (no stderr/body), which makes diagnosis difficult.

Impact

• Prevents basic file creation/editing through built-in tool even in non-read-only mode.
• Blocks normal coding workflow and automated patching.

What steps can reproduce the bug?

1. Create a new folder and add a file with a few lines of content

2. Ask 5.3-codex to modify the file under the default permission mode

3. Observe the "Refused" error on the UI

What is the expected behavior?

The file should be edited properly

Additional information

No response

[github-actions]

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

• apply_patch fails with Access is denied on mapped/UNC Windows worktrees #12350
• Agent edits resulting in "command failed; retry without sandbox?" #12888
• Failed to apply patch consantly #12241

Powered by Codex Action

[adxptived]

the same

[doublemover]

Mine's asking for permissons to do anything constantly, doesn't matter if I give it full access, default, etc. It's impossible to use! It also does not remember any "for this session" choice, and neither do sub agents. It's entirely unsuitable for work

[FylmTM]

Same issue. GPT-5.4 debugged itself and created bug report:

Version:

• Codex Desktop CLI version: 0.108.0-alpha.8
• Desktop app build: 26.304.38.0

Issue:
apply_patch always fails in Desktop with exit_code: 1 and empty output. No file changes are made.

Debugging results:

• apply_patch create: failed
• apply_patch update on existing file: failed
• Restarting Desktop: no change
• Shell file create/modify/delete in the same workspace: succeeded
• Codex CLI in the same workspace: apply_patch succeeded

Conclusion:
This looks Desktop-specific, not a workspace permission issue, not general file I/O, and not a basic patch syntax problem.

[skbtwiz]

I am facing this same issue too, switching to Full Access mode worked for me, though this is not desirable. When I try to submit feedback using /feedback it doesn't work and gives me an error saying feedback could not be submitted.

[yaboijbigs]

Using Codex windows app. GPT-5.4 with Full Access and Extra High Reasoning can't use the apply_patch tool and keeps saying it is failing with exit code 1. Here is the thread_id: 019cc04f-565c-7543-a0ff-9424111927d9

[AriMKatz]

same issue. Codex told me to say this:

I can confirm the same issue, and I have a likely root-cause detail.

On my machine, apply_patch fails with exit code 1 and no useful stderr, but the generated apply_patch.bat points to:

C:\Program Files\WindowsApps\OpenAI.Codex_26.305.950.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

Directly invoking that wrapper/target from PowerShell returns:

Access is denied.

As a control, I found an older generated wrapper on the same machine that points to the npm-installed vendored Codex binary under C:\Users\arika\AppData\Roaming\npm\node_modules\@openai\codex\..., and that launcher works far enough to parse --codex-run-as-apply-patch normally instead of failing at launch.

This machine has both the packaged Codex app and the npm Codex CLI installed, so this may be a Windows launcher-selection bug when both installs are present.

[siddhantparadox]

apply_patch works in native codex CLI on this machine, but fails in the Codex Windows app under sandboxed modes. Device context: Lenovo model 83F5, Windows 10.0.26200.0, CPU Intel(R) Core(TM) Ultra 9 275HX, RAM 33,752,997,888 bytes (~31.4 GB), native PowerShell environment, repo on local Windows filesystem. In the app, [features] apply_patch_freeform = true is enabled. Repro is a trivial patch such as:

*** Begin Patch
*** Add File: smoke.txt
+hello
*** End Patch

A trivial update to an existing file also fails. In the Codex Windows app, every apply_patch invocation fails immediately with exit code 1 and no diagnostic output. I confirmed this is not a patch-format or path issue: absolute path, relative path, Add File, and Update File variants all fail. It also fails in sandboxed configuration with: approval_policy = "never", sandbox_mode = "workspace-write", [sandbox_workspace_write] network_access = true, [windows] sandbox = "elevated", and features.unified_exec = true. It succeeds only in Full access / danger-full-access. Control case: native codex CLI using the same machine, same repo, and same config can apply patches successfully. That strongly suggests the issue is specific to the Codex Windows app’s sandboxed apply_patch path, likely in the native Windows workspace-write sandbox/integration rather than config, approvals, or patch content.`