Auto‑merge
On Max and Enterprise, AM can merge a pull request for you — hands‑off, with no human review. Auto‑merge fires as soon as the change clears AM's automated gates. Gating it on earned trust is an optional extra, not a requirement (see Gate it on earned trust below).
What must be true to auto‑merge
A PR auto‑merges only when all of these hold:
- Auto‑merge is enabled for the repo and the plan allows it (Max+).
- The Verification Gate passed (green) — mandatory. A red gate produces a draft PR that is never auto‑merged. (A repo with no gate configured also can't reach the auto‑merge‑ready trust tier.)
- AM's automated review gates didn't flag the change — the objective‑adherence (intent) and architecture‑conformance critics. A concern or fail on either holds the merge for you.
- (Optional) Earned trust — only if you enabled "Only when trust is earned": the repo must have reached the auto‑merge‑ready tier.
There is no human review and no manual approval step on auto‑merge — that's what "hands‑off" means. If you want a human in the loop, that's the Pro posture: AM reviews + approves, you press merge. If any gate above isn't satisfied, the PR is left as a reviewable (or draft) PR instead.
Enabling it
In Repo settings, toggle Auto‑merge. On plans below Max the toggle is inert — review/merge stays with you.
Gate it on earned trust (opt‑in)
In Repo settings → Auto‑merge, enable "Only when trust is earned" and AM auto‑merges only once this repo's trust score reaches auto‑merge ready — a demonstrated track record over a real verify gate. Below that, the run still opens a reviewable PR (you merge) instead of merging automatically.
Because trust is recomputed every run, this ramps and demotes on its own: auto‑merge resumes as the repo proves out and pauses if reliability regresses — no manual flipping. It's the literal form of "autonomy earned by demonstrated reliability", and the safest way to adopt auto‑merge.
Does the next run see the merge?
Yes. Once a PR auto‑merges, its commits are on your default branch
(main/master), and the next scheduled run starts from a fresh clone of that
branch — so it builds on the merged work, not a stale copy. The panel pins no
checkout and no commit SHA: each run sends only the repo URL, and the worker
re‑clones the current default‑branch HEAD every time. There's no "stale workdir"
to reset. (The one exception is recovering an open PR,
where a run is told to continue an unmerged PR branch instead.)
Recommended adoption
Start with auto‑merge off even on Max, watch a handful of runs land merge‑ready PRs you approve, then enable auto‑merge with trust‑gating on so it goes hands‑off only once the repo has earned it. Pair it with explore mode for a fully hands‑off improvement loop.