Windows restricted sandbox cannot apply_patch existing files: “cannot enforce split writable root sets directly”

Resolved 💬 2 comments Opened Jul 19, 2026 by visnetwork Closed Jul 19, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

ChatGPT Desktop: 1.2026.190.0 - OpenAI Codex package: 26.715.4045.0

What subscription do you have?

Business

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Windows, apply_patch can create a new file under the normal restricted
permission mode, but it cannot update the newly created existing file.

The identical update succeeds immediately under Full Access.

This appears related to #31776, but the failure is different. There is no
Access Denied error and no multiline patch corruption. The operation fails
while preparing the filesystem sandbox before the target file is opened.

  • CodexSandboxOffline exists and is enabled
  • CodexSandboxOnline exists and is enabled
  • Integrated terminal: PowerShell

What steps can reproduce the bug?

  1. Under normal restricted access, use native apply_patch to create:

_codex_patch_probe.txt

Contents:
probe-1

Creation succeeds.

  1. Use native apply_patch to update probe-1 to probe-2.
  1. The update fails.

PowerShell independently confirms:

  • Get-Location: C:\coding-work
  • Test-Path .\_codex_patch_probe.txt: True
  • Get-Content: probe-1
  • File attributes: Archive
  • File length: 8 bytes

Patch submitted:

* Begin Patch
* Update File: _codex_patch_probe.txt
@@
-probe-1
+probe-2
*** End Patch

Exact error

apply_patch verification failed: Failed to read file to update
C:\coding-work\_codex_patch_probe.txt:
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

Additional result

After switching the same session to Full Access:

  • Updating probe-1 to probe-2 succeeds using native apply_patch.
  • Deleting the probe file succeeds using native apply_patch.

No fallback editing method was used.

What is the expected behavior?

The normal restricted Windows sandbox should permit apply_patch to update
existing files inside the selected workspace.

Additional information

Related issue

Possibly related to #31776, but this report fails during filesystem sandbox
preparation rather than due to the generated .bat path or multiline argument
transport.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34000
  • #33355

Powered by Codex Action

visnetwork · 1 month ago

Resolved on my system.

The root cause was a legacy config.toml:

[windows]
sandbox = "unelevated"

The older unelevated sandbox had worked successfully on this same computer
a few days earlier, including native apply_patch updates to existing files.
However, with the current runtime it failed with:

windows unelevated restricted-token sandbox cannot enforce split writable
root sets directly; refusing to run unsandboxed

Changing the configuration to:

[windows]
sandbox = "elevated"

triggered the one-time Windows sandbox setup.

After setup:

  • whoami returned: predator\codexsandboxonline
  • native apply_patch successfully created an inside-workspace file
  • native apply_patch successfully updated the existing file
  • native apply_patch successfully deleted the file
  • an attempted write outside the workspace was blocked
  • Full Access remained disabled
  • sandbox_mode remained workspace-write
  • approval_policy remained on-request

Therefore, this was not a broken apply_patch helper. It was caused by the
legacy unelevated sandbox selection being incompatible with the current
runtime behavior.

A clearer startup warning or automatic migration when a copied config still
selects sandbox = "unelevated" may be useful.

Closing as resolved.