config: add initial support for the new permission profile config language in config.toml

[bolinfest]

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

---

Stack created with Sapling. Best reviewed with ReviewStack.

• linux-sandbox: honor split filesystem policies in bwrap #13453
• protocol: keep root carveouts sandboxed #13452
• sandboxing: preserve denied paths when widening permissions #13451
• linux-sandbox: plumb split sandbox policies through helper #13449
• seatbelt: honor split filesystem sandbox policies #13448
• safety: honor filesystem policy carveouts in apply_patch #13445
• protocol: derive effective file access from filesystem policies #13440
• sandboxing: plumb split sandbox policies through runtime #13439
• -> config: add initial support for the new permission profile config language in config.toml #13434

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 57adb8739f

ℹ️ 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]

why is this expecting a top level [network] entry? shouldn't it be permissions.<profile>.network? we don't need backwards compatibility here..

[bolinfest]

Yes, it seems like Codex was trying to be "helpful" on the backwards compatibility front. I'll remove...