fix: support split carveouts in windows elevated sandbox by viyatb-oai · Pull Request #14568 · openai/codex

viyatb-oai · 2026-03-13T08:12:02Z

Summary

preserve legacy Windows elevated sandbox behavior for existing policies
add elevated-only support for split filesystem policies that can be represented as readable-root overrides, writable-root overrides, and extra deny-write carveouts
resolve those elevated filesystem overrides during sandbox transform and thread them through setup and policy refresh
keep failing closed for explicit unreadable (none) carveouts and reopened writable descendants under read-only carveouts
document the elevated vs restricted-token support split in the core README

Example

Given a split filesystem policy like:

":root" = "read"
":cwd" = "write"
"./docs" = "read"
"C:/scratch" = "write"

the elevated backend now provisions the readable-root overrides, writable-root overrides, and extra deny-write carveouts during setup and refresh instead of collapsing back to the legacy workspace-only shape.

A policy like:

"/workspace" = "write"
"/workspace/docs" = "read"
"/workspace/docs/tmp" = "write"

still fails closed, because the elevated backend does not reopen writable descendants under read-only carveouts yet.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 46da179661

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

codex-rs/core/src/exec.rs

) ## Summary - keep legacy Windows restricted-token sandboxing as the supported baseline - support the split-policy subset that restricted-token can enforce directly today - support full-disk read, the same writable root set as legacy `WorkspaceWrite`, and extra read-only carveouts under those writable roots via additional deny-write ACLs - continue to fail closed for unsupported split-only shapes, including explicit unreadable (`none`) carveouts, reopened writable descendants under read-only carveouts, and writable root sets that do not match the legacy workspace roots ## Example Given a filesystem policy like: ```toml ":root" = "read" ":cwd" = "write" "./docs" = "read" ``` the restricted-token backend can keep the workspace writable while denying writes under `docs` by layering an extra deny-write carveout on top of the legacy workspace-write roots. A policy like: ```toml "/workspace" = "write" "/workspace/docs" = "read" "/workspace/docs/tmp" = "write" ``` still fails closed, because the unelevated backend cannot reopen the nested writable descendant safely. ## Stack -> fix: support split carveouts in windows restricted-token sandbox #14172 fix: support split carveouts in windows elevated sandbox #14568

iceweasel-oai · 2026-03-25T21:11:08Z

codex-rs/windows-sandbox-rs/src/identity.rs

    let sandbox_dir = crate::setup::sandbox_dir(codex_home);
-    let needed_read = gather_read_roots(command_cwd, policy, codex_home);
-    let needed_write = gather_write_roots(policy, policy_cwd, command_cwd, env_map);
+    let needed_read = read_roots_override


gather_read_roots() attempts to provide read access to the sandbox user to a number of directories that we think it might need in order to actually be able to execute commands (like the real user's profile dir, some important windows directories, etc.)

I'm worried that if we just replace those with a set of config-supplied directories then some commands will fail in surprising ways. Unless, this feature is meant to be literally "the sandbox can read this directories and nothing else"?

good point, fixed it.

) ## Summary - keep legacy Windows restricted-token sandboxing as the supported baseline - support the split-policy subset that restricted-token can enforce directly today - support full-disk read, the same writable root set as legacy `WorkspaceWrite`, and extra read-only carveouts under those writable roots via additional deny-write ACLs - continue to fail closed for unsupported split-only shapes, including explicit unreadable (`none`) carveouts, reopened writable descendants under read-only carveouts, and writable root sets that do not match the legacy workspace roots ## Example Given a filesystem policy like: ```toml ":root" = "read" ":cwd" = "write" "./docs" = "read" ``` the restricted-token backend can keep the workspace writable while denying writes under `docs` by layering an extra deny-write carveout on top of the legacy workspace-write roots. A policy like: ```toml "/workspace" = "write" "/workspace/docs" = "read" "/workspace/docs/tmp" = "write" ``` still fails closed, because the unelevated backend cannot reopen the nested writable descendant safely. ## Stack -> fix: support split carveouts in windows restricted-token sandbox #14172 fix: support split carveouts in windows elevated sandbox #14568

…elevated-permissions-support # Conflicts: # codex-rs/cli/src/debug_sandbox.rs # codex-rs/core/src/exec.rs # codex-rs/windows-sandbox-rs/src/elevated_impl.rs # codex-rs/windows-sandbox-rs/src/identity.rs # codex-rs/windows-sandbox-rs/src/setup_main_win.rs # codex-rs/windows-sandbox-rs/src/setup_orchestrator.rs

Co-authored-by: Codex <[email protected]>

iceweasel-oai · 2026-03-27T19:28:52Z

codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs

        file_system_sandbox_policy,
        network_sandbox_policy,
        windows_restricted_token_filesystem_overlay: _windows_restricted_token_filesystem_overlay,
+        windows_elevated_filesystem_overrides: _windows_elevated_filesystem_overrides,


what do you think about merging these into one thing, and then each sandbox implementation (legacy vs elevated) can decide which of the fields it actually supports?

iceweasel-oai · 2026-03-27T19:30:15Z

codex-rs/core/src/exec.rs

+/// Resolved filesystem overrides for the elevated Windows sandbox backend.
+///
+/// Unlike the restricted-token path, elevated setup can provision explicit read
+/// and write roots up front, so we pass the exact split-policy roots and any


might want to update this docstring to indicate that read roots include the gather_read_roots ones too

Co-authored-by: Codex <[email protected]>

viyatb-oai mentioned this pull request Mar 13, 2026

fix: support split carveouts in windows restricted-token sandbox #14172

Merged

chatgpt-codex-connector bot reviewed Mar 13, 2026

View reviewed changes

codex-rs/core/src/exec.rs Outdated Show resolved Hide resolved

viyatb-oai requested a review from iceweasel-oai March 13, 2026 16:25

viyatb-oai force-pushed the codex/viyatb/permissions-windows-fail-closed branch from 86c7c4e to 17c89eb Compare March 18, 2026 00:23

viyatb-oai force-pushed the codex/viyatb/windows-elevated-permissions-support branch from 46da179 to aa35d52 Compare March 18, 2026 00:29

viyatb-oai changed the base branch from codex/viyatb/permissions-windows-fail-closed to main March 18, 2026 00:33

viyatb-oai force-pushed the codex/viyatb/windows-elevated-permissions-support branch from aa35d52 to d10d8b5 Compare March 18, 2026 00:36

viyatb-oai changed the base branch from main to codex/viyatb/permissions-windows-fail-closed March 18, 2026 00:36

github-actions bot mentioned this pull request Mar 18, 2026

📊 AI CLI 工具社区动态日报 2026-03-18 gsscsd/big_model_radar#55

Open

bolinfest self-requested a review March 18, 2026 05:50

viyatb-oai force-pushed the codex/viyatb/windows-elevated-permissions-support branch from 980af52 to 3f1c117 Compare March 24, 2026 22:34

Base automatically changed from codex/viyatb/permissions-windows-fail-closed to main March 25, 2026 05:54

viyatb-oai force-pushed the codex/viyatb/windows-elevated-permissions-support branch from 3f1c117 to d30f171 Compare March 25, 2026 06:14

viyatb-oai added 3 commits March 24, 2026 23:17

fix: support split carveouts in windows elevated sandbox

ab18c97

fix: restack elevated windows sandbox support

01617c0

fix: refresh elevated branch exec test callsites

c7b5c90

viyatb-oai force-pushed the codex/viyatb/windows-elevated-permissions-support branch from d30f171 to c7b5c90 Compare March 25, 2026 06:17

fix: refresh windows elevated sandbox debug callsite

da72d73

iceweasel-oai reviewed Mar 25, 2026

View reviewed changes

fix: preserve elevated windows helper read roots

fc4fbd2

viyatb-oai requested a review from iceweasel-oai March 26, 2026 19:53

viyatb-oai and others added 3 commits March 27, 2026 12:16

fix: normalize elevated windows deny carveout matching

e8bbcb4

Co-authored-by: Codex <[email protected]>

fix: borrow elevated windows setup root overrides

5e92cf6

Co-authored-by: Codex <[email protected]>

iceweasel-oai reviewed Mar 27, 2026

View reviewed changes

viyatb-oai and others added 2 commits March 27, 2026 12:33

docs: clarify elevated windows read root overrides

af6075a

Co-authored-by: Codex <[email protected]>

fix: remove needless borrows in windows setup overrides

2b7e9ac

Co-authored-by: Codex <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: support split carveouts in windows elevated sandbox#14568

fix: support split carveouts in windows elevated sandbox#14568
viyatb-oai wants to merge 10 commits intomainfrom
codex/viyatb/windows-elevated-permissions-support

viyatb-oai commented Mar 13, 2026 •

edited

Loading

Uh oh!

chatgpt-codex-connector bot left a comment

Uh oh!

Uh oh!

iceweasel-oai Mar 25, 2026

Uh oh!

viyatb-oai Mar 26, 2026

Uh oh!

iceweasel-oai Mar 27, 2026

Uh oh!

iceweasel-oai Mar 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

viyatb-oai commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Example

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

iceweasel-oai Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

viyatb-oai Mar 26, 2026

Choose a reason for hiding this comment

Uh oh!

iceweasel-oai Mar 27, 2026

Choose a reason for hiding this comment

Uh oh!

iceweasel-oai Mar 27, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

viyatb-oai commented Mar 13, 2026 •

edited

Loading