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:
- Add File succeeds.
- Update File fails.
- 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:
PerikiyoXD@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.
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:
A controlled three-step probe behaves as follows:
The update fails during patch verification with:
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:
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:
Reference implementation:
PerikiyoXD@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.