TL;DR
An agent that runs gh with your login can approve and merge a pull request in one command, faster than you can interrupt it. Let the agent edit, commit and open pull requests, and keep merging and deploying with people. Give it its own credential with no bypass rights, require approval from someone other than the last pusher, and gate production deployments the same way. The boundary then holds even when the agent's instructions fail.
Approve and merge in one command
gh pr review 448 --approve --body "..." && gh pr merge 448 --merge is one line of shell. A Claude Code user quoted it in a GitHub issue in September 2026. They had asked the agent to "review and merge" a pull request, then interrupted to say it should only leave comments. The interrupt arrived, but approval and merge were one chained call, so the pull request was already merged. Later a vague "now update it" sent the agent toward promoting the development branch to main, which deploys to production, until the user stopped it. The issue, still open, asks for irreversible actions to run as separate calls.
In March 2026 a Cursor user asked on the Cursor forum how to make their bots merge their own pull requests, tired of waiting for review on each one. A Cursor staff reply said Automations had no merge tool, then listed workarounds: a second automation that approves each new pull request so GitHub's auto-merge fires, a GitHub MCP merge tool, or pushing straight to main where branch protection allows it.
One person wanted the agent to stop before merging; the other wanted it never to stop. An engineering lead has to decide which actions an agent may take, and what enforces that.
Five actions, five separate grants
The five look like one workflow but carry different risk.
Who holds each action
| Action | Sensible default for the agent | What enforces it | How it is undone |
|---|---|---|---|
| Edit files | Yes, in its own working copy or sandbox | Client permissions and sandbox | Discard the change |
| Commit | Yes, on its own branch | Local only until pushed | Reset the branch |
| Push and open a pull request | Yes, to its own branch, ideally as a draft | A host credential that cannot write to protected branches | Close the pull request |
| Merge into a protected branch | No: a person who did not write the change approves it first | Branch protection or rulesets on the code host | A revert, after others may have built on it |
| Deploy to production | No: a named approver for each deployment | Environment protection rules | A rollback, after users have seen it |
The line falls between the third and fourth rows, where an action stops being private: before it, anything the agent does can be thrown away; a merge changes what every teammate pulls.
GitHub draws the same line for its own agent. Copilot cloud agent pushes only to its own copilot/ branch or the pull request it was asked to work on, cannot approve or merge its pull request, and the person who asked for the work cannot approve it either. Workflows on its pull requests wait for approval by someone with write access (Copilot risks and mitigations).
When a person has to make the call
When a person must approve
Treat the person who prompted the agent as an author of the change. Require approval from someone who neither wrote nor prompted it when any of these holds:
- The target branch deploys, directly or with the next release.
- The change touches authentication, permissions, payments, personal data, data migrations or infrastructure.
- The change edits CI workflows, branch rules, code owner files, dependency manifests or the tests that guard the code it changes.
- A required check is missing, was skipped or was rerun until it passed.
- The agent proposed the step itself, or acted on an ambiguous instruction.
- Nobody can say how the change would be rolled back.
Outside those conditions a merge can be delegated to a rule: auto-merge on a pull request a person has already approved, or a narrow lane such as documentation-only changes with every required check green. That is still a human decision: the lead writes the rule and owns what qualifies. What should not exist is a path where the agent decides its own change qualifies.
Instructions ask; the host enforces
A line in CLAUDE.md or AGENTS.md saying never to merge is worth having, but in the GitHub issue the agent did what it was asked, and the chained commands left the user's correction no chance. The article on why a coding agent keeps ignoring the project rules explains why written rules alone rarely hold. In Claude Code, an ask or deny rule such as Bash(gh pr merge *) applies to every part of a chained command, so it would have paused that line for confirmation. But Claude Code's documentation says such a rule matches the command text the agent usually writes and is not a security boundary: a deny rule for git push does not catch git -C . push (Claude Code permissions). A merge can also go through gh api, an MCP tool or a script.
The boundary that holds is the one the code host enforces against the agent's credential. If the agent runs with your login, GitHub cannot tell it from you: whatever you may merge, it may merge.
- Give the agent its own identity, and list every other one it can reach. Use a separate machine account or GitHub App with write access, never admin. Rulesets can name apps that may bypass them (about rulesets); keep the agent off that list. List every token its workflows can read and everyone who can edit workflows, rules or environments; they can all move the boundary.
- Protect every production-bound branch. Require a pull request, at least one approval, and approval of the most recent reviewable push by someone other than the person who pushed it. Dismiss stale approvals, require code owner review for sensitive paths and require the status checks (protected branches). GitHub already refuses an author's approval of their own pull request.
- Remove the administrator exception. By default, branch protection does not bind admins. Apply it to them too. An admin can still edit the rule itself, so the agent should never hold an admin's token.
- Stop workflows approving pull requests. Keep "Allow GitHub Actions to create and approve pull requests" switched off (Actions settings). That setting governs only
GITHUB_TOKEN. A workflow or automation holding another account's token or an app credential can still approve, and that approval counts. - Gate deployments separately. Put production behind an environment with required reviewers, the option that prevents self-review, deployments limited to protected branches and no administrator bypass (deployment environments). Approval releases the environment's secrets to the job and the code it runs, so review that workflow and commit first.
Test the boundary before trusting it
Settings that look right can still leave a path open: an old personal token, a bypass entry, an inherited admin login. Test them in a scratch repository configured like production, with the agent's real credential. This article did not run that test; it is a plan for you.
- Push a commit straight to the protected branch. Expect a rejection.
- Open a pull request as the agent and approve it as the agent. Expect the approval to be refused.
- Merge it unapproved with
gh pr merge, then throughgh api. Expect both to be blocked. - Approve it as a person, then push one more commit as the agent. Expect the approval to stop counting.
- Add a workflow that approves pull requests with
GITHUB_TOKEN. Expect it to fail. - Trigger a production deployment. Expect the job to wait for a reviewer other than the person who triggered it.
Record the date, identity and results, and repeat after any change to roles, tokens or rules. One gap remains: no branch rule knows who prompted the agent, so if the requester's approval should not count, back that team rule with code owners or a second required approval.
What the record should show at merge time
An approval only means something if it covers what was merged. Before a production-bound merge, the pull request should show who approved, and that they neither wrote nor prompted the change; the approved commit, matching the head being merged; required checks passing on that commit; the reason and name behind any exception; and a rollback step someone has read. With stale approvals dismissed and checks required, GitHub records the approver, the approved commit and the check results; the rest someone has to write. The article on which parts of AI-generated code review should stay with a human covers who should give that approval.
Paqad covers the record and leaves the merge to people. Its deliver command asks before opening a pull request, waits for CI, and on green posts the verification receipt on the pull request; in Paqad's own worked example a colleague merges. A Safe to merge verdict attests that the gates Paqad ran passed: evidence for the approver, not permission to merge. Nor does Paqad block merges: its hooks watch file-editing tools, not shell commands such as gh pr merge. Paqad's guardrails page lists what it does not stop, worth reading before deciding where your branch rules must carry the weight.
Frequently Asked Questions
Should an AI coding agent be allowed to merge its own pull request?
Not into a branch that ships, and not on its own judgment. If a team wants agent changes to land without waiting, let a person approve and a rule merge, using auto-merge once the approval and checks are in. On a personal project with no other users the trade-off is yours; these controls are for code other people depend on.
What authority should be separate for editing, committing, opening a pull request, merging and deploying?
Separate the credentials as well as the permissions. The agent's token should never hold deployment secrets. GitHub withholds an environment's secrets from a job until a required reviewer approves it, but an approved job receives them, so the reviewer is deciding what code may hold production secrets, not only whether to deploy.
Which risk or ownership conditions require an independent human decision?
Ownership matters as much as risk. When a change reaches into code another team owns, that team's code owner should approve it, however small it is. The same applies when the agent proposed the step itself, as in the recap that led toward a production promotion.
How do repository permissions and branch protections enforce that decision even if the agent's instructions fail?
The host evaluates its rules when the merge is attempted, whichever client, command or tool made the request. Check what your plan provides: on GitHub Free, Pro and Team, environment required reviewers are available only for public repositories, and anyone on a bypass list or with admin rights left exempt can still merge.
What approval and verification record should exist before a production-bound merge is allowed?
Keep it on the pull request rather than in the chat or the agent's session, because the pull request is what the next engineer or an auditor will open. When a rule rather than a person merged the change, the record should name the rule, so the lead can see which lane it went through.