You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The core Op turn-context path should not carry both the new permissions model and the legacy SandboxPolicy model. Earlier PRs made user turns permission-profile-first; this follows through for turn-context updates so the session layer only sees PermissionProfile plus explicit active-profile provenance.
The app-server v2 boundary still accepts the legacy sandboxPolicy override for now. This PR keeps that API behavior by converting the legacy override into a concrete PermissionProfile before submitting the core op, then marks the active profile identity as cleared because a raw sandbox override is not a named profile selection.
What Changed
Removed sandbox_policy from Op::UserInputWithTurnContext and Op::OverrideTurnContext.
Added clear_active_permission_profile to those ops so callers can explicitly clear profile name/provenance when they submit a concrete permission profile derived from a legacy sandbox override.
Moved the legacy turn-context conversion out of core/src/session/handlers.rs and into the app-server request handling boundary.
Kept AppCommand profile-only for normal TUI commands while preserving unknown clear-provenance ops as Other instead of losing the clear signal.
Updated core, TUI, and memory startup test constructors to use the new explicit clear flag.
// Current app-server responses include `permissionProfile`. If it is absent,
// keep the TUI on its configured profile rather than rebuilding a lossy
// profile from the legacy `sandbox` compatibility field.
config.permissions.permission_profile()
Preserve server sandbox fallback when permissionProfile is absent
When permissionProfile is omitted, this now unconditionally uses the local config profile instead of deriving from the response’s legacy sandbox value. That causes permission drift for version-skewed or non-experimental app-server responses (where permissionProfile is optional): the resumed thread state in TUI can no longer reflect the server’s actual runtime permissions, so later turn overrides and permission UX can become inconsistent with what the server enforces. Restoring a sandbox-based fallback for this case (at least in remote mode) avoids silently mis-reconstructing thread permissions.
Closing this pull request because it has had no updates for more than 14 days. If you plan to continue working on it, feel free to reopen or open a new PR.
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
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
The core
Opturn-context path should not carry both the new permissions model and the legacySandboxPolicymodel. Earlier PRs made user turns permission-profile-first; this follows through for turn-context updates so the session layer only seesPermissionProfileplus explicit active-profile provenance.The app-server v2 boundary still accepts the legacy
sandboxPolicyoverride for now. This PR keeps that API behavior by converting the legacy override into a concretePermissionProfilebefore submitting the core op, then marks the active profile identity as cleared because a raw sandbox override is not a named profile selection.What Changed
sandbox_policyfromOp::UserInputWithTurnContextandOp::OverrideTurnContext.clear_active_permission_profileto those ops so callers can explicitly clear profile name/provenance when they submit a concrete permission profile derived from a legacy sandbox override.core/src/session/handlers.rsand into the app-server request handling boundary.AppCommandprofile-only for normal TUI commands while preserving unknown clear-provenance ops asOtherinstead of losing the clear signal.Verification
cargo check -p codex-protocol -p codex-core -p codex-tui -p codex-app-server --testscargo check -p codex-memories-write --testscargo test -p codex-core override_turn_contextjust fix -p codex-protocoljust fix -p codex-corejust fix -p codex-tuijust fix -p codex-app-serverjust fix -p codex-memories-writeStack created with Sapling. Best reviewed with ReviewStack.