Review on approval

Approving a pull request is the cheapest thing you can do on GitHub, and reading a diff carefully is one of the most expensive. Review on approval splits those apart: you press Approve to say "I want this in", and an independent reviewer that has actually read the diff decides whether it goes in.

It works on any pull request in a connected repository - one a Foxl coding agent opened, or one you pushed by hand. Foxl does not care who wrote the code.

What happens when you approve

1. You approve the PR on github.com (or from the Work tab).
2. Foxl wakes an independent reviewer. It is a separate agent from the one that writes code, with a restricted toolset and a GitHub token that is read-only on contents: it can read the repository and post a review, and it cannot push commits, edit files, or steer agents - GitHub enforces the first of those, not just the prompt.
3. It reads the changed files, grades the diff, and posts one review.
4. Then it either merges the PR and comments, or refuses and comments saying what needs to change.

Either way you get a comment on the PR. A silent refusal would be indistinguishable from the feature being switched off.

You do not have to approve to get the reviewer: Ask Foxl to review on the Work page runs it on any pull request in a connected repository. And when you want changes rather than a verdict, click a line number in the review pane's diff, say what should change, and Request changes sends each comment, with its file and line, back to the agent that opened the PR. See Work.

Your approval is a request, not the verdict

This is the part worth internalizing: the reviewer does not defer to your approval. It is told explicitly that your approval is what woke it up and that it is not evidence the code is correct. If you approve something broken, the reviewer's job is to say so and refuse the merge.

That is deliberate. A reviewer that agreed with every approval would be ceremony, and on this path a passing verdict can merge - so agreeableness would cost you a bad commit on your default branch.

Enabling it

Both switches live under Advanced on the Autonomy card of the Schedules page, and both are off in the default level:

• Review any PR when a human approves it - approving a PR wakes the reviewer. On its own this is a second-opinion feature: the reviewer grades and comments, and never merges.
• Merge when the reviewer approves - when the reviewer approves, it also merges. Only offered once the first switch is on, because a merge decision needs a verdict to read.

The top level, Merge its own green work, turns both on together with auto-merge; the other two levels leave both off, and setting them by hand reads as Custom. See Autonomous loop.

The merge method (squash, merge, rebase) and whether the branch is deleted afterwards are the same settings auto-merge uses. Squash is the default.

When it will not merge

The reviewer approving is necessary but not sufficient. Foxl re-reads the PR from GitHub at merge time and refuses, with a comment saying which of these applies:

• New commits landed after the review. A verdict is a statement about one commit, so it has to say which. The reviewer reports the commit it read, the merge is pinned to it, and Foxl refuses if that is no longer the head. If you push while a review is running, nothing merges - approve again to review the new head. If a verdict arrives without naming a commit at all, that is also a refusal: Foxl will not merge a change it cannot prove was read.
• GitHub is not ready to merge it. Conflicts, a required check that has not reported yet, a branch that is behind under a strict protection rule. Note that "no conflicts" is not the same question as "have the checks passed", and Foxl asks both. Branch protection still applies in full; this feature does not bypass it.
• Mergeability is still being computed. GitHub reports this as "unknown" rather than "no", so Foxl waits instead of guessing. Approve again to retry.
• The PR is a draft or closed.

In every one of these cases Foxl comments saying which applied, and the pull request is left exactly as it was - open, unmerged, and yours to merge by hand. Nothing about this feature can block a merge you would otherwise be able to do.

Rounds

A pull request gets at most six automated review rounds. Each round needs both a fresh approval from you and a genuinely new commit, so rounds only advance when someone decides they should - re-approving the same commit costs nothing and starts no second review. After the sixth Foxl comments and stops reviewing that PR; merging it is then yours to do.

If the review could not start

Two things have to hold on Foxl's side, and neither is anything you configure in your repository: the GitHub App receives the Pull request review event (separate from "Pull request review comment"), and the reviewer runtime is a build that can review a pull request outside a Foxl task. If either is missing, approving a PR with these switches on gets you a comment on the PR saying the review could not be started, and nothing merges. That comment is not a problem with your repository: merge by hand as you normally would, or turn the switch off until it is fixed.