sandboxing: plumb split sandbox policies through runtime#13439
Merged
viyatb-oai merged 4 commits intomainfrom Mar 7, 2026
Merged
sandboxing: plumb split sandbox policies through runtime#13439viyatb-oai merged 4 commits intomainfrom
viyatb-oai merged 4 commits intomainfrom
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3d8f475bce
ℹ️ 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".
This was referenced Mar 4, 2026
bolinfest
force-pushed
the
pr13434
branch
2 times, most recently
from
15b518e to
7abd701
Compare
This was referenced Mar 4, 2026
This was referenced Mar 4, 2026
bolinfest
force-pushed
the
pr13434
branch
2 times, most recently
from
5cd0fd9 to
974327b
Compare
bolinfest
force-pushed
the
pr13439
branch
3 times, most recently
from
0e7b5f0 to
b4e9baa
Compare
bolinfest
force-pushed
the
pr13434
branch
2 times, most recently
from
c19cf38 to
fac9b40
Compare
bolinfest
force-pushed
the
pr13439
branch
2 times, most recently
from
45efe16 to
eb5869b
Compare
bolinfest
added a commit
that referenced
this pull request
Mar 6, 2026
…guage in config.toml (#13434) ## Why `SandboxPolicy` currently mixes together three separate concerns: - parsing layered config from `config.toml` - representing filesystem sandbox state - carrying basic network policy alongside filesystem choices That makes the existing config awkward to extend and blocks the new TOML proposal where `[permissions]` becomes a table of named permission profiles selected by `default_permissions`. (The idea is that if `default_permissions` is not specified, we assume the user is opting into the "traditional" way to configure the sandbox.) This PR adds the config-side plumbing for those profiles while still projecting back to the legacy `SandboxPolicy` shape that the current macOS and Linux sandbox backends consume. It also tightens the filesystem profile model so scoped entries only exist for `:project_roots`, and so nested keys must stay within a project root instead of using `.` or `..` traversal. This drops support for the short-lived `[permissions.network]` in `config.toml` because now that would be interpreted as a profile named `network` within `[permissions]`. ## What Changed - added `PermissionsToml`, `PermissionProfileToml`, `FilesystemPermissionsToml`, and `FilesystemPermissionToml` so config can parse named profiles under `[permissions.<profile>.filesystem]` - added top-level `default_permissions` selection, validation for missing or unknown profiles, and compilation from a named profile into split `FileSystemSandboxPolicy` and `NetworkSandboxPolicy` values - taught config loading to choose between the legacy `sandbox_mode` path and the profile-based path without breaking legacy users - introduced `codex-protocol::permissions` for the split filesystem and network sandbox types, and stored those alongside the legacy projected `sandbox_policy` in runtime `Permissions` - modeled `FileSystemSpecialPath` so only `ProjectRoots` can carry a nested `subpath`, matching the intended config syntax instead of allowing invalid states for other special paths - restricted scoped filesystem maps to `:project_roots`, with validation that nested entries are non-empty descendant paths and cannot use `.` or `..` to escape the project root - kept existing runtime consumers working by projecting `FileSystemSandboxPolicy` back into `SandboxPolicy`, with an explicit error for profiles that request writes outside the workspace root - loaded proxy settings from top-level `[network]` - regenerated `core/config.schema.json` ## Verification - added config coverage for profile deserialization, `default_permissions` selection, top-level `[network]` loading, network enablement, rejection of writes outside the workspace root, rejection of nested entries for non-`:project_roots` special paths, and rejection of parent-directory traversal in `:project_roots` maps - added protocol coverage for the legacy bridge rejecting non-workspace writes ## Docs - update the Codex config docs on developers.openai.com/codex to document named `[permissions.<profile>]` entries, `default_permissions`, scoped `:project_roots` syntax, the descendant-path restriction for nested `:project_roots` entries, and top-level `[network]` proxy configuration --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/13434). * #13453 * #13452 * #13451 * #13449 * #13448 * #13445 * #13440 * #13439 * __->__ #13434
viyatb-oai
approved these changes
Mar 7, 2026
…merge # Conflicts: # codex-rs/app-server/src/codex_message_processor.rs # codex-rs/core/src/exec.rs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
#13434introduces splitFileSystemSandboxPolicyandNetworkSandboxPolicy, but the runtime still made most execution-time sandbox decisions from the legacySandboxPolicyprojection.That projection loses information about combinations like unrestricted filesystem access with restricted network access. In practice, that means the runtime can choose the wrong platform sandbox behavior or set the wrong network-restriction environment for a command even when config has already separated those concerns.
This PR carries the split policies through the runtime so sandbox selection, process spawning, and exec handling can consult the policy that actually matters.
What changed
FileSystemSandboxPolicyandNetworkSandboxPolicythroughTurnContext,ExecRequest, sandbox attempts, shell escalation state, unified exec, and app-server exec overridescore/src/sandboxing/mod.rsandcore/src/exec.rsto key offFileSystemSandboxPolicy.kindplusNetworkSandboxPolicy, rather than inferring behavior only from the legacySandboxPolicycore/src/spawn.rsand the platform wrappers to useNetworkSandboxPolicywhen deciding whether to setCODEX_SANDBOX_NETWORK_DISABLEDExternalSandboxcompatibility projections aligned with the split policies, including explicit user-shell execution and Windows restricted-token routingcore,app-server, andlinux-sandboxto pass the split policies explicitlyVerification
core/tests/suite/user_shell_cmd.rsto verifyRunUserShellCommanddoes not inheritCODEX_SANDBOX_NETWORK_DISABLEDfrom the active turncore/src/exec.rsfor Windows restricted-token sandbox selection when the legacy projection isExternalSandboxlinux-sandbox/tests/suite/landlock.rsto exercise the split-policy exec pathjust clippyStack created with Sapling. Best reviewed with ReviewStack.