Pull requests

Plexus opens a GitHub or Bitbucket pull request straight from a session's branch and keeps its status — open, merged, or closed, plus CI — in view, without leaving the app.

Before you start

PR features need a connected git provider. Open Settings → Git ▸ Providers and click Connect for GitHub or Bitbucket — a one-click sign-in, no CLI required. Plexus stores the resulting token in your OS keychain and talks to the provider directly from your machine; the token is never sent to us. See Connections.

A session also has to be on a named feature branch with at least one commit beyond its base. Sessions on the project's main branch can't open a PR.

Create a pull request

1. On the session row, open the ⋯ menu and choose Create PR.
2. Fill in the title, an optional description, and an optional base branch.
3. Click Create.

Plexus pushes the branch to origin, opens the PR on your provider (GitHub or Bitbucket), and the session's branch icon turns green.

If the session was started from a GitHub issue, the description starts out as Closes #123 — one line per linked issue — so merging the pull request closes the issue on GitHub. The line is ordinary text: edit it, move it, or delete it. It survives an AI-drafted description too — the draft is written above it, and a draft that already says Fixes #123 is not followed by a second line for the same issue.

A dirty worktree

If the worktree has uncommitted changes when you create a PR, Plexus doesn't fail — it shows a commit-then-PR dialog. Enter a commit message (or accept the default WIP on <branch>), and Plexus commits, pushes, and opens the PR in one flow.

Auto-generate the title and description

Turn on Write pull request descriptions with AI (Settings → Git, default off) to have the agent draft the PR title and description from the diff when the dialog opens. It spends an AI turn, and you can still edit the draft before submitting.

Stacked pull requests

A session stacked on another session opens its pull request against its parent's branch, so the pull request shows only its own changes. When the parent has no pull request yet, the dialog offers Open pull requests for the whole stack, which opens one per session from the bottom up. From then on the stack looks after itself: when a session underneath gets new commits, Plexus syncs the branches above it and pushes them again, and on GitHub it groups the stack's pull requests into one GitHub stack, so reviewers see the stack on GitHub and GitHub can merge it in one go (turn that off with Create stacks on GitHub). See Pull requests in a stack, and Merging for merging a stack from Plexus.

Track PR status

Once a PR exists, the branch icon next to the session reflects its state at a glance:

Hover the icon for details, including the aggregate CI status (pending, passing, or failing) from the provider's checks (GitHub check runs / Bitbucket pipelines). Click a green or purple icon to open the PR in your browser.

The session's state chip says where the pull request stands in words — Checks while they run, Needs you: checks failed, Review, Ready, Merged — on its row, on the dashboard and in the context bar, where a pill with the pull request's number (#129) opens its panel with a Merge button (with a plan). See States.

Status is polled automatically — when you focus the window, on a periodic refresh, and when the agent finishes a turn. You can also refresh on demand with the Refresh PR status button in the session header. CI status updates alongside the PR, so a very fast pipeline may briefly show "pending" until the next refresh. For how the branch and activity indicators relate, see Session status.

Plexus finds a session's PR by its branch name, and ignores a PR on that branch that was closed or merged before the session was created, so a session that reuses the name of an old, merged branch starts with no PR instead of the old one. An open PR on the branch always counts. A session that was already showing an old PR is checked again once after you update and cleared if the PR isn't its own; the Refresh PR status button in the session header does the same at any time. The session keeps the name it was given from the old PR.

Review comments

Once the PR exists, its review conversation lives on GitHub or Bitbucket — and the Review tab shows it. A toggle in the Review header reveals the PR's threads under the diff lines they're about, with everything that can't be placed on the current diff (PR-level comments, review verdicts, outdated threads) collected in a section of its own — one that starts collapsed, with a count and any review verdict in its header. From there you can reply, resolve a thread when the provider allows it, post a new comment on a line, and hand one thread — or all of them — to the agent as a prompt.

Your own inline notes can travel the other way while the PR is open: publish one — or the session's unresolved set in one go — and it's posted as an inline comment on the same line under your provider account, replacing the local note.

Unlike the status above, the conversation is not polled. Plexus fetches it when you open the Review tab, when the window regains focus, and when you click Refresh — never in the background. See Pull request comments for the full flow and its limits.

After the PR is created

Two optional behaviors keep sessions tidy as PRs progress:

• Auto-rename from PR title — Rename sessions to match their pull request (Settings → Git, default on) keeps the session name in sync with the PR title. The underlying git branch keeps its original name.
• Auto-teardown on merge — Clean up a session when its pull request is merged (Settings → Git, default off) tears the session down when Plexus detects its PR has merged. It honors your When you remove a session setting, so it archives or deletes per your configuration — but it never asks. Nobody is at the keyboard when a background check notices the merge, and switching this on is the confirmation, so Ask each time deletes here too. Whether the branch goes with it is inherited from the Also delete the local branch switch you last used when removing a session by hand, and only ever applies to a plexus/… branch Plexus cut — see Archive vs. remove. Plexus only does this for a pull request it saw while it was open, and a message tells you afterwards what was removed. Two things change for a session other sessions are stacked on: the sessions above it are moved down a level and their pull requests retargeted first, and the branch is kept whenever another session is still based on it — the message names that session.

Configure all of these in Settings.