GitHub Won't Accept Your Copilot PR Approval, but Your Laptop Will: The Separation-of-Duties Gap in AI Coding

You assign an issue to the Copilot cloud agent on GitHub, and minutes later you get a PR. You read the diff, think it looks fine, and click Approve. But the merge rules ignore that click: GitHub's documentation states plainly that "if your repository requires PR approvals, your approval of a Copilot PR will not count toward the required number." Someone else must approve before it can merge.

CI is waiting too. By default, when Copilot pushes changes to a PR, GitHub Actions workflows do not run automatically—someone must first click "Approve and run workflows."

Now do the same thing on your laptop: you prompt Claude Code or Codex, read the diff, and run git merge. The person who requested the change, the person who reviewed it, and the person who shipped it are all the same. Nothing turns the count into two.

My position: GitHub's rule is right, and it shouldn't stop at github.com. Separation of duties must follow agent work onto your laptop.

How GitHub Handles Agent Pull Requests

GitHub's cloud agent risk and mitigation page reads like a checklist a careful team would draw up:

• Only users with write access to the repository can trigger the agent; comments from users without write access are never passed to the agent.
• For new work, the agent gets a fresh copilot/ branch and can only push to that branch.
• It "cannot mark its pull request as 'Ready for review,' nor can it approve or merge pull requests."
• It is "subject to any branch protections and required checks on the working repository."
• Workflows wait for "a user with write permissions to click the Approve and run workflows button."
• The page's list of mitigations also includes: GitHub "blocks users who requested the Copilot cloud agent to create a pull request from approving that PR."

The last item is the most interesting choice. Copilot is the author of the submission, and the developer who requested the change is marked as co-author. GitHub could have treated you as an outside reviewer of bot work, but it didn't. It put you on the author's side.

This aligns with GitHub's existing rules for humans. On the required reviews page: "Pull request authors cannot approve their own pull requests." The same page notes that if "you assigned Copilot to the issue," you cannot approve the PR Copilot opened. The person who wrote the prompt is treated as the author.

The workflow half has an opt-out. As of the changelog update on March 13, 2026, repository administrators can turn off "Require approval for workflow runs" for the agent. The settings page warns alongside it that doing so "may allow unreviewed code written by Copilot" to gain write access to the repository or reach Actions secrets. Approval remains on by default.

Branch Protection Rules are a set of merge preconditions that a GitHub repository administrator sets for specific branches; common items include: requiring at least one approval, requiring status checks to pass, prohibiting force pushes, requiring linear history, and so on. Rules are configured via repository Settings → Branches and can take effect in bulk for branch name patterns. Their core function is to turn "merging" from a personal action into a policy-constrained process. The "required reviews" and "required status checks" mentioned in the article fall into this category. Note that by default the rules do not apply to repository administrators unless "Do not allow bypassing the above settings" is explicitly enabled—this is also the root of the "administrator gap" discussed later.

Required Status Checks refer to the mechanism in branch protection that requires specific CI jobs to finish in a successful state before merging. Checks are reported by GitHub Actions or other CI systems and are bound to the latest commit SHA on the branch; a new push invalidates old checks. Making a test job a required check means "passing tests" goes from a suggestion to a hard gate for merging—even if a reviewer approves, the merge cannot proceed if the check hasn't passed. This provides an automatically enforceable second-party constraint for scenarios without a second human reviewer.

On Your Laptop, You Are Three People at Once

NIST's glossary defines separation of duties as: "no single user should be given sufficient privileges to abuse the system alone." NIST's example is the two-person rule. GitHub applies it to agent pull requests, and a local agent session has no equivalent.

Run a coding agent in your terminal, and its commits enter under your git identity. It may even be GitHub's agent: Copilot CLI "can perform tasks on your behalf, such as executing or modifying files, or running shell commands." Same vendor, same kind of work. Once those commits belong to you and you merge them locally, no rule on GitHub knows an agent wrote them.

To be fair to the laptop, though: if main is protected and requires review, a direct push is rejected—with required reviews enabled, "collaborators can only push changes to a protected branch through a pull request." A teammate still has to approve. The gap shows up in three places:

• Local merges. Merging git merge agent/fix-login into the branch you deploy, or into a branch later submitted as one big PR, rushes the agent's portion through.
• Administrators. "By default, the restrictions of branch protection rules do not apply to people with admin permissions on the repository." In small teams, the person running the agent is often the admin.
• Reviews that feel like reviews. You did read the agent's diff carefully. But under GitHub's rules for Copilot PRs, your reading doesn't count, because you requested the work. The laptop counts it as the only review.

The workflow gate has no laptop counterpart either. On GitHub, by default, agent changes to .github/workflows/ don't run until someone approves, and the documentation advises you to be "especially wary" of such changes. Locally, test commands edited by the agent run in your shell the next time you or the agent invoke them, under whatever permission mode you've chosen.

git identity (user.name / user.email) consists of the author and committer fields in commit metadata, read by default from local git configuration, and does not verify the real operator. Coding agents running locally usually inherit your configuration, so the commits they produce look to GitHub no different from your manual commits—they carry no "generated by agent" marker and don't trigger the special rules for the Copilot cloud agent. This is precisely the technical reason a local session can bypass GitHub's separation of duties: all platform-side agent constraints depend on "being able to recognize this as agent behavior," while local commits are indistinguishable from human commits at the identity level. If you want to trace them after the fact, you can use Co-authored-by trailers or commit signing, but these are voluntary conventions, not mandatory gates.

Make the Second Key Follow the Agent

Rule: agent branches land as pull requests, approved by a teammate, with checks you wrote deciding when the work is done.

Use the GitHub CLI to push the branch and open a PR instead of merging directly:

git push -u origin agent/fix-login
gh pr create --base main --fill

--fill takes the title and body from the commits, so the agent's commit messages become the PR description reviewers read first. If they're vague, edit them.

Then close the gaps on the GitHub side with branch protection rules for main:

• Require pull request reviews, at least one approval.
• Enable "Do not allow bypassing the above settings" to remove the administrator exemption.
• Enable "Require approval of the most recent reviewable push." According to the protected branches documentation, "the most recent reviewable push must be approved by someone other than the person who pushed it."
• Require status checks to pass, and make your test job one of them.

And assign owners for high-risk paths. Code owners "are automatically requested for review when someone opens a pull request that modifies code that they own," and "Require review from Code Owners" makes their approval mandatory:

**CODEOWNERS** is a text file in the repository root, `docs/`, or `.github/` that maps code areas to users or teams by path pattern. When a PR modifies a matching path, the corresponding owner is automatically requested for review; combined with "Require review from Code Owners" in branch protection, their approval becomes a necessary condition for merging. Matching rules follow "the last matching pattern takes precedence," so wildcard lines should come first and specific paths later, otherwise the wildcard line will override the fine-grained rules after it. CODEOWNERS does not force the owner themselves to push—only to review—so it is suitable for setting an extra human gate on high-risk directories (such as workflows, deployment scripts, and authentication modules).
# .github/CODEOWNERS
*                   @acme/backend
.github/workflows/  @acme/platform

Order matters: "the last matching pattern has the highest priority," so put the workflows line after the catch-all line.

Wiring This Up in Hermes

I built Hermes IDE, so weigh this section with that in mind. Hermes runs each agent (Claude Code, Codex, Copilot CLI, etc.) in its own terminal, its own hermes/<task> branch, and its own worktree, per its README.

Review Desk (⌘G, or Ctrl+Shift+G on Windows and Linux) is where you read agent work by round or by file. That reading is useful, but by GitHub's logic it does not make you the second person.

So the key part is Land. According to the README, Land "commits, opens a pull request, or merges locally in one step, merging into the branch where the task started, and can be undone." Choose pull request, and approval happens on GitHub, with your branch rules applying.

The same README line adds: "Your own checks can decide when a task is done." Run the same commands there as your required status checks in CI, so that local "done" and GitHub's "mergeable" agree.

What Hermes doesn't do: it cannot force anyone to approve anything. Required reviews are GitHub's job, and if you choose local merge, Hermes will still merge locally. Hermes is free, source-available under BSL 1.1, supports macOS, Windows, and Linux, and is not affiliated with Nous Research, Anthropic, OpenAI, or GitHub.

The Cost of This Approach

A solo developer has no second person. So the checks you write are the second party: they don't know who requested the change, and they don't care how confident the agent sounds. Skip required reviews, make the checks required status checks, and turn off administrator bypass on your own repository so that even you have to go through them.

On a team, the cost is delay: every agent branch now waits for a teammate, just as Copilot cloud agent PRs already do on github.com.

Do you allow agent branches to merge locally, or does everything an agent writes go through a PR approved by someone else?

One-line Summary

GitHub rejects Copilot PR approvals, yet local agent merges lack separation of duties—extend the second key to the laptop.

Paragraph Summary

The article points out that GitHub imposes clear constraints on PRs from the Copilot cloud agent: users who request agent work are treated as co-authors, their approval does not count toward the required number of reviews, and workflows by default also require human approval to run. But once the same work moves to a local laptop, coding agent commits enter under the user's git identity, and three scenarios—local merges, administrator bypass, and "self-review"—break separation of duties, while workflow approval has no local counterpart. The author argues for extending GitHub's rules locally: agent branches should land via PR, be approved by a teammate, and use required status checks and CODEOWNERS as hard gates; solo developers can use automated checks as the second party. The article ends by describing how Hermes IDE's Land feature fits this workflow and acknowledges that it cannot enforce reviews.