Stack

fix: fail closed for unsupported split windows sandboxing #14172
fix: preserve split filesystem semantics in linux sandbox #14173
-> fix: align core approvals with split sandbox policies #14171
refactor: centralize filesystem permissions precedence #14174

Why This PR Exists

This PR is intentionally narrower than the title may suggest.

Most of the original split-permissions migration already landed in the earlier #13434 -> #13453 stack. In particular:

• #13439 already did the broad runtime plumbing for split filesystem and network policies.
• #13445 already moved apply_patch safety onto filesystem-policy semantics.
• #13448 already switched macOS Seatbelt generation to split policies.
• #13449 and #13453 already handled Linux helper and bubblewrap enforcement.
• #13440 already introduced the first protocol-side helpers for deriving effective filesystem access.

The reason this PR still exists is that after the follow-on [permissions] work and the new shared precedence helper in #14174, a few core approval paths were still deciding behavior from the legacy SandboxPolicy projection instead of the split filesystem policy that actually carries the carveouts.

That means this PR is mostly a cleanup and alignment pass over the remaining core consumers, not a fresh sandbox backend migration.

What Is Actually New Here

• make unmatched-command fallback decisions consult FileSystemSandboxPolicy instead of only legacy DangerFullAccess / ReadOnly / WorkspaceWrite categories
• thread file_system_sandbox_policy into the shell, unified-exec, and intercepted-exec approval paths so they all use the same split-policy semantics
• keep apply_patch safety on the same effective-access rules as the shared protocol helper, rather than letting it drift through compatibility projections
• add loader-level regression coverage proving legacy sandbox_mode config still builds split policies and round-trips back without semantic drift

What This PR Does Not Do

This PR does not introduce new platform backend enforcement on its own.

• Linux backend parity remains in #14173.
• Windows fail-closed handling remains in #14172.
• The shared precedence/model changes live in #14174.

Files To Focus On

• core/src/exec_policy.rs: unmatched-command fallback and approval rendering now read the split filesystem policy directly
• core/src/tools/sandboxing.rs: default exec-approval requirement keys off FileSystemSandboxPolicy.kind
• core/src/tools/handlers/shell.rs: shell approval requests now carry the split filesystem policy
• core/src/unified_exec/process_manager.rs: unified-exec approval requests now carry the split filesystem policy
• core/src/tools/runtimes/shell/unix_escalation.rs: intercepted exec fallback now uses the same split-policy approval semantics
• core/src/safety.rs: apply_patch safety keeps using effective filesystem access rather than legacy sandbox categories
• core/src/config/config_tests.rs: new regression coverage for legacy sandbox_mode no-drift behavior through the split-policy loader

Notes

• core/src/codex.rs and core/src/codex_tests.rs are just small fallout updates for RequestPermissionsResponse.scope; they are not the point of the PR.
• If you reviewed the earlier #13439 / #13445 stack, the main review question here is simply: “are there any remaining approval or patch-safety paths that still reconstruct semantics from legacy SandboxPolicy instead of consuming the split filesystem policy directly?”

Testing

• cargo test -p codex-core legacy_sandbox_mode_config_builds_split_policies_without_drift
• cargo test -p codex-core request_permissions
• cargo test -p codex-core intercepted_exec_policy
• cargo test -p codex-core restricted_sandbox_requires_exec_approval_on_request
• cargo test -p codex-core unmatched_on_request_uses_split_filesystem_policy_for_escalation_prompts
• cargo test -p codex-core explicit_
• cargo clippy -p codex-core --tests -- -D warnings