What is a pull request?
What a pull request is: a request to merge one branch into another. Its parts, how it merges, and what changes when a coding agent opens it.
What is a pull request? It is a request to merge the commits on one branch into another. It puts the diff, the description, the discussion, the automated checks and the reviews in one place until someone, or a rule, merges it. GitLab calls the same thing a merge request.
Today the one opening it is often a coding agent. CodePanel reviews its own repository, where Claude Code writes the pull requests and answers the reviews. As of 17 October 2026, 150 pull requests merged from PR 61 to PR 213, and 147 were opened from the owner's account by Claude Code: each carries a Co-Authored-By: Claude trailer and the "Generated with Claude Code" line. The other three are two benchmark-results pull requests from GitHub Actions and one from Dependabot. None of the 150 has a GitHub review of any kind. Merging main takes two required checks, check and the CodePanel status, and the repository's maintainer docs say the ruleset requires no approving review, so nothing waited on one. Auto-merge became the rule partway through that range and was armed at merge on 98 of the 150; the repository's own instructions tell the agent to arm it in the same turn it opens the pull request.
The trailer is attribution, not proof: the agent writes it and GitHub does not check it. CodePanel's own review is a comment on the pull request, not a GitHub review.
What a pull request is made of
GitHub's documentation describes a pull request as a proposal to merge code changes, organized into tabs:
| Part | What it is |
|---|---|
| Head and base branch | The head branch holds the changes. The base branch, usually main, is where they would land |
| Commits | How the head branch changed over time |
| Diff | The Files changed tab: what reviewers read to understand the proposal |
| Description | Text the author writes to say what changed and why |
| Checks | Automated tests, builds and other validations |
| Reviews | A reviewer's decision: Comment, Approve or Request changes (review decisions) |
| Conversation | The timeline of the description, comments and reviews, including comments on specific lines |
| Merge | A merge commit keeps every commit, squash combines them into one, rebase adds each onto the base without a merge commit (merge methods) |
How to read the diff and write the review comment is a separate subject: see PR review.
The name comes from git's request-pull
Git has shipped a request-pull command since 2005. It generates a summary of pending changes, a request asking an upstream project to pull them. GitHub announced its pull request feature in February 2008, in a post by Chris Wanstrath, as a way to tell people who forked a repository that they need to pull, or to ask its owner to pull.
How a pull request gets merged
Anyone with write access can press merge on an open pull request, unless the repository's rules say otherwise. Those rules are where a team decides what "ready" means:
- Protected branches and rulesets. A ruleset is a named list of rules for a repository. It works alongside branch protection, and all applicable rules are enforced (rulesets).
- Required status checks. A required check must pass before changes reach the protected branch (protected branches).
- Required reviews. The branch can demand a set number of approving reviews before the merge.
- Auto-merge. The pull request merges on its own "after all required reviews and status checks pass" (auto-merge). Nobody has to be present when the last check turns green.
- Drafts. A draft cannot be merged, and code owners are not automatically asked to review it, until it is marked ready.
CodePanel's contribution is one of those required checks. Its CodePanel status fails while any finding at or above the repository's gate level is unanswered, and passes once each is answered: fixed, deferred or dismissed, or disputed and then withdrawn or revised by the orchestrator. A dispute it upholds leaves the finding blocking. That is the merge gate; the status rules and how to require it are in Merge gate. A round that fails is judged on the findings the pull request already has, so a failed review does not hold the merge on its own.
Pull requests opened by coding agents
Anthropic documents Claude Code creating pull requests and pushing commits from GitHub issues and comments, and OpenAI documents Codex opening a pull request from a cloud task. Both pages have the agent act when a person asks it to. As of 17 October 2026, the pages cited do not describe the agent waiting for, or answering, the review of its own pull request. On CodePanel's repository, Claude Code runs the whole loop from its own session:
- Branch from the default branch and commit the change.
- Push, and open the pull request with
gh pr create, ready for review rather than as a draft. - Arm auto-merge on the same turn.
- Wait for the checks and for the review of the commit it pushed.
- Fix each finding, or rebut it with evidence, and rate every one.
- Push again, and go back to step 4 until the merge happens.
What changes when the author is an agent
The agent writes the change and its description, so a trade-off it never weighed is missing from both. A reviewer reading only the diff can catch it. A case on CodePanel's repository is PR 137, which moved all four default reviewer roles onto one model provider. Neither the change nor the docs said what that costs. A reviewer raised F5 (a suggestion, medium confidence):
All four default roles now share one provider, so an outage or rate limit on that provider disables the whole starter panel. The old spread limited that exposure, and the docs do not mention the tradeoff.
Claude Code rated it up fixed, and rated the whole review up with this note: "F5 caught a real tradeoff (single-provider outage) the change had not stated."
Bot-opened pull requests may get no review. CodePanel skips drafts until they are marked ready, and skips pull requests opened by bot accounts such as Dependabot until someone comments /review. An agent that pushes under a person's account is reviewed like that person. The rules are in Triggering reviews.
Agents' pull requests merge somewhat less often in one preprint. The figures and their limits are in Reviewing AI-generated code.
A person sets the checks an agent's pull request merges by
A person sets the ruleset, enters the provider keys in the browser (so they never pass through an agent's context) and chooses the token's scopes. The agent can open a pull request, answer every finding and arm auto-merge. It merges only when the checks the person chose have passed. Scoped to read and reviews:write (the CLI's default), its CodePanel token cannot change the repository's settings, the gate level included: that takes repos:write.
For how the agent's side of that loop runs, and how its rebuttals are judged, see Agentic code review. The wider picture is in AI code review.
The commands an agent runs
These are the commands for the loop above, using the GitHub CLI and the CodePanel CLI:
git push -u origin HEAD
# open it ready for review (use --title and --body for your own text)
gh pr create --fill
n=$(gh pr view --json number --jq .number)
# let GitHub merge it when the required checks pass
gh pr merge "$n" --auto --squash
# wait for the review of the commit just pushed; exit 0 means the gate passes,
# exit 4 means findings still block, exit 3 means it timed out: run it again
codepanel review owner/name#"$n" --wait --sha "$(git rev-parse HEAD)"
# block until GitHub merges it; after any fix and push, wait for the review again first
gh pr checks "$n" --watch --required
To set this loop up on your repository, give your coding agent the prompt in the Quickstart.