feat: reuse low-risk Guardian approvals#26333
Open
viyatb-oai wants to merge 1 commit into
Open
Conversation
Co-authored-by: Codex noreply@openai.com
Contributor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 97d33ed350
ℹ️ 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".
Comment on lines
+150
to
+153
| return with_cached_approval( | ||
| &session.services, | ||
| "shell", | ||
| keys, |
Contributor
There was a problem hiding this comment.
Do not reuse command approval for network retry
When Guardian is enabled for OnRequest/granular approvals, the first low-risk approval now stores this command key before the sandboxed run executes. If that same run is then blocked by managed network access, orchestrator.rs deliberately asks for a fresh retry approval with network_approval_context set, but this cache lookup uses the same command/cwd/sandbox key and returns ApprovedForSession without calling Guardian, so the retry can proceed without the network-specific review that was supposed to happen for the blocked host. The same pattern was added in unified_exec.rs as well; the cache needs to distinguish or bypass network retry approvals.
Useful? React with 👍 / 👎.
Comment on lines
+148
to
+151
| assessment.user_authorization, | ||
| GuardianUserAuthorization::Low | ||
| | GuardianUserAuthorization::Medium | ||
| | GuardianUserAuthorization::High |
Contributor
There was a problem hiding this comment.
Require clear authorization before caching
GuardianUserAuthorization::Low is defined in the Guardian policy as weak or ambiguous authorization, but including it here makes that action reusable for the whole session whenever the risk is low. In a case where Guardian says the command only loosely follows from the user's goal (low) but allows it because the intrinsic risk is low, this turns a one-off auto-review into a session approval for the same command/key, which broadens the permission boundary beyond explicitly authorized actions.
Useful? React with 👍 / 👎.
Comment on lines
+575
to
+576
| if guardian_assessment_allows_session_reuse(&assessment) { | ||
| ReviewDecision::ApprovedForSession |
Contributor
There was a problem hiding this comment.
Keep session reuse off non-command approvals
This return path applies to every GuardianApprovalRequest, not just the shell/unified-exec paths that now have exact cache keys. If Guardian low-risk-allows a direct network approval or MCP tool approval, downstream code maps ApprovedForSession to session_approved_hosts or AcceptForSession, so later requests to the same host/tool can skip review even though the original approval was for one concrete request. The session-scoped result should be limited to approval surfaces with an explicit, narrow reuse key.
Useful? React with 👍 / 👎.
Comment on lines
+147
to
+152
| && matches!( | ||
| assessment.user_authorization, | ||
| GuardianUserAuthorization::Low | ||
| | GuardianUserAuthorization::Medium | ||
| | GuardianUserAuthorization::High | ||
| ) |
Contributor
There was a problem hiding this comment.
Update the Guardian prompt to emit authorization
The existing Guardian output contract tells the reviewer to answer low-risk actions with only {"outcome":"allow"}, and the parser defaults missing user_authorization to Unknown. With this predicate requiring a non-unknown authorization, a normal low-risk allow that follows the prompt will never become ApprovedForSession, so the new reuse path will mostly not activate unless the reviewer ignores its low-risk response instructions. The prompt/schema expectations need to be updated alongside this check.
Useful? React with 👍 / 👎.
This was referenced Jun 4, 2026
viyatb-oai
added a commit
that referenced
this pull request
Jun 8, 2026
## Why Auto Review should remain the effective approval reviewer when settings cross runtime boundaries. A config or app-server round trip must not change the reviewer identity, and delegated work must not silently fall back to user review. This requires both a stable canonical serialized value and propagation of the effective setting. `auto_review` is the canonical value across protocol and app-server output, while `guardian_subagent` remains accepted as backward-compatible input. ## What changed - serialize `ApprovalsReviewer::AutoReview` consistently as `auto_review` across core protocol and app-server v2 - continue accepting `guardian_subagent` when reading existing config or client requests - carry the active turn's approval reviewer into spawned agents - update config/debug expectations and add delegated-task regression coverage ## Scope This does not change Guardian policy or remove compatibility with existing `guardian_subagent` inputs. It preserves the selected reviewer across serialization, config reloads, app-server settings, and delegated task setup. Related Guardian changes are split independently: - #26231 adds denials and soft denials - #26334 retries transient reviewer failures - #26333 reuses narrowly scoped low-risk approvals - #26232 adds TUI denial recovery ## Validation - `just test -p codex-app-server-protocol` (224 passed) - regression coverage for delegated task reviewer propagation - serialization coverage for canonical `auto_review` output and legacy `guardian_subagent` input --------- Co-authored-by: saud-oai <saud@openai.com>
dkropachev
pushed a commit
to dkropachev/codex
that referenced
this pull request
Jun 9, 2026
## Why Auto Review should remain the effective approval reviewer when settings cross runtime boundaries. A config or app-server round trip must not change the reviewer identity, and delegated work must not silently fall back to user review. This requires both a stable canonical serialized value and propagation of the effective setting. `auto_review` is the canonical value across protocol and app-server output, while `guardian_subagent` remains accepted as backward-compatible input. ## What changed - serialize `ApprovalsReviewer::AutoReview` consistently as `auto_review` across core protocol and app-server v2 - continue accepting `guardian_subagent` when reading existing config or client requests - carry the active turn's approval reviewer into spawned agents - update config/debug expectations and add delegated-task regression coverage ## Scope This does not change Guardian policy or remove compatibility with existing `guardian_subagent` inputs. It preserves the selected reviewer across serialization, config reloads, app-server settings, and delegated task setup. Related Guardian changes are split independently: - openai#26231 adds denials and soft denials - openai#26334 retries transient reviewer failures - openai#26333 reuses narrowly scoped low-risk approvals - openai#26232 adds TUI denial recovery ## Validation - `just test -p codex-app-server-protocol` (224 passed) - regression coverage for delegated task reviewer propagation - serialization coverage for canonical `auto_review` output and legacy `guardian_subagent` input --------- Co-authored-by: saud-oai <saud@openai.com>
dkropachev
pushed a commit
to dkropachev/codex
that referenced
this pull request
Jun 9, 2026
## Why Auto Review should remain the effective approval reviewer when settings cross runtime boundaries. A config or app-server round trip must not change the reviewer identity, and delegated work must not silently fall back to user review. This requires both a stable canonical serialized value and propagation of the effective setting. `auto_review` is the canonical value across protocol and app-server output, while `guardian_subagent` remains accepted as backward-compatible input. ## What changed - serialize `ApprovalsReviewer::AutoReview` consistently as `auto_review` across core protocol and app-server v2 - continue accepting `guardian_subagent` when reading existing config or client requests - carry the active turn's approval reviewer into spawned agents - update config/debug expectations and add delegated-task regression coverage ## Scope This does not change Guardian policy or remove compatibility with existing `guardian_subagent` inputs. It preserves the selected reviewer across serialization, config reloads, app-server settings, and delegated task setup. Related Guardian changes are split independently: - openai#26231 adds denials and soft denials - openai#26334 retries transient reviewer failures - openai#26333 reuses narrowly scoped low-risk approvals - openai#26232 adds TUI denial recovery ## Validation - `just test -p codex-app-server-protocol` (224 passed) - regression coverage for delegated task reviewer propagation - serialization coverage for canonical `auto_review` output and legacy `guardian_subagent` input --------- Co-authored-by: saud-oai <saud@openai.com>
dkropachev
pushed a commit
to dkropachev/codex
that referenced
this pull request
Jun 9, 2026
## Why Auto Review should remain the effective approval reviewer when settings cross runtime boundaries. A config or app-server round trip must not change the reviewer identity, and delegated work must not silently fall back to user review. This requires both a stable canonical serialized value and propagation of the effective setting. `auto_review` is the canonical value across protocol and app-server output, while `guardian_subagent` remains accepted as backward-compatible input. ## What changed - serialize `ApprovalsReviewer::AutoReview` consistently as `auto_review` across core protocol and app-server v2 - continue accepting `guardian_subagent` when reading existing config or client requests - carry the active turn's approval reviewer into spawned agents - update config/debug expectations and add delegated-task regression coverage ## Scope This does not change Guardian policy or remove compatibility with existing `guardian_subagent` inputs. It preserves the selected reviewer across serialization, config reloads, app-server settings, and delegated task setup. Related Guardian changes are split independently: - openai#26231 adds denials and soft denials - openai#26334 retries transient reviewer failures - openai#26333 reuses narrowly scoped low-risk approvals - openai#26232 adds TUI denial recovery ## Validation - `just test -p codex-app-server-protocol` (224 passed) - regression coverage for delegated task reviewer propagation - serialization coverage for canonical `auto_review` output and legacy `guardian_subagent` input --------- Co-authored-by: saud-oai <saud@openai.com>
dkropachev
pushed a commit
to dkropachev/codex
that referenced
this pull request
Jun 9, 2026
## Why Auto Review should remain the effective approval reviewer when settings cross runtime boundaries. A config or app-server round trip must not change the reviewer identity, and delegated work must not silently fall back to user review. This requires both a stable canonical serialized value and propagation of the effective setting. `auto_review` is the canonical value across protocol and app-server output, while `guardian_subagent` remains accepted as backward-compatible input. ## What changed - serialize `ApprovalsReviewer::AutoReview` consistently as `auto_review` across core protocol and app-server v2 - continue accepting `guardian_subagent` when reading existing config or client requests - carry the active turn's approval reviewer into spawned agents - update config/debug expectations and add delegated-task regression coverage ## Scope This does not change Guardian policy or remove compatibility with existing `guardian_subagent` inputs. It preserves the selected reviewer across serialization, config reloads, app-server settings, and delegated task setup. Related Guardian changes are split independently: - openai#26231 adds denials and soft denials - openai#26334 retries transient reviewer failures - openai#26333 reuses narrowly scoped low-risk approvals - openai#26232 adds TUI denial recovery ## Validation - `just test -p codex-app-server-protocol` (224 passed) - regression coverage for delegated task reviewer propagation - serialization coverage for canonical `auto_review` output and legacy `guardian_subagent` input --------- Co-authored-by: saud-oai <saud@openai.com>
dkropachev
pushed a commit
to dkropachev/codex
that referenced
this pull request
Jun 9, 2026
## Why Auto Review should remain the effective approval reviewer when settings cross runtime boundaries. A config or app-server round trip must not change the reviewer identity, and delegated work must not silently fall back to user review. This requires both a stable canonical serialized value and propagation of the effective setting. `auto_review` is the canonical value across protocol and app-server output, while `guardian_subagent` remains accepted as backward-compatible input. ## What changed - serialize `ApprovalsReviewer::AutoReview` consistently as `auto_review` across core protocol and app-server v2 - continue accepting `guardian_subagent` when reading existing config or client requests - carry the active turn's approval reviewer into spawned agents - update config/debug expectations and add delegated-task regression coverage ## Scope This does not change Guardian policy or remove compatibility with existing `guardian_subagent` inputs. It preserves the selected reviewer across serialization, config reloads, app-server settings, and delegated task setup. Related Guardian changes are split independently: - openai#26231 adds denials and soft denials - openai#26334 retries transient reviewer failures - openai#26333 reuses narrowly scoped low-risk approvals - openai#26232 adds TUI denial recovery ## Validation - `just test -p codex-app-server-protocol` (224 passed) - regression coverage for delegated task reviewer propagation - serialization coverage for canonical `auto_review` output and legacy `guardian_subagent` input --------- Co-authored-by: saud-oai <saud@openai.com>
dkropachev
pushed a commit
to dkropachev/codex
that referenced
this pull request
Jun 9, 2026
## Why Auto Review should remain the effective approval reviewer when settings cross runtime boundaries. A config or app-server round trip must not change the reviewer identity, and delegated work must not silently fall back to user review. This requires both a stable canonical serialized value and propagation of the effective setting. `auto_review` is the canonical value across protocol and app-server output, while `guardian_subagent` remains accepted as backward-compatible input. ## What changed - serialize `ApprovalsReviewer::AutoReview` consistently as `auto_review` across core protocol and app-server v2 - continue accepting `guardian_subagent` when reading existing config or client requests - carry the active turn's approval reviewer into spawned agents - update config/debug expectations and add delegated-task regression coverage ## Scope This does not change Guardian policy or remove compatibility with existing `guardian_subagent` inputs. It preserves the selected reviewer across serialization, config reloads, app-server settings, and delegated task setup. Related Guardian changes are split independently: - openai#26231 adds denials and soft denials - openai#26334 retries transient reviewer failures - openai#26333 reuses narrowly scoped low-risk approvals - openai#26232 adds TUI denial recovery ## Validation - `just test -p codex-app-server-protocol` (224 passed) - regression coverage for delegated task reviewer propagation - serialization coverage for canonical `auto_review` output and legacy `guardian_subagent` input --------- Co-authored-by: saud-oai <saud@openai.com>
dkropachev
pushed a commit
to dkropachev/codex
that referenced
this pull request
Jun 9, 2026
## Why Auto Review should remain the effective approval reviewer when settings cross runtime boundaries. A config or app-server round trip must not change the reviewer identity, and delegated work must not silently fall back to user review. This requires both a stable canonical serialized value and propagation of the effective setting. `auto_review` is the canonical value across protocol and app-server output, while `guardian_subagent` remains accepted as backward-compatible input. ## What changed - serialize `ApprovalsReviewer::AutoReview` consistently as `auto_review` across core protocol and app-server v2 - continue accepting `guardian_subagent` when reading existing config or client requests - carry the active turn's approval reviewer into spawned agents - update config/debug expectations and add delegated-task regression coverage ## Scope This does not change Guardian policy or remove compatibility with existing `guardian_subagent` inputs. It preserves the selected reviewer across serialization, config reloads, app-server settings, and delegated task setup. Related Guardian changes are split independently: - openai#26231 adds denials and soft denials - openai#26334 retries transient reviewer failures - openai#26333 reuses narrowly scoped low-risk approvals - openai#26232 adds TUI denial recovery ## Validation - `just test -p codex-app-server-protocol` (224 passed) - regression coverage for delegated task reviewer propagation - serialization coverage for canonical `auto_review` output and legacy `guardian_subagent` input --------- Co-authored-by: saud-oai <saud@openai.com>
dkropachev
pushed a commit
to dkropachev/codex
that referenced
this pull request
Jun 9, 2026
## Why Auto Review should remain the effective approval reviewer when settings cross runtime boundaries. A config or app-server round trip must not change the reviewer identity, and delegated work must not silently fall back to user review. This requires both a stable canonical serialized value and propagation of the effective setting. `auto_review` is the canonical value across protocol and app-server output, while `guardian_subagent` remains accepted as backward-compatible input. ## What changed - serialize `ApprovalsReviewer::AutoReview` consistently as `auto_review` across core protocol and app-server v2 - continue accepting `guardian_subagent` when reading existing config or client requests - carry the active turn's approval reviewer into spawned agents - update config/debug expectations and add delegated-task regression coverage ## Scope This does not change Guardian policy or remove compatibility with existing `guardian_subagent` inputs. It preserves the selected reviewer across serialization, config reloads, app-server settings, and delegated task setup. Related Guardian changes are split independently: - openai#26231 adds denials and soft denials - openai#26334 retries transient reviewer failures - openai#26333 reuses narrowly scoped low-risk approvals - openai#26232 adds TUI denial recovery ## Validation - `just test -p codex-app-server-protocol` (224 passed) - regression coverage for delegated task reviewer propagation - serialization coverage for canonical `auto_review` output and legacy `guardian_subagent` input --------- Co-authored-by: saud-oai <saud@openai.com>
dkropachev
pushed a commit
to dkropachev/codex
that referenced
this pull request
Jun 9, 2026
## Why Auto Review should remain the effective approval reviewer when settings cross runtime boundaries. A config or app-server round trip must not change the reviewer identity, and delegated work must not silently fall back to user review. This requires both a stable canonical serialized value and propagation of the effective setting. `auto_review` is the canonical value across protocol and app-server output, while `guardian_subagent` remains accepted as backward-compatible input. ## What changed - serialize `ApprovalsReviewer::AutoReview` consistently as `auto_review` across core protocol and app-server v2 - continue accepting `guardian_subagent` when reading existing config or client requests - carry the active turn's approval reviewer into spawned agents - update config/debug expectations and add delegated-task regression coverage ## Scope This does not change Guardian policy or remove compatibility with existing `guardian_subagent` inputs. It preserves the selected reviewer across serialization, config reloads, app-server settings, and delegated task setup. Related Guardian changes are split independently: - openai#26231 adds denials and soft denials - openai#26334 retries transient reviewer failures - openai#26333 reuses narrowly scoped low-risk approvals - openai#26232 adds TUI denial recovery ## Validation - `just test -p codex-app-server-protocol` (224 passed) - regression coverage for delegated task reviewer propagation - serialization coverage for canonical `auto_review` output and legacy `guardian_subagent` input --------- Co-authored-by: saud-oai <saud@openai.com>
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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
Guardian currently asks again for repeated low-risk actions even when the reviewer has already confirmed explicit user authorization in the transcript. Reusing that narrow approval reduces repetitive prompts without broadening the permission boundary.
What changed
allowassessments with explicit user authorizationScope
This PR is independent and targets
main. It does not add denial kinds, reviewer retries, or UI behavior.Split from #26128. Related independent PRs: #26231, #26334, and #26232.
Validation
just test -p codex-core guardian