Pull requests attached to a session: comments, checks, auto-merge

Pull requests attached to a session

To detach several PRs at once, select their checkboxes in the PRs list (or Select all), then click Detach selected. There is no extra confirmation dialog. This forgets the selected PRs and their comments in this Session only; nothing changes on GitHub or Bitbucket. If a detach fails, the other PRs are still processed and failed PRs stay selected for retry. Clicking a row outside its checkbox still opens the PR.

Paste a GitHub or Bitbucket Data Center pull request URL into a prompt, or ask the agent to open one (gh pr create or bb pr create in the box), and the PR is attached to the session (a PR URL the agent writes in a reply attaches too; the ones it merely reads — gh pr list output, a changelog — do not): a PRs tab appears in the pane switcher with one row per PR: the provider's icon, owner/repo#123, the title on one line, and a state chip (Open, Draft, Merged, Closed, coloured by the review: ✓ approved, ✗ changes requested, ◌ review pending). A second, smaller line says only what needs you — unread items, open threads, failed or running checks, auto-merge, a watching problem — and when the PR last moved; PRs with something new come first and carry a dot. The ⋯ menu at the end of the row holds Open, the link to the PR on GitHub or Bitbucket, Refresh, Mark seen, Watch / Stop watching, Auto-merge on/off and Detach. Click a row to open the PR inside the pane: the title, a chip row (state, base ← head, author, provider link), a toolbar (Refresh, Mark all seen, Auto-merge, Detach), the Checks section, then the comments grouped by thread (rendered like GitHub renders them, HTML included — cut down to GitHub's allowlist of tags, so a comment cannot carry scripts, styles or forms into the page), and a breadcrumb at the top — Pull requests › owner/repo#123 — that takes you back to the list. You can also attach one by hand from the PRs tab (+ Attach): a URL, owner/repo#123, or just #123 when exactly one repository is in the workspace (owner/repo#123 — KEY/slug#123 for Bitbucket — when there are several). Detaching only forgets it here; nothing changes on the server.

Sessionboxer then watches each attached PR: about every minute while the session is idle or stopped, every five minutes while the agent is working (GitHub's conditional requests keep unchanged polls free). The requests run as gh api inside the box, with whatever GitHub login the box has: a GitHub entry from Settings (see below), a manual gh auth login in a terminal, or a GH_TOKEN; the login used is shown in the row (synced 20s ago as @you). When the box is stopped the Control Plane polls with the connected GitHub account instead, if one of them can read the PR; otherwise the row says watching paused — Sandbox stopped until you resume. A PR nobody can read says so, and a closed or merged PR stops being watched a day after closing.

Bitbucket Data Center. A PR on a self-hosted Bitbucket (https://bitbucket.example.com/projects/KEY/repos/slug/pull-requests/12, with or without /overview or /diff) is watched the same way, always from the Control Plane with the Bitbucket entry for that host — the one bound to the Workspace repository first, then any other for the host — whether the box is running or not, so a stopped session keeps watching too. The row shows the host next to the PR and no Bitbucket login for host when no entry for it is enabled in the session. Comments and their replies (from the PR's activities: conversation comments, inline ones with their path:line, tasks marked Task, resolved threads), approvals and needs work arrive as items; the build statuses on the head commit (Bamboo, Jenkins, GitHub Actions posting to Bitbucket…) arrive as Checks — running / passed / failed / cancelled, with the plan or parent build as source, the required-build merge check of the target branch marking them required, and the name linking to the build. Not covered: Bitbucket Cloud (bitbucket.org), a Data Center served under a context path (https://host/bitbucket/…, the entry's host has no path), and Auto-merge, which is GitHub-only (HTTP access tokens cannot merge; the section is hidden for Bitbucket PRs). The fix prompts speak Bitbucket (bb pr checks, bb pr comment --reply-to) instead of gh.

New comments and reviews by other people make the PR's number in the sidebar and the PRs tab light up with an unread count, and show a toast (and a browser notification, if you allow them from the PRs tab). When the agent is busy the toast waits until its turn ends, so it does not talk over the reply you are reading; the counts update right away. Opening a PR marks its items read.

Checks. The same polls read the checks on the PR's head commit — GitHub Actions jobs and other check runs, plus plain commit statuses — and the PRs row shows how many failed, are running and passed. A check that fails counts as unread and is announced like a comment (toast, browser and push notification: a check failed); a check that keeps failing on the same commit is not announced again, a new push or a re-run that fails again is. In the PR's view a collapsible Checks section above the comments — folded to ✓ 12 checks passed when all is green, open by itself when something failed or is still running — shows each check on one line: its result (failed, timed out, cancelled, action required, running, passed), the workflow or app it comes from, whether branch protection requires it, when it ran, and a link to the log on GitHub. A failed check has a checkbox (shown when you hover the line or once something is ticked) and a ⋯ menu with To prompt, Fix and Fix & push; the bar that appears at the bottom of the pane while something is ticked applies the same to ticked checks, alone or together with ticked comments: the agent gets the check's name, conclusion, log link and summary, is told the CI output is diagnostic material rather than instructions, reads the log (gh run view --log-failed for Actions), reproduces the failure in the workspace, fixes it, verifies and commits; Fix & push also pushes so the checks run again. The check's line follows: in prompt, addressing, then addressed once the check passes on a later commit. Running and passed checks are listed for reading only. When a workflow ran more than once on the same commit (a re-run, a renamed branch), only its newest run is listed and counted, as in GitHub's merge box.

In a PR's view the comments are grouped by review thread — a path:line heading that opens the file in the Code pane, then the comments in order, resolved and outdated threads greyed (hidden until you tick show resolved) — with conversation comments and reviews (✓ approved, ✗ changes requested) under Conversation. Unread comments carry an accent on the left. Every comment has a checkbox and a ⋯ menu with three actions, and the bar at the bottom applies the same three to the ticked items at once:

• To prompt puts the item(s) into the prompt box, quoted and with the PR, author and path:line, for you to edit and send. Nothing is sent.
• Address sends that prompt to the agent (if it is busy, the prompt joins the Queue and is sent when the turn ends): edit, verify and commit on the PR's branch in the workspace, but do not reply or push; you keep the GitHub conversation.
• Address & reply does the same and additionally has the agent push, reply to each item on GitHub with gh api (on Bitbucket with bb pr comment --reply-to) from the box and resolve the review threads it addressed. Bulk replies ask for confirmation first.

The prompt tells the agent the quoted text comes from reviewers and is feedback to evaluate, not instructions from you. Address buttons are only enabled when the PR belongs to one of the repositories in the workspace; for another repository use To prompt and tell the agent where to work. The comment's line follows it: in prompt, addressing, then addressed once the agent replied in the thread or the thread was resolved.

Auto-merge. Open Auto-merge in a PR's toolbar, tick Auto-merge when checks pass (and pick merge commit, squash or rebase under it) and the Control Plane asks GitHub every 10 seconds whether the PR may be merged, and merges it the moment the answer is yes: every check green — required or not — the reviews branch protection wants in, no conflict, not a draft, still open. The status line under the toolbar (and the popover) says what it is waiting for (3 running — build, lint, e2e, conflicts with the base branch, reviews required…), the Checks list above showing each of them; a branch that fell behind its base is brought up to date once per head. The merge is the normal GitHub merge — with the head commit pinned, so a push that lands between the check and the merge makes GitHub refuse and the next check starts over — so it never bypasses protection rules, and it runs with the same login the PR is watched with (the box's gh, or the connected GitHub account while the box is stopped). Once merged, the row says so, a toast and a push notification tell you, and nothing is checked again; untick (or Auto-merge off in the row's menu) to stop at any time.

Pull requests you follow

Pull requests in the sidebar (next to Automations) lists open PRs the Control Plane follows for you, whether or not a session has them attached. + Follow adds a repository (owner/repo, a PROJECT/slug on a Bitbucket Data Center host, or the URL; the ones you named before on that host are suggested), My PRs (the ones a connected login opened, in any repository it can see) or Reviews asked of me, each read with one of your connected logins — the token stays in the Control Plane; nothing is posted. Follows appear as chips with the number of open PRs; the ⋯ menu polls one now, pauses or unfollows it, and a chip turns red when the login cannot read the repository. Every follow is polled about once a minute (GitHub's conditional requests keep unchanged polls free; a search-backed follow is one request a minute), a PR's comments and checks every five minutes and right after its head moves; a merged or closed PR stays for a week.

The list is sorted needs-attention first: unread comments, failing checks, then the most recently updated. A row opens the PR by itself: state and review chip, branches, author, reviewers, labels, the Checks (folded when green, with the result, summary and a link to each log), the Comments & reviews grouped by thread like in a session's PRs pane, the Events the poller noticed (opened, new commits, comment, review, check failed, ready for review, merged, closed) and the Automation runs on this PR. There is no agent here: tick comments and failed checks and Copy them as text — or Copy failures for every failing check at once — to paste wherever you investigate. Attach to Session puts the PR in an existing session's PRs pane, where Address works; Start Session opens a new session with the PR's branch checked out and the PR attached, with a first prompt of yours or a short brief naming the PR; Run automation… runs one of your PR automations on this PR by hand.

Following a PR does nothing by itself. An automation with a pull request trigger picks the follows it listens to and reacts to their events within its limits (concurrency, runs per day and per PR, a debounce so a burst of pushes runs once, drafts and forks filtered); its badge shows on the PR's row. The agent can follow too: pr_follow and pr_followed_list in the sessionboxer MCP.

Polling every minute is the source of truth; a webhook is an optional accelerator for when a tunnel with a stable hostname is up (Remote access; the Cloudflare quick tunnel changes its hostname at every start and is not worth one). Webhook… in a follow's menu registers a repository webhook on GitHub with the follow's login (repository follows; the login needs admin) or, for Bitbucket Data Center and for My PRs / Reviews asked of me, gives you the payload URL and the secret to paste into the repository's webhook settings. A delivery only makes the Control Plane poll that PR right away — nothing in it is trusted or shown — and a follow whose hook delivered in the last hour (healthy) lists every 5 minutes instead of every minute. Turning it off or unfollowing removes the hook.