apply_patch fails for nested files under src/** with sandbox refresh error

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

• #14585
• #14409
• #13378

Powered by Codex Action

Additional sanitized details:

Reproduction boundary observed on Windows:

• apply_patch succeeds for root-level files directly under src, for example src/App.css
• apply_patch fails for nested files under src/**, for example src/core/hopfield.ts, src/features/hopfield/ControlPanel.tsx, and src/workers/hopfield.worker.ts
• apply_patch succeeds for nested files outside src, such as files under scripts/**, public/**, and another synthetic nested directory outside src
• normal shell file operations in the same failing src/** directories succeed, including create/edit/delete
• restarting the Codex Windows desktop app did not change the behavior
• absolute paths did not help for nested files under src/**

This was also reproduced in Codex CLI on Windows with the same exact error:

windows sandbox: setup refresh failed with status exit code: 1

In the CLI reproduction, a root-level src/numeric.d.ts patch succeeded while a nested src/workers/hopfield.worker.ts patch failed with the same sandbox refresh error.

This suggests the issue is not desktop-app-specific. It appears to be a shared Windows sandbox / patch-application bug affecting nested files under src/**.

Can easily reproduce:
<details>
<summary>Log</summary>

› this is a test.
  using the apply_patch tool, replace test.txt's content with lorem ipsum


• The patch missed because I assumed existing content; I’ll quickly inspect the file and then reapply a one-shot overwrite patch.

• Ran Get-Content -Raw test.txt
  └ hello


─────────

• I found the file currently contains hello; I’ll replace it with a single lorem ipsum line using apply_patch.

• Edited test.txt (+1 -1)
    1 -hello
    1 +Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

─────────

• Replaced test.txt content with lorem ipsum as requested.


› now do the same with nested/test.txt


• Applying the same replacement to nested/test.txt next. I’ll do a direct patch against that file now.

• Edited nested/test.txt (+1 -1)
    1 -hello
    1 +Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

✘ Failed to apply patch
  └ execution error: Io(Custom { kind: Other, error: "windows sandbox: setup refresh failed with status exit code: 1" })

─────────

• Deleted nested/test.txt (+0 -1)
    1 -hello

✘ Failed to apply patch
  └ execution error: Io(Custom { kind: Other, error: "windows sandbox: setup refresh failed with status exit code: 1" })

─────────

• I hit a transient sandbox/tool setup failure on that patch, so I’m making one quick follow-up command to verify the nested path and then retry with the exact path.

• Ran Get-ChildItem nested
  └

    … +6 lines



─────────

• The file exists at nested/test.txt; I’ll retry the apply_patch update now that the path is confirmed.

• Edited nested/test.txt (+1 -1)
    1 -hello
    1 +Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

✘ Failed to apply patch
  └ execution error: Io(Custom { kind: Other, error: "windows sandbox: setup refresh failed with status exit code: 1" })

─────────

• I’m retrying once more with an absolute path in the patch format; if this keeps failing, I’ll report the tool issue and ask to proceed with an equivalent command.

• Edited nested/test.txt (+1 -1)
    1 -hello
    1 +Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

✘ Failed to apply patch
  └ execution error: Io(Custom { kind: Other, error: "windows sandbox: setup refresh failed with status exit code: 1" })

• Edited test.txt (+0 -0)

─────────

• I confirmed apply_patch works; I’ll now check the current content of nested/test.txt and patch it based on the actual line.

• Ran Get-Content -Raw nested\test.txt
  └ hello


─────────

• nested/test.txt still contains hello; applying the replacement now should succeed.

• Edited nested/test.txt (+1 -1)
    1 -hello
    1 +Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

✘ Failed to apply patch
  └ execution error: Io(Custom { kind: Other, error: "windows sandbox: setup refresh failed with status exit code: 1" })

─────────

• I’m making one more targeted attempt using Windows-style relative path notation.

• Edited nested\test.txt (+1 -1)
    1 -hello
    1 +Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

✘ Failed to apply patch
  └ execution error: Io(Custom { kind: Other, error: "windows sandbox: setup refresh failed with status exit code: 1" })

─────────

• Couldn’t finish nested/test.txt with apply_patch due a repeated sandbox/tool failure specific to that path (windows sandbox: setup refresh failed...), even though apply_patch still
  works for test.txt.

</details>

This seems to be a regression in 0.114.0; as a workaround, you can downgrade to the previous version of @openai/codex.

npm install -g @openai/codex@0.113.0

Pinging some related issues since there seem to be many similar reports:

• https://github.com/openai/codex/issues/14744
• https://github.com/openai/codex/issues/14409
• https://github.com/openai/codex/issues/14585
• https://github.com/openai/codex/issues/12484
• https://github.com/openai/codex/issues/10601

Adding to this. Here is below the troubleshooting and reporting that I had Codex put together for me on what I am running into (similar to OP).

`apply_patch` appears to be broken in this workspace for files under `apps/*` and `packages/*`, while still working for repo-root files and files under `.dev/*`.

Repro details:
- Repo root: `C:\2-local-only\github\electron\electron-web-pg-todo`
- `apply_patch` succeeds on:
  - `package.json`
  - `.dev/...`
- `apply_patch` consistently fails on:
  - `apps/web/package.json`
  - `apps/web/src/index.ts`
  - `packages/schemas/package.json`

Observed failure:
- For actual patch attempts under `apps/*` and `packages/*`, `apply_patch` returns:
  - `windows sandbox: setup refresh failed with status exit code: 1`

Important notes:
- This is not specific to `package.json`; it also happens on `.ts` files.
- It is not specific to path format; I tested:
  - repo-relative with `/`
  - repo-relative with `\`
  - `.\`-prefixed paths
  - absolute paths with `C:\...`
  - absolute paths with `C:/...`
- All path variants fail the same way for workspace-member files.
- In one case, `apply_patch` could read `apps/web/src/index.ts` and failed only because my expected line was wrong, which suggests path resolution/file read can work. But retrying with the correct line still failed during sandbox refresh.

Likely issue:
- A Windows sandbox/apply_patch integration bug affecting non-root workspace subdirectories, especially monorepo member directories like `apps/*` and `packages/*`.

I can confirm that the regression/issue happened at 0.114 as @apkd mentioned above. When I roll the Codex CLI back to 0.113 I no longer have these issues.

The problem is that I use the Codex App and with that it appears I cannot roll back to a previous version so I cannot use the Codex App until this is fixed.

@apkd have you tried with the Codex App to get it to use an older version under the hood?

@apkd have you tried with the Codex App to get it to use an older version under the hood?

~~I have tried, but I haven't found a way. The workarounds to allow write access to Windows Store app files no longer seem to work. The entire Windows platform seems increasingly annoying and locked down. I am literally this close to switching to Linux today.~~

🐧 SEEYA SUCKERS 🐧

cc @apkd @pzarzycki

Ok, I found a bit of a solution! Still don't know the cause of how/why certain subdirectories were created in a certain way that created issues but below is the write-up that I came up with via Codex based off our intense debug/troubleshooting/repro session:

TLDR Workaround / Solution

Have Codex move the affected top-level directories out of the way, recreate those directories fresh at the repo root, then recreate the same subdirectory structure and COPY (do not move) the tracked files back into the fresh directories. Do not move the old files/directories back in-place, because moves can preserve the old ACLs; copying into the fresh directories is what made apply_patch start working again for us.

Codex Detailed Write-Up

We were hitting apply_patch failures on Windows with:

windows sandbox: setup refresh failed with status exit code: 1

What we found:

• The failure was not caused by Git state, pnpm workspace config, or normal NTFS write permissions.
• Shell writes to the same locations worked fine.
• apply_patch failed specifically in certain existing subtrees, while root-level and some freshly created paths worked.
• Comparing ACLs/SDDLs showed the failing subtrees were missing one inherited ACE that existed on known-good directories/files.
• The strongest signal: if we created a fresh directory at repo root and then moved that directory under apps/ or packages/, apply_patch worked there. But old existing subtrees under apps/ / packages/ still failed.
• That suggests the bug is tied to the sandbox’s ACL/DACL refresh logic for certain existing directory trees, not file contents.

Workaround that fixed it for us:

1. Move the affected top-level trees out of the way (apps, packages, scripts in our case).
2. Recreate those top-level directories fresh at repo root so they inherit the “good” ACL shape.
3. Copy tracked files back into the fresh directories.

Important: copy files, do not move them back in-place, because moves can preserve the old ACLs.

1. Verify with apply_patch on both disposable temp files and real tracked files.
2. End state for us: apply_patch now works throughout the repo again.

Hunch:

• Codex’s Windows sandbox appears to rewrite or normalize ACLs before patching.
• Some pre-existing directory trees have an ACL/SDDL shape that causes that refresh step to fail before patch application starts.
• Freshly recreated directories inherit a different ACL shape that the sandbox accepts.

hey @GitMurf @pzarzycki @apkd sorry it took me a while to get to this.
I'm not able to reproduce this locally, so what would be really helpful would be if you could send me your sandbox.log file located at %USERPROFILE%\.codex\.sandbox\sandbox.log or at least the parts of it around when the bug occurred.

Also a dump of ACLs on the affected directories would help, something like

icacls "C:\path\to\repo\root"
icacls "C:\path\to\working\dir"
icacls "C:\path\to\failing\dir\.."

@iceweasel-oai

https://cpaste.de/raw/iminerotat

@Brokkonaut thanks - that is helpful. Would you mind running a few commands locally to help me debug this?

Get-Acl -LiteralPath "<APPROOTREDACTED>" | Format-List Path,Owner,AreAccessRulesProtected,AreAccessRulesCanonical,AccessToString

Get-Acl -LiteralPath "<APPROOTREDACTED>\docs" | Format-List Path,Owner,AreAccessRulesProtected,AreAccessRulesCanonical,AccessToString

fsutil reparsepoint query "<APPROOTREDACTED>\docs"

@iceweasel-oai I just submitted with /feedback another similar issue that hopefully can help with the troubleshooting. I am not sure if others use pnpm and if that is part of the issue with how pnpm works with its "symlinking" etc. but I ran into another ACL / access issue with Electron build process because it was running with the codex sandbox account. Details are in the /feedback report but also I pasted below for quick reference.

Feedback ID: 019d306f-186b-7710-9213-8a01bfc463bf

TLDR /feedback report

On Windows, the Codex sandbox account can’t reliably run pnpm package:desktop because the sandbox user ends up unable to read a hoisted dependency under node_modules even after pnpm install/pnpm install --force. In our case, Electron Forge failed with Error: Cannot find module 'chalk' from @electron-forge/cli, while the same command succeeded when run outside the sandbox with elevated permissions under the host account.

How to reproduce

1. In a Windows Codex sandbox, run pnpm install.
2. Run pnpm package:desktop.
3. The command fails before packaging starts with:

• Error: Cannot find module 'chalk'
• Require stack includes node_modules\@electron-forge\cli\dist\electron-forge.js

Observed behavior

• In the Codex sandbox: pnpm package:desktop fails with module resolution/ACL issues.
• In the host environment with elevated permissions: pnpm package:desktop succeeds and completes Electron Forge packaging.

Workaround
Run the command outside the sandbox / with elevated permissions so it uses the host account permissions instead of the Codex sandbox account. In our case, that made pnpm package:desktop complete successfully.

Notes

• This looked like a Windows sandbox ACL / permission issue, not a repo bug.
• Reinstalling dependencies inside the sandbox did not fix it.

@iceweasel-oai https://cpaste.de/raw/iqefozoliy

@iceweasel-oai any updates?

@iceweasel-oai any updates?

Still reproducible on Codex CLI 0.144.6, Windows 11 build 26200, with [windows] sandbox = "unelevated".

The session root was C:\Users\<user>, with the repository nested under it. apply_patch successfully created a new file, but two attempts to update an existing file returned empty output with no patch completion event. Normal shell-based edits worked, and the existing/new files had identical ACLs.

A separate sandboxed command also failed with: SetTokenInformation(TokenDefaultDacl) failed: 1344

This appears related to the same path-sensitive Windows sandbox/ACL issue.