Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 393a21dcd6
ℹ️ 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".
| let profiles_are_active = matches!( | ||
| permission_config_syntax, | ||
| Some(PermissionConfigSyntax::Profiles) | ||
| ) || (permission_config_syntax.is_none() | ||
| && has_permission_profiles); | ||
| ) || permission_config_syntax.is_none(); |
There was a problem hiding this comment.
Preserve implicit workspace-write overrides in default syntax
Treating permission_config_syntax.is_none() as profiles_are_active routes configs with no explicit permission syntax through built-in profiles, which bypasses ConfigToml::derive_permission_profile and therefore ignores [sandbox_workspace_write] knobs. A trusted/untrusted project that previously relied on implicit workspace-write plus sandbox_workspace_write (for network_access or extra writable_roots) will silently lose those settings after this change, changing runtime permissions for existing configs.
Useful? React with 👍 / 👎.
Why
The migration away from
SandboxPolicyneeds new configs to start from permissions profiles instead of deriving profiles from legacy sandbox modes. At the same time, existing users may have emptyconfig.tomlfiles, and we should not rewrite user-owned config files that may live in shared repositories.This PR introduces built-in profile names so an empty config can resolve to a canonical
PermissionProfile, while explicit named[permissions]profiles still behave predictably.What changed
default_permissionsprofile names::read-onlymaps toPermissionProfile::read_only().:workspacemaps to the workspace-write profile, including project-root metadata carveouts.:danger-no-sandboxmaps toPermissionProfile::Disabled, preserving the distinction between no sandbox and a broad managed sandbox.:prefix for built-in profiles so user-defined[permissions]profiles cannot collide with future built-ins.default_permissionsto reference a built-in profile without requiring a[permissions]table.:workspacewhen the platform supports that sandbox, while roots without a trust decision use:read-only.sandbox_modeconfigs on the legacy path, and still rejects user-defined[permissions]profiles that omitdefault_permissionsso we do not silently guess among custom profiles.Verification
cargo test -p codex-core builtin --libDocumentation
Public Codex config docs should mention these built-in names when the
[permissions]config format is ready to document as stable.Stack created with Sapling. Best reviewed with ReviewStack.