--- title: "Pull requests" description: "How agents open, manage, and merge PRs — and how credentials stay out of the sandbox" 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: How agents open, manage, and merge PRs — and how credentials stay out of the sandbox Related: /docs/threads/review, /docs/agent/tools, /docs/ci # Pull requests Pull requests are how thread work ships. Every PR links back to the thread that produced it, so the conversation, the diff, and the PR stay one unit of work. Hoplite works through a GitHub App installed on your organization or account. It powers repo access, branch operations, commits, pull requests, and the webhooks that keep threads in sync with review activity. Agents act through a provider-neutral source-control surface, so workspaces enrolled in the separate GitCafe rollout can bind GitCafe repositories from [Integrations](/docs/integrations) and use the same tools; GitHub App installation and webhook behavior remains GitHub-specific. 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. ## 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 rail Once a thread has a live PR, the **PR rail** slides out alongside the conversation: | 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. ## Run Hoplite from a PR comment An authorized workspace member with repository access can comment `@usehoplite ` (or `@hoplite `) 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, existing or newly arriving feedback and failing checks wake an agent pass automatically. 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. 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 Every sandbox has a repo-scoped Git identity, and may include the `gh` binary — but agent-authored shell commands never receive GitHub App credentials, so `git` and `gh` cannot inherit repository authority. Instead, Hoplite brokers short-lived, repository-scoped installation tokens inside its trusted worker, where first-party [source-control tools](/docs/agent/tools#source-control) bind every request to the thread's configured repository. Worker-owned Git publication is authenticated command-locally: tokens never reach the workspace filesystem, shell environment, Git configuration, or remote URL. Publication paths also reject repositories with tracked submodules before pushing. A compromised or confused agent process cannot exfiltrate a repository credential, because no credential ever exists in the sandbox. Repository authority lives only in Hoplite's trusted worker, scoped to one repository at a time. ## Sitemap See the full [sitemap](/docs/sitemap.md) for all pages. Well-known sitemap: [/docs/.well-known/sitemap.md](/docs/.well-known/sitemap.md).