Auto-merge on green

By default, every change an agent makes waits for you: it opens a Pull Request and you merge it on your terms. Auto-merge on green lets you hand off that last step for repos where you trust the checks — once CI passes, FlareCode merges the PR so you don't have to babysit it.

It is opt-in, off by default, and a Pro feature. We will never merge without you turning this on yourself.

Turn it on

Go to Settings → General → Automation and enable Auto-merge on green. It applies to both task PRs and PRs you publish manually with /pr or /ship. Turn it off any time — flipping it off also halts any merge that's still waiting on checks.

Auto-merge works best with the GitHub App installed on the repo, so the merge uses an installation token rather than your personal session.

What "green" means

FlareCode reads both GitHub's check runs (Actions and custom CI) and the older commit statuses, and merges only when all of them are complete and passing:

• Passing — every check finished as success, neutral, or skipped.
• Pending — at least one check is still running. FlareCode waits and re-checks.
• Failing — any check failed or errored. FlareCode will not merge, and gives up after a while (see below).
• No CI configured — after a short grace period, a PR with no checks is treated as green.

Only low-risk changes merge unattended

Green CI is necessary but not sufficient. For task PRs (including autopilot loops), FlareCode also classifies the diff and auto-merges only low-risk changes:

• Merges on green: documentation, tests, and dependency bumps (package.json + lockfile).
• Always waits for you: anything touching CI/workflow config, Dockerfiles or deploy config, infra-as-code, database migrations or SQL, auth or billing/payment paths — plus any PR that deletes tests, changes more than ~400 lines, or simply isn't clearly in a low-risk category.

A held PR isn't lost: you're notified, the goal's timeline records exactly which files triggered the hold, and you merge it on your terms. This is deliberate blast-radius control for unattended loops — a malicious or misjudged backlog item can at worst produce a PR for your review, never a merge. PRs you publish yourself with /pr or /ship are not risk-tiered (you're the human in the loop); they merge on green as before.

How it merges, and what it respects

• Squash merge, pinned to the exact commit that passed review. If a new commit is pushed, the merge is cancelled and the checks are re-evaluated against the new head.
• Never to your default branch directly. Agents only push flarecode/task-* branches; auto-merge merges the PR, it doesn't bypass the PR.
• Your repo's rules still apply. Auto-merge merges through GitHub, so branch protection, required reviewers, and CODEOWNERS are all still enforced by GitHub — auto-merge can't merge around them. If a required review is missing, the merge simply won't go through.

Timing and notifications

FlareCode connects to GitHub as an OAuth app, so auto-merge is poll-based: it re-checks pending PRs roughly every five minutes rather than reacting instantly. A PR that can't be merged — checks keep failing, a required review never lands — is retried for a few hours and then abandoned with a notification (email and Slack, if connected) so it never silently disappears. A PR you close, or merge yourself, stops being polled.

Related

• Submit a task — the default human-review flow auto-merge sits on top of.
• Plans and billing — auto-merge is included on the Pro plan.
• Notifications — where merge and failure alerts land.
• Security model — why agents never touch your default branch.