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

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 PRs tab appears in the pane switcher with one row per PR (state, review decision, unread items, open review threads, last activity, watch switch, Refresh / Detach / a link to the PR on GitHub or Bitbucket); click a row to open the PR inside the pane, with its conversation comments, inline review comments and reviews in a table (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: 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 list above the comments (it opens by itself when something has failed) shows each check with its result (failed, timed out, cancelled, action required, running, passed), the workflow or app it comes from, whether branch protection requires it, the commit and when it ran, with the name linking to the log on GitHub. Failed checks have a checkbox and three buttons — To prompt, Fix and Fix & push — and the bar under the table 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 status column 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 every item has a checkbox and three buttons, and the bar above the table 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. A path:line in an inline comment is a link into the Code pane, and the item's status column follows it: in prompt, addressing, then addressed once the agent replied in the thread or the thread was resolved.

Auto-merge. Tick Auto-merge when checks pass in a PR's view (and pick merge commit, squash or rebase next to 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 line next to the switch 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 to stop at any time.