Conversation
This was referenced Apr 24, 2026
Contributor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0250e437c9
ℹ️ 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".
3044a7c to
975ced4
Compare
095bb44 to
efc4b60
Compare
90bf568 to
47da6db
Compare
bolinfest
added a commit
that referenced
this pull request
Apr 24, 2026
## Why The profile conversion path still required a `cwd` even when it was only translating a legacy `SandboxPolicy` into a `PermissionProfile`. That made profile producers invent an ambient `cwd`, which is exactly the anchoring we are trying to remove from permission-profile data. A legacy workspace-write policy can be represented symbolically instead: `:cwd = write` plus read-only `:project_roots` metadata subpaths. This PR creates that cwd-free base so the rest of the stack can stop threading cwd through profile construction. Callers that actually need a concrete runtime filesystem policy for a specific cwd still have an explicitly named cwd-bound conversion. ## What Changed - `PermissionProfile::from_legacy_sandbox_policy` now takes only `&SandboxPolicy`. - `FileSystemSandboxPolicy::from_legacy_sandbox_policy` is now the symbolic, cwd-free projection for profiles. - The old concrete projection is retained as `FileSystemSandboxPolicy::from_legacy_sandbox_policy_for_cwd` for runtime/boundary code that must materialize legacy cwd behavior. - Workspace-write profiles preserve `CurrentWorkingDirectory` and `ProjectRoots` special entries instead of materializing cwd into absolute paths. ## Verification - `cargo check -p codex-protocol -p codex-core -p codex-app-server-protocol -p codex-app-server -p codex-exec -p codex-exec-server -p codex-tui -p codex-sandboxing -p codex-linux-sandbox -p codex-analytics --tests` - `just fix -p codex-protocol -p codex-core -p codex-app-server-protocol -p codex-app-server -p codex-exec -p codex-exec-server -p codex-tui -p codex-sandboxing -p codex-linux-sandbox -p codex-analytics` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19414). * #19395 * #19394 * #19393 * #19392 * #19391 * __->__ #19414
46f2411 to
c8f8161
Compare
f5c6803 to
69e51b2
Compare
This was referenced Apr 25, 2026
aacd108 to
2cc36a1
Compare
viyatb-oai
approved these changes
Apr 25, 2026
cdbbfa4 to
48d74e7
Compare
aibrahim-oai
approved these changes
Apr 25, 2026
71ce357 to
bb278c3
Compare
Collaborator
Author
|
Ugh, this was not actually merged! |
Collaborator
Author
Collaborator
Author
|
Re-published as #19606. |
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.
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
PermissionProfileis now the canonical permissions shape after #19231 because it can distinguishManaged,Disabled, andExternalenforcement while also carrying filesystem rules that legacySandboxPolicycannot represent cleanly. Core config and session state still needed to accept profile-backed permissions without forcing every profile through the strict legacy bridge, which rejected valid runtime profiles such as direct write roots.What Changed
Permissions.permission_profileandSessionConfiguration.permission_profileas constrained runtime state, while keepingsandbox_policyas a legacy compatibility projection.PermissionProfile, split filesystem/network policies, and legacySandboxPolicyprojections synchronized.SandboxPolicyexactly.glob_scan_max_depthwhen command/session profiles are narrowed.PermissionProfile::read_only()andPermissionProfile::workspace_write()presets that match legacy defaults.Verification
cargo test -p codex-core direct_write_rootscargo test -p codex-core runtime_roots_to_legacy_projectioncargo test -p codex-app-server requested_permissions_trust_project_uses_permission_profile_intentStack created with Sapling. Best reviewed with ReviewStack.