Auto-review converts explicit user approval into an unbound consent phrase loop

Open 💬 2 comments Opened Aug 1, 2026 by edsai
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Auto-review can turn an already explicit owner authorization into a repeated prose-confirmation loop that does not materially constrain the command being approved.

Observed behavior

  1. The user reviewed a detailed execution plan and explicitly directed the agent to execute it.
  2. Auto-review denied the boundary-crossing action and required a generated risk-acknowledgment paragraph.
  3. The requested paragraph did not bind approval to an exact command, executable, path, destination, expiry, or retry count.
  4. The user again explicitly approved execution. Relaying the requested authorization to the affected session was still denied.
  5. Invoking the documented /approve override was itself rejected as attempted policy circumvention.
  6. Even opening the built-in /feedback flow became impractical because Auto-review rejected reading the small tmux prompt needed to complete it.

Why this is unsafe product behavior

The loop creates consent theater rather than informed consent. Copying generated prose proves only that the words appeared in the transcript. It does not bind approval to the actual tool invocation. It also trains users to approve unread boilerplate, increases model usage, stalls time-sensitive work, and makes the documented override appear nonfunctional.

Expected behavior

  • Explicit user authorization given after a concrete plan should remain valid while the operation is unchanged.
  • If additional approval is required, the UI should bind it to the exact tool call or narrowly defined operation, not generated prose.
  • The system should clearly distinguish overridable denials from categorically non-overridable policy before asking for confirmation.
  • /approve should either perform the documented one-retry override or explain immediately why that denial class cannot be overridden.
  • Users should be able to switch approvals_reviewer from auto_review to user for the active session without restarting.
  • Repeated authorization wording should never substitute for command-bound scope.

Configuration

The affected session used workspace-write, approval_policy on-request, and approvals_reviewer auto_review. The user subsequently disabled Auto-review globally by changing approvals_reviewer to user.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 26 days ago

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

  • #36137
  • #36147

Powered by Codex Action

azolotov · 26 days ago

I saw the same approval loop with Linear. I asked Codex:

Post a detailed investigation comment on the Linear issue

Codex replied that “Linear blocked the comment” because it contained sensitive infrastructure details, then asked me to approve posting it. Linear did not block anything—Codex Auto Review did—and my original instruction already explicitly authorized posting that comment to that destination.

<img width="1512" height="672" alt="Image" src="https://github.com/user-attachments/assets/56485916-f640-4052-9319-b19e7eca25b3" />

Expected:

  • At the very least, say “Codex Auto Review blocked this action”; do not blame the connector unless it returned the rejection.
  • Honor the user's scoped, explicit request for the unchanged action and destination instead of requiring redundant approval.