---
title: "Pull requests"
description: "Take thread work through pull requests, reviews, branch updates, and CI."
canonical_url: "https://hoplite.sh/docs/github"
markdown_url: "https://hoplite.sh/docs/github.md"
---

# Pull requests
URL: /docs/github
LLM index: /llms.txt
Description: Take thread work through pull requests, reviews, branch updates, and CI.
Related: /docs/threads/review, /docs/agent/tools, /docs/ci

# Pull requests

Take agent work through a pull request with its conversation and diff close at hand. Linked PRs connect the thread to GitHub checks, reviews, and autofix, so you can continue working on feedback in the same task context.

GitHub repository access comes from the workspace's GitHub App installation. A thread's PR links connect its conversation and workspace to checks, reviews, and autofix.

PRs associated with a visible originating thread get an **Open in Hoplite** button appended to their description, linking back to that thread — useful for a reviewer who wants the full conversation behind a change.

## Start a thread from an existing PR

In the new-thread dialog, select the repository, open the source picker, and
choose **PRs** instead of **Branches**. Search for an open pull request and
select it to start from its head branch. Hoplite retains the pull request as the
thread's source, links its live checks and reviews, and gives the agent the PR
metadata as working context from the first run.

## Open a PR from a thread

Ask the agent to open a pull request, or type [`/pr`](/docs/agent/slash-commands) to create a draft PR from the thread's current diff. The agent can:

- Open PRs as **draft or ready**, and promote an existing draft without recreating it
- Comment on PRs and reply to review comments
- List a PR's files and checks, and fetch per-file diffs
- Request reviewers and resolve review threads
- Merge — merge, rebase, or squash

These actions run under the configured GitHub App's repository permissions. [Approval](/docs/threads/review#approvals) continues to protect sandbox-local changes and disruptive operations.

You can also ask the agent to link an existing open PR to the thread. Linking immediately synchronizes its current checks and review state and, when GitHub autofix is enabled, arms the automatic review loop.

To stop tracking a linked PR without closing it on GitHub, select **Unlink thread from pull request** in the thread's actions or context menu. The thread keeps its conversation and workspace; the agent also retains a note that the PR was deliberately unlinked, so it won't mistake the old link for a current PR. You can link a PR again later.

## Rebase onto the base branch

The agent can rebase a linked pull request onto its base branch. On conflict, Hoplite returns the named conflict files for the agent to resolve in the workspace. Publication of the rebase is an intentional non-fast-forward rewrite, protected by an exact remote-head lease: a concurrent branch update is rejected rather than overwritten. This is separate from selecting the `rebase` merge method.

## The PR view

Open a pull request from the **Pull requests** page or the linked thread's **PR** tab. Both use the same view for its description and activity, checks, reviews, changed files, and merge controls. The layout adapts to the available width:

| Section | What you see |
| --- | --- |
| Branches and state | Head and base branches, PR state, and status checks |
| Reviews | Reviews and unresolved comments, each with author, file and line reference, and age |
| Attach all comments | Pulls reviewer comments into the thread as context, so your next message can just be "address the review" |
| Merge | Merge with one of the methods allowed by the repository |

The merge picker follows the repository's GitHub settings. It only shows allowed methods and disappears when the repository permits a single choice; manual and automatic merges both fall back to an allowed method rather than sending GitHub a method it will reject.

## Fix failing CI

An open PR with failing checks shows **Fix CI** in its checks panel. Select it to ask the agent to read the failing logs, fix the causes without weakening tests, run relevant checks, and push to the PR branch. If a thread is already linked, the request goes to that thread; otherwise Hoplite starts a fix thread. The button shows **Requesting…** and then **Fix requested** to prevent duplicate requests.

This manual request is separate from enabling PR autofix. Requests sent to an already linked thread explicitly ask the agent not to merge; new fix threads use the normal project defaults. Check the PR autofix and auto-merge controls separately.

## Merge queues

When GitHub accepts a pull request into a repository's merge queue, Hoplite shows **Queued to merge** in the PR view and thread list. GitHub owns the merge at that point, so the merge action is disabled and the agent will not make a duplicate merge request. The review loop continues reconciling the queue while it waits for GitHub to merge or remove the PR, and reports that outcome in the linked thread.

While a PR is queued, hovering its PR chip shows a live countdown to GitHub's estimated merge time, when GitHub provides one.

With PR autofix enabled, removal from GitHub's merge queue starts a repair pass even when the PR's own checks are green. The agent examines merge-group checks and logs, fixes actionable failures, or explains a blocker requiring human action. That repair pass does not merge, close, or re-enqueue the PR.

## Run Hoplite from a PR comment

An authorized workspace member with repository access can comment `@usehoplite <instruction>` (or `@hoplite <instruction>`) on a GitHub pull request. Hoplite reuses the linked PR-command thread, adds 👀 when work starts, replaces its own 👀 with 👍 on success, and removes its 👀 on failure or cancellation. Reactions from reviewers are left untouched.

PR-comment commands support same-repository head branches only. Hoplite rejects
fork pull requests before creating a thread or run, because executing
fork-controlled code with the base project's environment or trusted repository
context would cross the credential boundary.

## The review loop

Hoplite always tracks a linked PR's review threads, comments, and checks via webhooks. When **PR autofix** is enabled, eligible feedback and checks start agent passes according to the selected triggers below. Feedback that arrives while another pass owns the thread shows as queued and starts a follow-up pass after ownership is released, rather than getting lost or requiring a manual prompt.

Webhooks wake reconciliation even when no agent work is needed. The loop can start these passes:

| Pass | What triggers it |
| --- | --- |
| Fix | New authorized conversation comments, unresolved current inline review threads, non-empty `COMMENTED` reviews, `CHANGES_REQUESTED` reviews, or failing checks once the repair-gating checks settle. An `APPROVED` review's body alone does not request a fix; its inline threads can still be actionable. |
| Merge-readiness | A non-draft PR has green checks, is mergeable, has no outstanding review requirement or actionable feedback, and needs a readiness audit for the current state. |
| Settled-report | Checks turn green after the thread's last run, reviewer waiting has settled or timed out, and no fix, conflict, or readiness pass is needed. The agent reports the settled outcome in the thread. |
| Conflict | GitHub reports a merge conflict while autofix is enabled, even if checks are still pending. |
| Queue removal | GitHub removes the PR from its merge queue while autofix is enabled, even if the PR's own checks are green. The repair pass does not merge or re-enqueue it. |

### Limit automatic triggers

Workspace owners and admins choose triggers under **Settings → Workspace → General**, in **Runs on** beneath **Autofix**. A project can override them under **Settings → Project → Agents** in **Autofix runs on**; choose **Use workspace setting** to follow the workspace selection again. Projects inherit the workspace selection unless they have an override. All seven triggers are enabled by default. An empty selection disables automatic agent passes without disabling PR synchronization. Changes apply when existing linked PR loops next reconcile; they do not cancel a pass already in progress.

| Setting | API value | Automatic agent work |
| --- | --- | --- |
| Changes requested | `changes_requested` | Authorized `CHANGES_REQUESTED` reviews. |
| Review comments | `review_comments` | Authorized conversation comments, unresolved current inline threads, and non-empty `COMMENTED` review bodies, independently of the PR-wide review decision. Approval bodies never qualify. |
| Failing checks | `failing_checks` | Failing checks once repair-gating checks settle. |
| Merge conflicts | `merge_conflicts` | Merge-conflict repair. |
| Removed from merge queue | `queue_removal` | Merge-queue removal repair. |
| Final check when green | `merge_readiness` | Merge-readiness audits. |
| Report when checks finish | `checks_settled` | Settled-outcome reports. |

Selecting triggers does not enable autofix or change the separate permission to auto-merge or enter a merge queue. All webhooks continue synchronizing PR state, and manual **Fix CI** requests remain available.

You can also manage triggers through the API and the agent's settings tool. Read the workspace default with `GET /api/orgs/pr-review-autofix-triggers`, or set it with `POST` to the same endpoint and a body such as `{"triggers":["changes_requested","review_comments"]}`. Workspace owners and admins can change it. On project creation (`POST /api/projects`) or update (`PATCH /api/projects/:projectId`), use `prReviewAutofixTriggers` with an array of triggers; set it to `null` to restore inheritance. Project reads return the nullable override.

The agent's settings tool exposes `pr_review_autofix_triggers` for the workspace and `project_pr_review_autofix_triggers` for a project. Project reads and writes return both the override and the resolved triggers, so the agent can confirm what applies.

Besides feedback from authorized people, the loop acts on feedback from these reviewer bots, matched by their GitHub App identity: Greptile, cubic, CodeRabbit, Copilot code review, and Sentry. Feedback from other bots doesn't start a pass unless your workspace trusts that App.

### Trust more reviewer apps

Workspace owners and admins can add other GitHub Apps under **Settings → Workspace → General**, in **Trusted reviewer apps** beneath **Auto-merge**. Enter each App's slug, the part of its bot login before `[bot]` (for example `coderabbitai` for `coderabbitai[bot]`). A workspace can list up to 20 Apps. Hoplite still checks that the comment comes from a GitHub App bot account and, when GitHub names the App that posted it, that the App matches the login, so a person or another App can't borrow a trusted name.

A trusted App's review comments act as instructions to the agent in the same way an authorized reviewer's do. Only add Apps you'd let direct changes to your pull requests. That's why only owners and admins can see or change the list.

Hoplite's own GitHub App is never trusted, even if you add it. Its comments are the review loop's own output, so treating them as new feedback would let each pass start the next one. The settings page and API reject its slug.

Through the API, read the list with `GET /api/orgs/pr-review-trusted-reviewer-apps` and replace it with `POST` to the same endpoint and a body such as `{"slugs":["my-review-bot"]}`. To avoid overwriting someone else's change, also send the list you read as `expectedSlugs`. If the stored list no longer matches it, the request fails with `409` and changes nothing. Both endpoints require an owner or admin. Changes apply the next time a linked PR's loop reconciles and are recorded in the workspace settings audit log.

Autofix pauses itself when a loop stops making progress: after repeated runs on the same pull request state, or after 12 runs in an hour. The PR shows the reason, and the next push or new review feedback resumes it. After 10 runs without input from a person, autofix turns off instead of merely pausing; a push or new review won't turn it back on. Turn **PR autofix** back on explicitly to continue.

Workspace members can enable or disable autofix for an individual thread's PR without changing workspace or project defaults. Use the linked PR controls or the thread context menu; multi-selected linked threads also offer bulk enable/disable actions. Automatic passes appear in a collapsible **Auto fix** transcript divider.

You can explicitly ask the agent to enable autofix for an eligible linked, open GitHub PR, including one previously opted out. Asking only to monitor comments does not authorize automatic fixes. Auto-merge has a separate merge permission: use **Enable auto-merge / queue when green** in the thread context menu to queue the PR when the repository uses a merge queue, or merge it directly when green otherwise.

Workspace owners choose the default under **Settings → Workspace → General**; projects can inherit or override the autofix default under **Settings → Project → Agents**. **PR auto-merge** is a separate workspace default and per-PR control: it waits for required checks and review-loop work to settle before merging with a repository-allowed method. Spawned threads inherit those defaults unless their creator explicitly overrides autofix or auto-merge. Automatic autofix is currently GitHub-only; other source-control providers still receive passive synchronized state.

## Commits and credentials

Git and GitHub CLI operations use a short-lived installation token scoped to the active repository. Hoplite stores its CLI configuration privately inside the sandbox and applies command policy to authenticated operations. See [Security](/docs/workspace/security#repository-credentials) for the exact boundary.

Hoplite's trusted automatic Git operations skip repository hooks. Run required validation explicitly before publication rather than relying on automatic commits to execute hooks; explicitly requested workspace commands remain subject to command policy.

When using the CLI to create a PR, the agent also links it to the thread. Creating a PR without that link does not subscribe it to Hoplite's autofix loop.

## Sitemap

Sitemap discovery is not enabled for this deployment.