Skip to content

fix: support split carveouts in windows elevated sandbox#14568

Open
viyatb-oai wants to merge 11 commits intomainfrom
codex/viyatb/windows-elevated-permissions-support
Open

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

Conversation

@viyatb-oai
Copy link
Copy Markdown
Collaborator

@viyatb-oai viyatb-oai commented Mar 13, 2026

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.

Copy link
Copy Markdown
Contributor

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

@viyatb-oai viyatb-oai force-pushed the codex/viyatb/permissions-windows-fail-closed branch from 86c7c4e to 17c89eb Compare March 18, 2026 00:23
@viyatb-oai viyatb-oai force-pushed the codex/viyatb/windows-elevated-permissions-support branch from 46da179 to aa35d52 Compare March 18, 2026 00:29
@viyatb-oai viyatb-oai changed the base branch from codex/viyatb/permissions-windows-fail-closed to main March 18, 2026 00:33
@viyatb-oai viyatb-oai force-pushed the codex/viyatb/windows-elevated-permissions-support branch from aa35d52 to d10d8b5 Compare March 18, 2026 00:36
@viyatb-oai viyatb-oai changed the base branch from main to codex/viyatb/permissions-windows-fail-closed March 18, 2026 00:36
@bolinfest bolinfest self-requested a review March 18, 2026 05:50
@viyatb-oai viyatb-oai force-pushed the codex/viyatb/windows-elevated-permissions-support branch from 980af52 to 3f1c117 Compare March 24, 2026 22:34
viyatb-oai added a commit that referenced this pull request Mar 25, 2026
)

## 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
Base automatically changed from codex/viyatb/permissions-windows-fail-closed to main March 25, 2026 05:54
@viyatb-oai viyatb-oai force-pushed the codex/viyatb/windows-elevated-permissions-support branch from 3f1c117 to d30f171 Compare March 25, 2026 06:14
@viyatb-oai viyatb-oai force-pushed the codex/viyatb/windows-elevated-permissions-support branch from d30f171 to c7b5c90 Compare March 25, 2026 06:17
rhan-oai pushed a commit that referenced this pull request Mar 25, 2026
)

## 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
viyatb-oai and others added 3 commits March 27, 2026 12:16
…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 <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
viyatb-oai and others added 3 commits March 27, 2026 12:33
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants