5.3 apply_patch fails under sandboxed default permission on Windows

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

• #12350
• #12888
• #12241

Powered by Codex Action

the same

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

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.

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.

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

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.

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.`

Seems like a pretty massive bug that's impacting all windows app users? Not sure how OpenAI isn't on top of this by now.

We're looking into it. We're juggling a lot of issues today because of the Windows app launch yesterday and the gpt-5.4 launch today. Please bear with us, and thanks for your patience.

@yaboijbigs, you said that you're seeing this behavior even with "full access" mode? That seems to contradict what others on this thread are saying. Just trying to narrow down the problem.

Also, I wouldn't assume this is "impacting all Windows app users". I don't think we have evidence of that. We're still trying to understand the cause.

One thing that I noticed from the initial report: @EarzuChan, you mentioned that your workspace is on your E: drive. I presume that's not your system drive. I wonder if that's a common thread here. Do the rest of you have your workspace/project stored on a non-system drive?

@etraut-openai you're right and I apologize, I didn't take that into consideration.

I switched to full access mode in a new message/conversation and was able to get it to work!

We're looking into it. We're juggling a lot of issues today because of the Windows app launch yesterday and the gpt-5.4 launch today. Please bear with us, and thanks for your patience.

Yep @etraut-openai Thanks for being so fast

Same issue here, apply_patch fails 100% of the time in Default Permissions, but works with Full Access mode. On the windows Codex app.

@yaboijbigs, you said that you're seeing this behavior even with "full access" mode? That seems to contradict what others on this thread are saying. Just trying to narrow down the problem. Also, I wouldn't assume this is "impacting all Windows app users". I don't think we have evidence of that. We're still trying to understand the cause. One thing that I noticed from the initial report: @EarzuChan, you mentioned that your workspace is on your E: drive. I presume that's not your system drive. I wonder if that's a common thread here. Do the rest of you have your workspace/project stored on a non-system drive?

I am experiencing this issue and my project is stored in my OneDrive>Documents directory. I haven't tried starting a project outside of OneDrive and seeing if the issue persists. That could be related.

Thanks everyone for reporting this issue.

We think we understand the problem, and we're working on a fix.

One thing that I noticed from the initial report: @EarzuChan, you mentioned that your workspace is on your E: drive. I presume that's not your system drive. I wonder if that's a common thread here. Do the rest of you have your workspace/project stored on a non-system drive?

My project is indeed on E: as well, which is not my system drive...

same problem

We've introduced a fix with this PR. It will be included in the next release. Thanks to everyone who reported the problem and provided details to help us track it down.

In addition to the apply_patch problem on Windows, I also noticed a process cleanup issue.

After closing the Codex desktop app, multiple Codex-related processes remain running (Codex, Windows PowerShell, and conhost).
Each new app launch adds more processes instead of reusing/cleaning up existing ones.

After several open/close cycles, I had around 70 processes left and total memory usage reached about 2 GB.

Expected behavior:
When the app is closed, all child/background processes started by Codex should be terminated.

Actual behavior:
Processes remain alive after close, and process count grows with each new launch.

Same issue. When is next release?

same issue

Still experiencing this exact issue after the latest codex update from microsoft store on Windows 11. I'm forced to run everything in Full access mode otherwise Codex is unable to apply patches correctly. They all get "rejected" in the sandbox.

@swebdevelopers I recommend you create a new issue about the processes not closing issue so it can get more attention.

When will the new version with the fix be released?

@ningjiaen123, we don't release on a fixed schedule, but we generally publish two or three releases each week. That means we should have a new release out in the next day or two.

IGNORE - diagnostic read attempt by assistant; please disregard.

<img width="970" height="701" alt="Image" src="https://github.com/user-attachments/assets/856e7c45-0810-464a-955e-f4bb282b681f" />
same problem

same problem

Same issue on the Windows Codex app.

<img width="1374" height="602" alt="Image" src="https://github.com/user-attachments/assets/d03ead8d-e90d-48e8-875f-a5c93cb5af12" />

I want to know why this happened and how to deal with this issue.

Same here, codex wrote the report:

Bug Report
apply_patch fails consistently on Windows Codex desktop, even for trivial add-file patches in a writable workspace.

Environment

• App: Codex desktop
• Version: OpenAI.Codex_26.306.996.0_x64
• OS: Windows
• Workspace: C:\Git\Game
• Sandbox mode: workspace-write

What I tested

1. Tried a trivial patch:

*** Begin Patch
*** Add File: tmp/apply_patch_probe.txt
+probe
*** End Patch

1. Result: apply_patch returned exit code 1
2. No file was created
3. No useful error text was returned

Why this looks like a Codex bug

• The workspace is writable
• Direct shell-based writes work
• Local Git commit works
• Creating/editing files via PowerShell works
• The repo now has a valid HEAD and tracked files
• An equivalent Git patch passes:

git apply --check tmp\apply_patch_git_probe.diff

So patch content is valid, and filesystem permissions are not the issue.

Additional observations

• Restarting Codex did not fix apply_patch

Expected

• apply_patch should create or modify files in the writable workspace

Actual

• apply_patch fails immediately with exit code 1 and no actionable error output

Thanks for the bug report. This is a known issue. See #14196. We already have a fix in place, and a new version should be out shortly.

If anyone is too impatient to wait for a fix, a workaround for this would be to grant read access for your logged in user in ACL of folder
C:\Program Files\WindowsApps\OpenAI.Codex_xxxxx (xxxxx being the version number).

Both rg.exe and apply_patch started working after I did this.

I am suddenly seeing the same issue on codex 0.116. It started happening yesterday, out of nowhere, without me doing an update. I was surprised how the sandbox can suddenly misbehave.

Still no fixed, files with over 1k lines always get rejected!

This serious issue still persists in the latest version of Codex! I've lost all patience. Every time it fails, it clears my files! Then Codex starts to recover bit by bit. Isn't this a waste of my tokens?

Same issues on codex cli on linux.
The codex cli version is 0.117.0.

<img width="354" height="123" alt="Image" src="https://github.com/user-attachments/assets/3f85f863-d0bb-4fa7-a3c5-11cef13f84b4" />

<img width="1205" height="140" alt="Image" src="https://github.com/user-attachments/assets/ad8e6e92-e6b9-45ef-97d7-6fecacda7210" />

@etraut-openai have you noticed that there is a regression? Even on a fresh and clean windows 11 install I frequently see "Failed to apply patch", only giving it Full Access helps. Other than that, most of the time it works around with powershell CLI tools to apply the changes but only after discovering that apply_patch failed; costs lots of tokens and time

@AmazingTurtle, this issue was fixed and closed a few weeks ago. If you're seeing a similar behavior or believe that there's a regression, please open a new bug report with details requested in the bug template.