GitHub 不計入你對 Copilot 撰寫 PR 的批准，本機合併卻把你當作審核者

• Book: Ship It — the pragmatic startup tech stack
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

You assign an issue to the Copilot cloud agent. A few minutes later there is a pull request. You read the diff, it looks right, and you click Approve. For the merge rule, that click is ignored: "If your repository requires pull request approvals, your approval of a Copilot pull request won't count toward the required number," say GitHub's docs. Another reviewer has to approve before it can merge.

The CI is waiting too. "By default, GitHub Actions workflows will not run automatically when Copilot pushes changes to a pull request." Somebody clicks Approve and run workflows first.

Now do the same job on your laptop. You prompt Claude Code or Codex in a terminal, read the diff and run git merge. The person who asked for the change is the person who reviewed it and the person who shipped it. Nothing anywhere counted to two.

My take: GitHub got this rule right, and it should not stop at github.com. Separation of duties has to follow agent work onto your laptop.

What GitHub does with an agent's pull request

GitHub's risks and mitigations page for the cloud agent reads like a list of things a careful team would ask for:

• Only users with write access to the repository can trigger the agent, and comments from users without write access are never passed to it.
• For new work the agent gets a fresh copilot/ branch, and it can only push to that branch.
• It "cannot mark its pull requests as 'Ready for review' and cannot approve or merge a pull request."
• It is "subject to any branch protections and required checks for the working repository."
• Workflows wait until "a user with write access to the repository clicks the Approve and run workflows button."
• The page lists, as a mitigation, that GitHub "prevents the user who asked Copilot cloud agent to create a pull request from approving it."

That last one is the interesting choice. Copilot is the author of the commits, and the developer who asked for the change is marked as co-author. GitHub could have treated you as an outside reviewer of a bot's work. It didn't. It put you on the author's side of the table.

That matches the rule GitHub already had for humans. On the required reviews page: "Pull request authors cannot approve their own pull requests." The same page says you can't approve a pull request raised by Copilot "if it was you who assigned Copilot" to the issue. The person who wrote the prompt counts as an author.

There is an opt-out for the workflow half. Since a March 13, 2026 changelog entry, a repository administrator can turn off Require approval for workflow runs for the agent. The settings page puts a warning next to it: doing so "may allow unreviewed code written by Copilot" to gain write access to your repository or reach your Actions secrets. Approval stays on by default.

GitHub wants a second key on an agent's pull request. The prompt writer's key alone doesn't open it.

On your laptop, you are all three people

NIST's glossary puts separation of duty in one line: "no user should be given enough privileges to misuse the system on their own." NIST gives the two-person rule as an example. GitHub applied it to agent pull requests. A local agent session has no equivalent.

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

Be fair to the laptop, though. If main is protected and requires reviews, a direct push gets refused: with required reviews on, "collaborators can only push changes to a protected branch via a pull request," per GitHub's protected branches docs. A teammate still has to approve. The gap opens in three places:

• The local merge. git merge agent/fix-login into a branch you deploy from, or into a branch that later goes up in one big PR where the agent's part gets skimmed.
• The admin. "By default, the restrictions of a branch protection rule don't apply to people with admin permissions to the repository," the same page says. On small teams, the person running agents is often the admin.
• The review that feels like a review. You did read the agent's diff, carefully. By GitHub's own rule for Copilot pull requests, your reading wouldn't count, because you asked for the work. Your laptop counts it as the only review there will be.

The workflow gate has no laptop twin either. On GitHub, by default, an agent's change to .github/workflows/ doesn't run until someone approves it, and the docs tell you to be "especially alert" to those changes. Locally, a test command the agent edited runs in your shell the next time you or the agent calls it, within whatever permission mode you picked.

Make the second key follow the agent

The rule: agent branches land as pull requests a teammate approves, and a check you wrote says when the work is done.

Push the branch and open the PR with the GitHub CLI instead of merging it:

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 your reviewer reads first. Edit them if they are vague.

Then close the gaps on the GitHub side, in the branch protection rule for main:

• Require pull request reviews, with at least one approval.
• Turn on Do not allow bypassing the above settings, which removes the admin exemption.
• Turn on Require approval of the most recent reviewable push. Per the protected branches docs, "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 give the risky paths an owner. 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:

# .github/CODEOWNERS
*                   @acme/backend
.github/workflows/  @acme/platform

Order matters: "the last matching pattern takes the most precedence," so the workflows line goes after the catch-all.

The agent reports done. A check you wrote decides it.

Wiring this up in Hermes

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

The Review Desk (⌘G, Ctrl+Shift+G on Windows and Linux) is where you read an agent's work by turn or by file. That read is useful, and by GitHub's logic it doesn't make you a second person.

The Review Desk (⌘G) by turn for a Claude Code task in orders-api: two turns, turn 1's diff of src/db.ts, the changed files and a commit message drafted from the turns.

So the part that matters is Land. Per the README, Land "commits, opens a pull request or merges locally in one step, into the branch the task started from, and can be undone." Pick the pull request, and the approval happens on GitHub where your branch rules apply.

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

What Hermes doesn't do: it can't make anyone approve anything. Required reviews are GitHub's job, and Hermes will still merge locally if you pick that. Hermes is free, source-available under BSL 1.1, on macOS, Windows and Linux, and not affiliated with Nous Research, Anthropic, OpenAI or GitHub. Download it or read the code on GitHub.

Where this take costs you

A solo developer has no second person. Then the check you wrote is the second party: it doesn't know who asked for the change and doesn't care how confident the agent sounded. Skip the required review, make the check a required status check, and turn off the admin bypass on your own repo, so even you go through it.

On a team, the cost is latency: every agent branch now waits for a teammate, the same way a Copilot cloud agent PR already does on github.com.

Do you let agent branches merge locally, or does everything an agent writes go through a PR someone else approves? Tell me in the comments.

If this was useful

Branch rules, required checks and who gets to merge are the kind of setup a small team gets right once and then forgets about. Ship It covers that stretch between localhost and production for small teams: hosting, deploys, auth, payments, CI/CD and monitoring. If this post made you open your branch protection settings, the book walks through the rest of that stack.