Pull requests

When a pull request will not open, or a merge will not go through, the cause is usually access, the diff, or which of the two merge paths you are on. A run opens a real pull request on your repository, authored as you, and there are two distinct ways work reaches your main branch. This page covers why a PR fails to create, why one sometimes shows a bot as its author, why a merge is refused, and why a merged PR does not on its own complete a plan. If the trouble is reaching the repository at all, that is on connections and access.

A pull request could not be created

What you see. A run's create-a-pull-request step finishes without opening one, and names the reason rather than leaving you guessing.

Why it happens. A pull request needs three things, and a failure is one of them missing. It needs changes to open from, so a step that made no edits has nothing to put in a PR. It needs access to the repository, so a repository that is not connected, or a connection without permission to push and open a PR, stops it. And it needs a base branch to open against, which the platform resolves from the repository or project default; if neither is set and the run has no branch lineage, it cannot pick one. A fourth case is not really a failure: when a pull request is already open for the branch, the platform links the existing one rather than opening a second.

How to fix it. Read the reason the step gave, and the fix follows from it.

• No changes to open from. The work did not produce edits. Check the run's transcript to see what the step did, and run it again once there is something to commit.
• The repository is not connected, or the connection cannot push. Connect or reconnect the repository, and make sure the connection has permission to push and open pull requests. The specific authorization causes and fixes are on connections and access.
• No base branch. Set a default branch on the repository or the project so a PR has something to open against.
• A pull request already exists. No fix needed; the platform links the open one. Find it from the plan's pull-request panel.

Your pull request shows a bot as its author

What you see. A pull request opened, but its author on the repository is an app or bot identity rather than you.

Why it happens. A run opens a pull request under your own GitHub identity when you have connected GitHub, so the commit and the PR carry your name. When you have not connected GitHub, or the connection cannot be used, the platform falls back to opening the PR under its app installation so the work still ships; the visible effect is that the PR is authored by the app rather than by you. This is a fallback, not a failure: the PR is real and complete.

How to fix it. Connect your GitHub account, then open the pull request again so it carries your identity. Connecting GitHub is on connect a repository; once your account is connected, new pull requests are authored as you.

If your GitHub account is already connected and a pull request still opened under the app, the connection could not be used at the moment it was needed: the account's authorization may have lapsed, or, if your organization enforces single sign-on, the GitHub App's authorization may not be approved for the org yet. Reconnect GitHub, and where single sign-on is enforced, approve the App for the organization, then open the pull request again. The authorization causes and fixes are on connections and access.

A merge would not go through

What you see. A merge is refused or the control to merge is not available to you.

Why it happens. There are two ways work reaches your main branch, and they are governed differently. The everyday path is to open a pull request and merge it on your repository, the same review and merge your team already uses. The platform also offers a direct merge to main that commits the selected work straight to your main branch without a pull request, which is deliberately the more guarded of the two: it carries the pr.merge scope, which only an Owner or Admin holds, because it skips the review a pull request gives you. So a refused merge is usually either that you do not hold pr.merge and are reaching for the direct path, or, for either path, that there were no changes selected or the base branch moved underneath the merge.

How to fix it. Read which of the two paths you are on, and the fix follows from it.

• The merge-to-main control is unavailable to you. You are reaching for the direct path and do not hold pr.merge. An Owner or Admin either performs the merge or grants you a role that includes the scope; it is destructive by design, so it is held narrowly. For most work the better path is to open a pull request and merge it on the repository, which keeps the review in place.
• No changes were selected. The merge had nothing to commit. Confirm the work you mean to ship is selected, then merge again.
• The base branch moved, or there is a conflict. Main changed underneath the merge. Retry once main is stable; if it persists, bring the work current against main first, then merge.

If you are on the pull-request path and the repository will not let the PR merge, that is your repository's own rule, a required check or a branch protection, not the platform. Clear the check or get the review the repository requires, then merge it there.

My pull request merged but the plan still shows in progress

What you see. A plan's pull-request badge reads merged, but the plan itself is still in its earlier status, or the badge looks out of date compared to the repository.

Why it happens. The platform tracks one pull request per plan and follows its status, draft, open, merged, or closed, from the repository: when you merge on GitHub, a signal comes back and the badge updates to merged. That status is about the pull request, not the plan. A merged PR does not move the plan to complete on its own, because finishing the work is a decision you make in the plan's workflow, not something a merge should silently do for you. A badge that looks behind the repository is usually a signal that has not arrived yet.

How to fix it. If the work is done, move the plan to its completed status in its workflow; the merged badge and the plan status are meant to be separate, so this is a deliberate step, not a bug. If the badge itself is behind the repository, it catches up when the status signal arrives; a merge on the repository is reflected by the platform, not driven by it, so the repository is the source of truth and the badge follows it.

The branch behind a pull request

What you see. A run opened a pull request from a branch on your repository, and you are unsure whether that branch is yours to reuse or clean up after the PR resolves.

Why it happens. A run pushes its work to a branch on your repository and opens the pull request from it, so the branch lives on your repository, not inside the sandbox. When the pull request merges, the platform cleans that branch up for you as part of the merge, so you are not left with a trail of merged branches. The cleanup is best effort: if it cannot complete, the branch is left in place rather than the merge being held up.

How to fix it. There is usually nothing to do; a merged branch is removed for you. If one does linger because the cleanup could not finish, delete it on the repository the way you would any branch. You do not reuse a branch to ship more work on the same plan: a new run opens a new pull request on a new branch, and the plan tracks that one instead.

Shipping one plan's work, start to finish

A run on the export endpoint plan finishes, and its create-a-pull-request step did not open one. The step is not silent about it: it reads that there were no changes to open a pull request from. The author reads the transcript and sees the implement step made no edits, because the change was already on the branch from an earlier run.

So the pull request is the one already open. The plan's pull-request panel links it, authored under her own GitHub identity because her account is connected. She gets it reviewed the way her team reviews any pull request, and merges it on the repository. The badge on the plan turns to merged when the signal comes back from GitHub.

The plan is still in its earlier status, and that is on purpose: merging the code and closing out the plan are two decisions. She moves the plan to its completed status in the workflow herself. The direct merge to main was never in play here; the pull-request path kept the review her team relies on.

One read of the step, one existing pull request, one review, one merge. The work landed the way her own work does, and the record shows who decided what.

Still stuck on a pull request

If the create step still will not open a pull request after you addressed the reason it named, read the reason once more, since a second cause can surface once the first is cleared, and confirm the connection can push and open a pull request on connections and access. For a merge that will not go through, check whether you are reaching for the direct merge to main without holding pr.merge, in which case an Owner or Admin is the fix, not a retry. If it persists, quote the run's identifier and the create-a-pull-request step, or the plan and its pull-request panel for a merge, so anyone looking with you lands on the same place. Your account contact can pick it up from the run identifier and the step that stopped.

Why a PR carries your name and a merge is held narrowly

The pull-request model here is built so that agent work lands the way your own work does. A pull request opens under your identity, against your base branch, for the same review your team already runs, which is what lets an agent contribute without becoming a separate, unaccountable author in your history. The direct merge to main exists for the cases that genuinely call for it, and it is held to Owners and Admins precisely because it skips that review; making it easy would undercut the reason the pull-request path exists. And a merged pull request stays distinct from a finished plan so that shipping code and closing out the work remain two decisions, each with its own record.

For a current user, the path is the same as your own pull requests: open one, get it reviewed, merge it on the repository. Connect GitHub so it carries your name, and read the create step's reason if it does not open.

For an administrator, the pr.merge scope is the lever to know. It governs the direct merge to main, it is destructive by design, and it is held to Owners and Admins; grant it deliberately, and steer everyday work to the pull-request path.

For a prospect, the takeaway is that an agent ships through your existing review, not around it. Its pull requests carry a real human identity, they merge the way your team's do, and the one path that skips review is held to your most trusted roles.