feat(sandbox): add Windows deny-read parity

[viyatb-oai]

Why

The split filesystem policy stack already supports exact and glob access = none read restrictions on macOS and Linux. Windows still needed subprocess handling for those deny-read policies without claiming enforcement from a backend that cannot provide it.

Key finding

The unelevated restricted-token backend cannot safely enforce deny-read overlays. Its WRITE_RESTRICTED token model is authoritative for write checks, not read denials, so this PR intentionally fails that backend closed when deny-read overrides are present instead of claiming unsupported enforcement.

What changed

This PR adds the Windows deny-read enforcement layer and makes the backend split explicit:

• Resolves Windows deny-read filesystem policy entries into concrete ACL targets.
• Preserves exact missing paths so they can be materialized and denied before an enforceable sandboxed process starts.
• Snapshot-expands existing glob matches into ACL targets for Windows subprocess enforcement.
• Honors glob_scan_max_depth when expanding Windows deny-read globs.
• Plans both the configured lexical path and the canonical target for existing paths so reparse-point aliases are covered.
• Threads deny-read overrides through the elevated/logon-user Windows sandbox backend and unified exec.
• Applies elevated deny-read ACLs synchronously before command launch rather than delegating them to the background read-grant helper.
• Reconciles persistent deny-read ACEs per sandbox principal so policy changes do not leave stale deny-read ACLs behind.
• Fails closed on the unelevated restricted-token backend when deny-read overrides are present, because its WRITE_RESTRICTED token model is not authoritative for read denials.

Landed prerequisites

These prerequisite PRs are already on main:

1. feat(permissions): add glob deny-read policy support #15979 feat(permissions): add glob deny-read policy support
2. feat(sandbox): add glob deny-read platform enforcement #18096 feat(sandbox): add glob deny-read platform enforcement
3. feat(config): support managed deny-read requirements #17740 feat(config): support managed deny-read requirements

This PR targets main directly and contains only the Windows deny-read enforcement layer.

Implementation notes

• Exact deny-read paths remain enforceable on the elevated path even when they do not exist yet: Windows materializes the missing path before applying the deny ACE, so the sandboxed command cannot create and read it during the same run.
• Existing exact deny paths are preserved lexically until the ACL planner, which then adds the canonical target as a second ACL target when needed. That keeps both the configured alias and the resolved object covered.
• Windows ACLs do not consume Codex glob syntax directly, so glob deny-read entries are expanded to the concrete matches that exist before process launch.
• Glob traversal deduplicates directory visits within each pattern walk to avoid cycles, without collapsing distinct lexical roots that happen to resolve to the same target.
• Persistent deny-read ACL state is keyed by sandbox principal SID, so cleanup only removes ACEs owned by the same backend principal.
• Deny-read ACEs are fail-closed on the elevated path: setup aborts if mandatory deny-read ACL application fails.
• Unelevated restricted-token sessions reject deny-read overrides early instead of running with a silently unenforceable read policy.

Verification

• cargo test -p codex-core windows_restricted_token_rejects_unreadable_split_carveouts
• just fmt
• just fix -p codex-core
• just fix -p codex-windows-sandbox
• GitHub Actions rerun is in progress on the pushed head.

[chatgpt-codex-connector]

💡 Codex Review

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

Lines 420 to 423 in 954e7c2

	for path in additional_deny_write_paths {
	if path.exists() {
	deny.insert(path.clone());
	}

Apply deny-write ACLs to missing None carveouts

The restricted-token path only adds additional_deny_write_paths when the path already exists. New deny-read logic later materializes missing deny paths (apply_deny_read_acls), so a FileSystemAccessMode::None path that starts missing gets read-denied but not write-denied. A sandboxed process can still create/write descendants under that directory, violating None semantics.

---

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

Lines 420 to 423 in 954e7c2

	for path in additional_deny_write_paths {
	if path.exists() {
	deny.insert(path.clone());
	}

Apply deny-write ACLs to missing None carveouts

The restricted-token path only adds additional_deny_write_paths when the path already exists. New deny-read logic then materializes missing deny paths (apply_deny_read_acls), so a missing FileSystemAccessMode::None path becomes read-denied but not write-denied. A sandboxed command can still create/write under that directory, violating None semantics.

ℹ️ 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".

[github-actions]

Closing this pull request because it has had no updates for more than 14 days. If you plan to continue working on it, feel free to reopen or open a new PR.

[bolinfest]

Still reviewing, but I wanted to send what I found so far...

[bolinfest]

I feel like we should create a macro or function that takes the TOML for config.toml because I find these test setups really hard to read...