Auto-review approvals should support optional human fallback on deny/abort
What variant of Codex are you using?
Codex Desktop / app-server approval flow, and likely CLI/TUI wherever approvals_reviewer = "auto_review" or the legacy guardian_subagent reviewer is supported.
What feature would you like to see?
Add an optional human fallback path for auto-review approval decisions.
Today, approval routing appears to be binary:
approvals_reviewer = "user"routes approval requests directly to the client/user.approvals_reviewer = "auto_review"routes approval requests to the reviewer subagent, which can approve, deny, or abort.
That works well for reducing approval friction, but when auto-review denies or aborts a request, the user has no first-class way to manually approve the exact same action from the normal approval UI. The agent can explain the denial and ask the user in chat, then retry the action after explicit user approval, but that is a conversational workaround rather than a native approval flow.
Proposed behavior
Support a mode where auto-review is tried first, and only denials/aborts are escalated to the user for manual review.
Possible config shape:
approvals_reviewer = "auto_review"
auto_review_user_fallback = "on-deny" # or trueOr, if this fits better as a single enum:
approvals_reviewer = "auto_review_then_user"Suggested v1 behavior:
- If auto-review approves: proceed exactly as it does today.
- If auto-review denies or aborts: surface the original approval request to the user, along with the auto-review rationale/risk metadata.
- If the user approves: proceed with the exact originally reviewed action.
- If the user declines/cancels or does not respond: preserve today's denied/aborted behavior.
- Preserve any hard deny policy categories where user approval must not override the decision.
Why this would help
The auto-review feature is excellent as a low-friction safety layer. The rough edge is that a conservative or mistaken denial can become a dead end even when the user is present and willing to explicitly approve the exact action after seeing the risk.
The app-server protocol already distinguishes user approval requests from auto-review notifications, and auto-review exposes useful review status/risk/rationale metadata. A fallback flow could combine those pieces: keep the reviewer as the first pass, but let a human make the final call for actions that are not absolute policy denials.
Safety considerations
This should fail closed:
- If the fallback prompt cannot be shown, treat the request as denied.
- If the user response does not clearly approve the exact action, treat it as denied.
- If the auto-review denial represents an absolute policy block, do not offer the fallback.
- The fallback prompt should include the auto-review rationale so the user understands why the action was denied before choosing.
Related context
The app-server docs currently describe approvalsReviewer values of "user" and "auto_review" and describe auto-review status values including approved, denied, and aborted. They also document the existing client-driven approval request flow for command/file approvals. This request is for an optional bridge between those two paths.
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks for flagging these. I reviewed the suggested duplicates, and I think this issue is related but not a duplicate.
codex-auto-reviewfailing on Microsoft Foundry/Azure OpenAI because the reviewer model is not deployable there, with manual approval fallback as one possible mitigation.This issue is a broader feature request for the approval routing behavior itself: when
approvals_reviewer = "auto_review"runs successfully but returnsdeniedoraborted, Codex should optionally surface the original approval request to the user for a final manual decision, including the auto-review rationale/risk metadata.So I see this as complementary to those issues rather than a duplicate. The common theme is “don’t turn a non-absolute automated block into a dead end,” but the requested product behavior here is specifically an optional
auto_review -> userfallback path.I want to add one more reason why this fallback is becoming increasingly important as model capabilities improve.
When auto-review denies an action, the model often does not naturally stop and wait for a better approval path. Instead, it may try to work around the denial by changing the plan, adding indirect steps, or introducing unnecessary scaffolding to avoid the blocked action. That can produce strange or overly complicated results, even when the user is present and would have explicitly approved the original action after seeing the risk.
A native
auto_review -> userfallback would make the safe path clearer: if the reviewer denies or aborts a non-absolute request, surface the exact original approval request to the user. If the user approves, continue with that action. If the user denies, stop. This avoids encouraging the agent to invent detours around the approval system.Generated with assistance from Codex CLI.
<img width="1802" height="651" alt="Image" src="https://github.com/user-attachments/assets/42061776-1fd4-4dbb-a826-2d0720185502" />
+1, this would be a very valuable feature for our org
In a perfect world, what I'm really imagining would be something like a fourth option for the auto-review agent to return. Instead of just
approved,denied, andaborted, adding something like anescalated. This could be treated the same way asdenieddepending on the user's config (or by necessity in headless envs, etc). It would naturally fail-closed by making sure existing policy prompts continued to counsel a "final"denieddecision, because theescalatedaction would be something new. This could be a "fuzzier", approval agent prompting cousin to the kind of rules changes proposed by #30598 and others.The scope of this change would be bigger than just "allow human review of denials"... but I think it could be worth it. In general, there's a real lack of "soft touch" options for enterprise admins, this could go a long way to filling that gap!