Auto-review approvals should support optional human fallback on deny/abort

[aaroniscode]

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 true

Or, 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.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Tool call was cancelled because of safety risks: safety layer hallucinates reasons why a tool call is unsafe and blocks it without manual approval #21186
• Automatic approval review fails on Microsoft Foundry/Azure OpenAI because codex-auto-review is not deployable #21928
• MCP Toolbox for Databases read-only SQL call is blocked by safety guard after explicit approval (interactive mode) #20337

Powered by Codex Action

[aaroniscode]

Thanks for flagging these. I reviewed the suggested duplicates, and I think this issue is related but not a duplicate.

• Tool call was cancelled because of safety risks: safety layer hallucinates reasons why a tool call is unsafe and blocks it without manual approval #21186 and MCP Toolbox for Databases read-only SQL call is blocked by safety guard after explicit approval (interactive mode) #20337 are bug reports about safety/tool-call blocking, especially around MCP calls and cases where explicit approval is not enough to proceed.
• Automatic approval review fails on Microsoft Foundry/Azure OpenAI because codex-auto-review is not deployable #21928 is closer, but it is specifically about codex-auto-review failing 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 returns denied or aborted, 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 -> user fallback path.