›_ Codex Issues
Codex Issues / #35864

[BUGFIX INCLUDED] Windows unelevated sandbox rejects enforceable split writable roots, breaking apply_patch updates and deletes

Open 💬 11 comments Opened Jul 29, 2026 by PerikiyoXD
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.
# THIS INCLUDES A BUGFIX RATHER THAN BEING A PLAIN ISSUE REPORT

I reproduced the native Windows CLI apply_patch failure under the unelevated restricted-token sandbox and traced it to the filesystem override compatibility check.

Linked Issues

#34088
#31229

Reproduction

With:

  • Native Windows Codex CLI
  • [windows] sandbox = "unelevated"
  • Managed workspace-write permissions with split writable roots

A controlled three-step probe behaves as follows:

  1. Add File succeeds.
  2. Update File fails.
  3. Delete File fails for the same reason.

The update fails during patch verification with:

apply_patch verification failed: Failed to read file to update <path>:
failed to prepare fs sandbox:
windows unelevated restricted-token sandbox cannot enforce split writable root sets directly;
refusing to run unsandboxed

This explains why creation works while modification and deletion do not: adding a file does not require reading an existing file, whereas update/delete verification does.

Root cause

The relevant path is:

apply_patch handler
→ verify_apply_patch_args
→ sandboxed filesystem read
→ resolve_windows_restricted_token_filesystem_overrides

resolve_windows_restricted_token_filesystem_overrides rejects the operation whenever the legacy writable-root projection differs from the modern split writable-root set.

However, unequal root sets do not necessarily mean the requested policy is unenforceable.
Concrete split writable roots already receive capability SIDs through the unelevated sandbox machinery.
The blanket equality check rejects enforceable configurations before that machinery can be used.

This is not specific to patch verification: the actual patch application uses the same sandboxed filesystem path, so bypassing verification alone would not correctly solve it.

Proposed fix

Permit split-only concrete writable roots and continue enforcing their restrictions through the existing capability-root and deny-write mechanisms.

The implementation:

  • Removes the blanket legacy-versus-split root-set equality rejection.
  • Accepts concrete split-only writable roots.
  • Adds their read-only carve-outs to the additional deny-write set.
  • Continues failing closed for unsupported filesystem-root writes.
  • Preserves the existing rejection of unsupported read restrictions and unsafe descendant configurations.
  • Does not fall back to unsandboxed execution.

Reference implementation:

https://github.com/PerikiyoXD/codex/commit/381acb1

Validation

After rebuilding the CLI with the change, the same production apply_patch path completed all three operations:

Add File: succeeded
Update File: succeeded
Delete File: succeeded

The focused sandboxing suite also passes:

37 tests run: 37 passed, 0 skipped

just fix -p codex-sandboxing completes without warnings.

I have kept the change as a focused commit on my fork. I can add a dedicated regression test and submit the implementation if a maintainer confirms that this approach matches the intended Windows sandbox architecture and invites a PR.

View original on GitHub ↗

11 Comments

github-actions[bot] contributor · 1 month ago

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

  • #35428
  • #35086
  • #34993
  • #34970

Powered by Codex Action

PerikiyoXD · 1 month ago

<img width="1465" height="598" alt="Image" src="https://github.com/user-attachments/assets/190f70ea-9943-407c-8b35-67eade41251d" />

PerikiyoXD · 29 days ago

https://github.com/PerikiyoXD/codex/commit/381acb1
Fixes
https://github.com/openai/codex/issues/34088
https://github.com/openai/codex/issues/31229
https://github.com/openai/codex/issues/35086
https://github.com/openai/codex/issues/34993
https://github.com/openai/codex/issues/34970

Gale0418 · 28 days ago

Additional reproduction from Codex Desktop on native Windows (workspace path omitted):

Environment:

  • Codex Desktop on Windows with managed :workspace / workspace-write permissions
  • [windows] sandbox = "unelevated"
  • Split writable roots injected by the managed session

Observed:

  1. apply_patch Add File succeeds.
  2. Updating an existing file fails during verification/read with:

apply_patch verification failed: Failed to read file to update <path>: failed to prepare fs sandbox: windows unelevated restricted-token sandbox cannot enforce split writable root sets directly; refusing to run unsandboxed

  1. Delete fails with the same split-root error.
  2. PowerShell edits and Git/file API edits work on the same files, so this is not caused by the project contents or encoding.

On this machine, switching to elevated made sandbox setup/ACL helper work fail to complete promptly and made normal commands impractical; unelevated restores command responsiveness but leaves apply_patch update/delete unusable. We therefore currently need a PowerShell fallback.

This matches the Add/Update/Delete behavior described here and appears related to #35428, #34970, and the newer #36178 read-after-create failure. Could the maintainers please consider integrating the focused fix and adding a regression test covering managed split writable roots for Add, Update, and Delete? A release note or confirmation of the target version would help Windows users know when to retest.

kt-dev-ds · 28 days ago

I can also reproduce this issue with the latest ChatGPT Desktop.

Environment

  • ChatGPT Desktop Version: 26.721.81911
  • Released: 2026-07-29
  • Powered by Codex & OWL
  • Subscription: ChatGPT Business
  • OS: Windows 11

Additional observation

The workaround suggested by Codex is to switch the task to Full Access.

However, the current ChatGPT Desktop application does not expose any Sandbox, Permissions, or Full Access settings.

I checked:

  • Task menu (three dots)
  • Codex menu
  • View menu
  • Help menu

There are no Sandbox / Permissions / Full Access controls available.

Therefore, the suggested workaround cannot be performed.

This behavior occurs in the official ChatGPT Desktop application, not in the standalone Codex CLI.

Reproduction

  • Create new file → ✅ Success
  • Update existing file → ❌ Failure
  • Delete existing file → ❌ Failure

Error:

windows unelevated restricted-token sandbox cannot enforce split writable root sets directly

Restarting ChatGPT Desktop does not resolve the issue.

If needed, I can provide screenshots showing that the current Desktop UI does not contain the Full Access / Sandbox controls that Codex instructs users to use.

The issue occurs in the built-in Codex experience inside the official ChatGPT Desktop application.

<img width="375" height="360" alt="Image" src="https://github.com/user-attachments/assets/d97d3b02-f523-42a1-b562-192598ea621b" />

<img width="265" height="279" alt="Image" src="https://github.com/user-attachments/assets/317e14fb-4ad4-48b4-87b6-765125462e7f" />

PerikiyoXD · 28 days ago

I recommend users to self-compile Codex with the commit I sent as a workaround.

kt-dev-ds · 28 days ago

Thank you for the suggestion.

My issue occurs in the built-in Codex included in the official ChatGPT Desktop application, not the standalone Codex CLI.

Unfortunately, ChatGPT Desktop users cannot self-compile or patch the bundled Codex.

Is this fix expected to be included in a future ChatGPT Desktop release?

Thank you!

PerikiyoXD · 28 days ago

I never used Desktop app but I can assure you the mechanism lives in this repository. This is why the issue no longer exists when I recompiled Codex CLI from this repo and my commit applied (Tried "master" from a few days ago and then switched to 0.145.0 tag and works equally fine)

kt-dev-ds · 28 days ago

Thank you for the clarification.

That makes sense.

Since ChatGPT Desktop is powered by Codex, I hope this fix will be included when the Desktop application is updated to a newer Codex version.

I'll test it again after a future ChatGPT Desktop update and report back if I can confirm the fix.

Thank you for tracking down the root cause and providing a fix.

kt-dev-ds · 23 days ago

I retested this issue after updating the official ChatGPT Desktop application.

Environment

  • ChatGPT Desktop version: 26.730.61639
  • OS: Windows 11

Test result

Creating a new file with apply_patch

Success.

Updating the created file with apply_patch

Failed.

Error:

Script error:
apply_patch verification failed: Failed to read file to update <test file>: 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

Verification

  • The created file remained unchanged after the failed update.
  • The test file was deleted successfully.
  • Confirmed that the test file no longer exists.
  • No existing project files or database contents were modified.

Conclusion

This issue is still reproducible in ChatGPT Desktop 26.730.61639.

Creating new files works correctly, but updating existing files with apply_patch still fails with the same Windows sandbox error.

kt-dev-ds · 11 days ago

Good news — I retested this after updating the official ChatGPT Desktop application, and the issue appears to be resolved.

Environment

  • ChatGPT Desktop version: 26.810.52044
  • OS: Windows 11

Test result

  • Creating a new file with apply_patch: Success
  • Updating the created file with apply_patch: Success
  • Deleting the test file: Success
  • Verified that the test file no longer exists after deletion

No sandbox errors occurred.

No existing project files, source files, documents, or database contents were modified during the test.

Based on this minimal reproduction test, the issue appears to be resolved in ChatGPT Desktop 26.810.52044.

Thank you for the fix!