Agent PR review

Cloud coding agents (Cursor, GitHub’s coding agent) open a pull request for each bug Mushi sends them, and spend-down mode can send dozens a day. Most of those pull requests are fine. Some quietly delete a feature, ignore part of the bug, rely on a framework’s private internals, or make a product decision nobody asked for. Before you merge one, Mushi has Claude Opus 5.5 read it the way a careful reviewer would.

What you see

Each cloud-agent fix gets a verdict a few minutes after its pull request opens:

Verdict	Meaning	Merging from Mushi
merge	Fixes the bug, nothing else to worry about	Works as usual
fix first	Fixes or nearly fixes it; read the findings	Works; the merge dialog lists the findings
hold	Does not fix the bug, could break something, removes something users rely on, needs your decision, or part of the code was too large to read	Refused until a project member ticks Merge anyway in the console and gives a reason

The verdict appears in the fix timeline, in the Merge PR dialog, in get_fix_timeline (review), and as one comment on the pull request. Each finding names a file and line, what is wrong, and the smallest fix. The review also lists any behaviour the change removes, and any decision it took that you should make yourself.

When the verdict is merge or fix first, Mushi also marks the pull request ready for review. Repos that skip CI on drafts then run their checks; a hold stays a draft.

A pull request with no review merges as it always has. The dialog says Not reviewed so you know to read the diff yourself.

When the agent pushes new commits, Mushi reviews the new version a few minutes later. Until that review finishes, the old verdict still applies: a hold keeps blocking, and a “merge” about an older commit reads older commit and counts as not reviewed. Mushi always merges exactly the commit it checked; if the pull request changes in between, nothing is merged.

Overriding a hold is a person’s decision: it works only from the console, by a project member who is not a viewer, with a reason that goes in the audit log. The CLI and MCP tools cannot override. While a fix’s first review is still running, the CLI and MCP wait for it; in the console you can merge after confirming that you want to skip it.

What the review checks

Does the change fix the cause of the reported bug, not just a symptom?
What could it break: retry or reload loops, lost error handling, changed defaults?
What does it remove: features, settings, flows, saved state?
Did it take a product or design decision on its own (copy, pricing, app-wide visuals with no screenshots)?
Does it change things the bug report did not ask for?
Do its tests fail without the fix and pass with it?
Security: secrets, removed permission checks, unsafe HTML, new dependencies.
Code conventions visible in the diff: private framework APIs, dead code, disabled lint or type checks.

The bug report and the pull request are treated as untrusted text. If the diff contains instructions aimed at a reviewer or an AI, the review reports them as a security finding instead of following them.

Re-running a review

After the agent (or you) pushes fixes, press Re-run review in the merge dialog, or run:


mushi fixes review <fixId>          # start a new review
mushi fixes review <fixId> --show   # read the current one

The last verdict stays in force until the new review finishes, so re-running never unlocks a hold by itself. A fix can be re-reviewed at most three times an hour, and not while a review is already running. Asking again about a hold on the same commit needs a person in the console.

When the review says “fix first”

A fix first verdict means the change is close but has findings. Mushi can send the pull request back to a cloud agent once, with those findings, so you don’t have to copy them over yourself.

Turn it on under Settings → AI keys → Cursor → Review follow-ups. It is off until an owner or admin turns it on, and it applies to every app in the organization.
Mushi starts a new Cursor agent on the same pull request. The agent gets the bug’s summary and diagnosis and every finding. It is told to fix exactly those, add tests, and push to the same branch.
Each pull request is sent back at most twice, and only once per commit. A hold, a merge, a closed pull request, or auto-fix turned off sends nothing.
Findings are filtered first. A finding about a file the pull request did not change, a finding that reads like an instruction to the agent, and a suggested fix that carries an outside link or a shell command are all left out.
When the agent pushes, Mushi reviews the new commit. The settings card shows the latest follow-ups and the verdict each one got after.
Each follow-up counts toward the app’s daily auto-fix limit. The organization limit defaults to 30 a day. Pick which Cursor key and model to use, or let each app use the key its fixes already use. Mushi’s own platform key is never used.

Spend-down and its safety stop

Spend-down mode (Settings → AI keys → Cursor, or mushi keys spend-down) uses a Cursor key’s credits before they expire, by sending the best open bugs to cloud agents. It watches the review verdicts as it goes. When an app’s recent spend-down pull requests are clearly poor (too few merge verdicts, too many hold verdicts, or too many runs with no pull request), Mushi pauses spend-down for that app and sends one test fix a day until the results recover. Press Resume in the console to restart it sooner. The settings card shows a 7-day scoreboard per key: runs, pull requests, verdicts, merges, and what the reviews cost.

Cost and keys

The review runs on your own Anthropic key (Settings → AI keys), your organization’s shared one, or an owner’s all-apps key. It never runs on Mushi’s platform key. Without a key it is skipped, and the fix shows Review skipped with the reason. A review usually costs $0.05 to $0.20, depending on the size of the diff; the most one review can cost, including retries, is about $0.90. It counts toward your monthly AI budget.

Turn it off under Settings → General → Review cloud agent pull requests. Only owners and admins can change it.

For operators

The agent-pr-review edge function drains a queue in fix_reviews every 10 minutes, three reviews at a time and one per project per run. To review pull requests that were already open when the feature shipped, call it with { "backfill": true, "limit": 50 } using the internal caller token. The design and the rejected alternatives are in ADR 0030.