Developers Asked for a Reviewer, Not a Bypass. The Fix Is Still an Open Pull Request.
In the open source coding agent oh-my-pi's own issue tracker, a developer states the actual demand plainly. Fewer interruptions without unlimited permission. A pull request opened weeks earlier answers with a second model that reviews the first one's commands before they run. Its own review history, still open and unmerged, is the more interesting document.
Event analysed: . This analysis was published on 7 September 2026.
Issue 11053 on the open source coding agent project oh-my-pi, opened 6 September 2026 by a user identified as mimiq4343 and labeled agent, enhancement, tool and triaged, asks for AI reviewed tool approvals, described in the issue's own title as related to an existing pull request, number 6263. The issue states its motivation in one sentence: routine command approvals interrupt development repeatedly. It then rules out the two answers already available. Setting tools.approval.bash to allow reduces interruptions, the issue says, but does not add a semantic risk assessment. Yolo is not the desired solution either, because the goal is delegated review, not bypassing review. The issue gives one worked example of what a semantic distinction looks like in practice: removing a specific disposable build directory created by the current task is not the same request as removing pre existing user data, even though both are delete operations a static rule cannot tell apart. What it asks for is a mechanism that separates the agent executing a command from a reviewer deciding whether it may proceed, with three outcomes: allow low risk work, request human confirmation for anything ambiguous, and keep existing deny rules for what is forbidden outright. It also specifies what should happen when the reviewer itself is unavailable: missing reviewer configuration, a timeout, malformed output or an unreachable model should fail closed, either asking the user directly or blocking the call, never defaulting to approval. Pull request 6263, titled Add approve for me approval mode with LLM reviewer, was opened six weeks earlier, on 22 July 2026, by a contributor identified as maatheusgois dd, and remains open and unmerged as of this record's publication. It proposes exactly the mechanism the later issue asks for by name: an approve for me mode, framed in the pull request's own description as a middle ground between always ask and yolo, that routes exec tier tool calls through a separate reviewing model rather than either prompting for every call or skipping review altogether. What makes the pull request worth reading past its own summary is its review history. At the commit this record read, 36d0b89, five defects raised in earlier review rounds had already been addressed by two subsequent commits. A model response could return a risk level of critical and an outcome of allow in the same structured output, and an earlier version of the wrapper trusted that outcome field directly, meaning a reviewer's own mislabeled decision could still authorize a dangerous call; commit ea8c79b changed the wrapper to derive the outcome from the validated risk and authorization fields instead of the model's own outcome label, so a critical classification cannot carry an allow past deterministic policy. A cached approval was keyed only on the tool name and its arguments, which meant the identical command in a different session or a different workspace could reuse an approval decided under a different authority context entirely; the same commit moved cache and circuit breaker state into maps scoped to the session id. Prompts that named an explicit human mandate could still be routed to the automated reviewer rather than staying on the path that requires an actual person; the fix keeps explicit prompt tools on the human path. A tool call argument longer than 4000 characters was truncated before being shown to the reviewer, which means the reviewer could be asked to approve a prefix of an action rather than the whole of it; the fix fails closed on truncation rather than reviewing a partial action. A circuit breaker meant to stop repeated automated denials from cycling indefinitely was defined in the code but never wired into the execution path, and a separate approval gate could double prompt for the same call; commit 36d0b89 wires the breaker into the wrapper, resets it at the start of each turn, counts a cached allow toward resetting a run of consecutive denials, reads recent user messages newest first when establishing authorization context, and aborts the turn outright, rather than retrying, when the breaker trips. Reviewers on the pull request had, at the time this record was read, flagged only minor edge cases in how a multi part message is ordered before reaching the reviewer, described here as an open nit rather than a material defect. Nothing in either the issue or the pull request states that approve for me has shipped in any released version of oh-my-pi, and this record does not treat it as shipped functionality. What is established is narrower and, this record thinks, more durable: a practitioner naming a specific third option between a static allow rule and unrestricted execution, and an unmerged implementation whose own review history is a working example of the distinction the issue asks for, a delegated reviewer's decision is not the same fact as authorization, and needs its own constraints to stay one.
Most complaints about approval prompts read the same way. Too many interruptions, developer wants fewer of them, someone eventually suggests turning approval off. Issue 11053, filed against the open source coding agent oh-my-pi on 6 September 2026, does not read that way, and the difference is worth sitting with before getting to the pull request that tries to answer it.
What the issue actually asks for
The person who opened it, a user identified as mimiq4343, states the problem in one sentence: routine command approvals interrupt development repeatedly. That much is ordinary. What follows is not.
The issue names the two easy answers and rejects both, in its own words. Setting tools.approval.bash to allow reduces interruptions, it says, but does not add a semantic risk assessment. A static allowlist removes the prompt. It does not add any judgment about what the command actually does. And then, just as directly: yolo is not the desired solution either. The goal is delegated review, not bypassing review.
That is a sentence with a specific shape. It is not asking for less oversight. It is asking for oversight that happens somewhere other than in front of the developer's own eyes, on every single call.
The issue gives one example of what a semantic distinction would need to do that a static rule cannot. Removing a specific disposable build directory the current task created is a different request from removing pre existing user data, even though both are, mechanically, a delete. A command allowlist keyed on the program name cannot tell those apart. A human reading the actual target can.
What the issue proposes is a role split: an agent that executes, and a separate reviewer that decides whether the execution may proceed, with three possible outcomes rather than two. Allow the low risk work outright. Ask a human when the action is ambiguous. Keep the existing deny rules in force for whatever is forbidden regardless of context. And it is specific about failure. Missing reviewer configuration, a timeout, output that does not parse, or a model that cannot be reached, none of those should default to approval. They should ask the user directly, or block the call.
The pull request that already exists
The issue's own title calls out pull request 6263 as related, and it is more than related. Titled Add approve for me approval mode with LLM reviewer, opened by a contributor identified as maatheusgois dd on 22 July 2026, six weeks before the issue that names it, it proposes the mechanism the issue asks for almost exactly. Its own description frames approve for me as a middle ground between always ask and yolo: a mode that routes exec tier tool calls through a separate reviewing model, which evaluates risk and can auto approve low risk actions or deny risky ones, rather than prompting for everything or trusting everything.
As of this record's publication, the pull request is still open. It has not merged. Nothing here should be read as describing shipped oh-my-pi functionality, and this record is deliberate about that distinction throughout.
The review history is the actual evidence
What makes the pull request worth reading closely is not the proposal. It is what its own reviewers caught before the branch ever merged, and what the later commits did about it.
At the commit this record read, 36d0b89, five defects raised in earlier review rounds had already been addressed by two subsequent commits, ea8c79b and the head commit itself. Read together, they are a small case study in the difference between an automated reviewer and an authorization.
The first defect is the sharpest one. An earlier version of the reviewer wrapper could receive a structured model response carrying a risk level of critical and an outcome of allow in the same object, and trust the outcome field directly. A reviewer's own mislabeled decision, in other words, could still authorize a dangerous call, because nothing checked the label against the classification sitting right next to it. Commit ea8c79b changed that: the wrapper now derives the outcome from the validated risk and authorization fields rather than trusting whatever outcome string the model produced, so a critical classification cannot carry an allow past deterministic policy underneath it.
The second defect concerns memory rather than judgment. An approval cache was keyed only on the tool name and its arguments. The same command, textually identical, could reuse a cached approval in a different session or a different workspace, contexts where the authority behind the original approval may not still apply at all. The fix moves cache and circuit breaker state into maps scoped to the session id, so an approval earned in one context stops being available for reuse in another one it was never evaluated against.
The third defect is about which path a request travels. Tool calls carrying an explicit human mandate, a case where a person plainly authorized the action themselves, could still be routed through the automated reviewer instead of staying on the path that requires an actual person to answer. The fix keeps explicit prompt tools on the human path, rather than letting a delegated reviewer stand in for a human decision that was never actually delegated.
The fourth defect is a truncation problem with a security shape. A tool call argument longer than 4000 characters was cut before being shown to the reviewer. A reviewer asked to approve a prefix of an action is not reviewing the action, and a crafted argument could put the consequential part of a command past that cut point. The fix fails closed on truncation instead, rather than reviewing a partial picture of what would actually run.
The fifth defect is about a control that existed on paper without existing in practice. A circuit breaker meant to stop a run of repeated automated denials from cycling indefinitely was defined in the code but never wired into the execution path, and a separate approval gate could double prompt for the same call. The head commit, 36d0b89, wires the breaker into the wrapper, resets it at the start of each turn, counts a cached allow toward resetting a run of consecutive denials, reads recent user messages newest first when building authorization context, and aborts the turn outright, rather than retrying, once the breaker trips.
Reviewers on the pull request had, at the time this record was read, flagged only minor edge cases in how a multi part message is ordered before reaching the reviewer. This record treats that as an open nit, not a material defect standing between the current state of the branch and a mergeable one.
Not the same shape as auto mode, and not the same shape as an agent that can approve
Two records already in this corpus sit close to this one, and it is worth being precise about why none of them are the same story.
Claude Code's auto mode ships a classifier built into one vendor's own product, generally available, deciding whether a human needs to see a given action before it runs. GitHub Agentic Workflows' approve workflow run lets an agent request that a specific, narrowly scoped approval gate be satisfied, behind deterministic eligibility checks a maintainer configured in advance. Approve for me is neither shipped nor built in. It is a third party, still unmerged proposal for a general purpose reviewing layer, sitting in front of whatever tool call an agent wants to make, evaluated by a second model rather than a deterministic classifier or a fixed rule set. The mechanism is close in spirit to auto mode's own classifier. The maturity and the shape of the proposal are not close at all.
What this record thinks the evidence actually establishes
Strip away the specific project and the pattern underneath issue 11053 is not new to this corpus, but this is the clearest practitioner statement of it Moona Intelligence has read. Fewer prompts and more standing authority are not the same fact. A developer can want less interruption and still refuse yolo, in the same sentence, because what they are actually asking for is a different kind of review, not the absence of one.
The pull request's own defect history makes a second point just as directly. Building a delegated reviewer does not automatically produce a trustworthy one. A reviewer that can be told a call is critical and still say allow is not a control until something outside the reviewer's own output enforces the difference. A cached decision that travels across sessions without carrying its authority context is not a decision about the new context at all, it is a decision about a different one being reused. And a path built for a human's own explicit instruction has to stay a human path, or the delegation quietly swallows the one case it was never supposed to touch.
None of that is shipped. The pull request that demonstrates it is still open. What is on the record, as of 6 September 2026, is a developer naming the distinction precisely, and an implementation whose own review comments are the best evidence available that the distinction is real, and that getting it wrong the first time is the expected difficulty, not the exception.
Sources
This analysis interprets third-party reporting, research and announcements. Moona is not the original reporter of the underlying events.