---
title: Pull Requests
---

# Pull Requests

## What it is

This page is kept for historical reference: the built-in GitHub feature it describes has been **REMOVED from Omniscio core** (the "in-core GitHub detachment"). The built-in `gh:*` GitHub feature — Pull Requests, Issues, Code Search, Releases, and the GitHub notifications channel — has been removed; install the **github-integration** marketplace plugin for it. GitHub bug-intake, the PR merge-queue, the PR inbox backend, and cloning a GitHub repo when adding a project remain built in.

The removal is complete: the built-in GitHub feature is **FULLY REMOVED and plugin-only**. The in-core code is gone — there is no longer any way to restore it (the old Settings > Lab > "Built-in GitHub (legacy)" toggle and the `AMC_SHOW_INCORE_GITHUB` env var no longer exist). It is superseded by the **GitHub Integration** marketplace plugin, which has full parity plus a codebase browser, a unified siderail, and a repo navigator. Install the plugin for GitHub features.

What the tab did, when it existed: it was a cross-repo GitHub pull-request manager, modeled on GitHub Desktop but focused only on PRs. It listed the pull requests you're involved in across every repo your GitHub account can access, and let you view a PR (description, changed files, checks, review timeline), add a comment, approve or request changes, and merge — all without leaving Omniscio.

It was released for everyone: the **Pull Requests** entry appeared in the left sidebar by default, with no toggle to find first.

It shells out to the GitHub CLI (`gh`), so it requires `gh` to be installed and signed in. If it isn't, the tab shows a **Connect GitHub** button that walks you through setup (the same one-click install + sign-in flow as GitHub Notifications) and scrolls you to the GitHub settings card.

## Where to find it

The surface was a **Pull Requests** entry in the **left sidebar**, opening a tab with a PR list down the left and the selected PR's detail on the right. A **+** button in the tab header opened the create dialog. A **Connect GitHub** button appeared in place of the list when `gh` was not set up. The optional Inbox rows were turned on separately in **Settings → Lab → "PRs assigned to me in Inbox"**. With the feature plugin-only, none of this ships in core — the same surfaces are provided by the **GitHub Integration** marketplace plugin, which you install from the Marketplace.

## How it behaves

### How to use it

1. **Open it.** You clicked **Pull Requests** in the left sidebar.
2. **Connect GitHub** (first run only). If `gh` wasn't set up, you clicked **Connect GitHub** — Omniscio installed the CLI if needed and signed you in.
3. **Browse PRs.** The left list showed the pull requests you were involved in across all your repos. Filter chips narrowed it to **Created by me** or **Review requested**.
4. **Open a PR** to see its description, changed files, checks, and the comment/review timeline.
5. **Act on it.** You could add a comment, **Approve** / **Request changes**, or **Merge** (with a confirmation step — merge was the one irreversible action).

### Creating a pull request

When GitHub was connected, a **+** button appeared in the Pull Requests tab header. It opened a dialog that created the pull request on GitHub directly, with no local checkout involved.

1. **Pick the repository.** The dropdown listed the repos from your PR list plus your own repos; choosing **Type a repository...** let you enter any `owner/repo` you could access.
2. **Pick base and head branches.** Both lists came from the repo's real branches on GitHub (the first 100 alphabetically, with the default branch always included; a note told you when the list was truncated). There was no free-text branch field, so the dialog could never invent or push a branch.
3. **Title and description.** If the repo had a pull request template, its first template prefilled the description; once you had typed in the box, switching repos never overwrote your edits.
4. **Optionally tick "Open as draft"**, then click **Create pull request** (or press Ctrl+Enter).

If the head branch already had an open pull request into the chosen base, the dialog showed it and disabled Create for that pair; picking a different base was still allowed. Creating needed the GitHub `repo` permission (the same one approve / request-changes / merge used); if your `gh` login did not have it, Omniscio ran the one-click grant first. On success the dialog showed the new PR number with a **View on GitHub** button; it could take GitHub a minute to show the new pull request in your list. Any failure was reported in plain language inside the dialog.

### Review comments on specific lines

Beyond the top-level comment box, you could hold a real line-level review conversation right inside the diff, so you rarely needed to open github.com to review.

1. **Open the changed file.** In **Changed files**, you expanded a file. A small comment-count badge on each file row told you which files already had review conversations.
2. **Read the threads.** Existing review threads appeared inline, directly under the line they were left on, showing every reply and whether the thread was resolved. Threads whose line was no longer in the current diff were grouped under an **Outdated** heading at the top of the file so nothing was lost.
3. **Reply** to any thread from the box at the bottom of it.
4. **Start a new comment on a line.** Hovering a diff line and clicking the **+** that appeared let you type a note and send it.
5. **Resolve or reopen** a thread with its toggle once it was handled.

Posting any of these needed the GitHub `repo` permission (the same one approve / request-changes / merge used); if your `gh` login did not have it, Omniscio ran the one-click grant first.

### PRs assigned to me, in your Inbox

You can also have pull requests **waiting on you** show up directly in the unified **Inbox**, so you see them without opening the tab. Two kinds surface as Inbox rows:

- **Review requested** — someone asked for your review.
- **Changes requested** — one of your own PRs got changes requested and is back in your court.

Turn it on in **Settings → Lab → "PRs assigned to me in Inbox"** (it requires `gh` signed in). While on, Omniscio checks GitHub in the background every few minutes; each matching PR becomes its own Inbox row (amber dot). Clicking a row opens the Pull Requests tab. Dismissing a row (middle-click on desktop, the X on mobile) hides it — with an Undo — and it stays hidden until you bring it back; a PR also drops off on its own the moment it no longer needs you. It's off by default, so there are no background GitHub calls until you enable it.

## For agents

The tab is an `amc-builtin` integration (virtual project `__pull_requests__`) registered in `src/shared/integration-registry.ts`, with its panel + sidebar wired in `src/renderer/src/integrations/ui-registry.ts`. Visibility routes through the unreleased-feature registry (`src/shared/unreleased-features.ts`, id `pull-requests`, status `'shipped'`): the Dashboard inline `visibleProjects` filter still calls `isUnreleasedFeatureVisibleInRenderer('pull-requests', settings)`, and the shipped status makes the gate pass for every user.

All GitHub data flowed through the `gh` service layer in the since-removed `src/main/services/github-notifications-service.ts` (`searchAuthoredPRs`, `searchReviewRequests`, `searchAuthoredChangesRequestedPRs`, `getPRDetail`, `getPRFiles`, `getIssueComments`, `getPRReviews`, `getDetailedCheckRuns`, `rerunCheckRun`, `postComment`) plus PR-write helpers for review submission and merge, exposed over `GH_PR_*` IPC channels. Line-level review threads add `getReviewThreads` (one GraphQL `reviewThreads` query) for the read and `addReviewComment` / `replyToReviewThread` / `setReviewThreadResolved` for the writes; the renderer anchors each thread to its diff row with the pure `partitionFileThreads` helper.

The **Checks** section (`PullRequestChecks`) in the PR detail panel is the per-check CI breakdown beneath the aggregated status badge. It lazily calls `GH_PR_CHECKS` on first expand (`getDetailedCheckRuns` for the PR head commit SHA), listing each check with its state and a link to its logs. A finished, failing check can be re-run in place via `GH_PR_CHECK_RERUN` (`rerunCheckRun` runs `gh api -X POST .../check-runs/{id}/rerequest`), which pre-flights the GitHub `repo` scope like review and merge and humanizes any gh failure. Full invariants: `.claude/memory/contracts/pull-requests-contract.md`.

Creating a pull request adds three channels: `GH_PR_CREATE_META` (`getPrCreateMeta`, one GraphQL call for the default branch, the first 100 head refs, and the PR template), `GH_PR_FOR_BRANCH` (`listOpenPrsForBranch`, the advisory already-has-a-PR check, fail-soft to an empty list), and `GH_PR_CREATE` (`createPullRequest`, a REST `gh api repos/{owner}/{repo}/pulls` POST, deliberately not `gh pr create` so no local git state is ever consulted). Full invariants: `.claude/memory/contracts/github-pr-create-contract.md`.

The **Inbox source** (`pr-inbox`) is a derived, self-clearing satellite: a background poller (`src/main/services/pr-inbox/pr-inbox-poller.ts`) wholesale-replaces a `pr_inbox_snapshots` cache each tick, and the renderer projected one row per PR (via the since-removed dedicated store `src/renderer/src/stores/pr-inbox-items.ts`; those rows now project through the generic inbox projector `src/renderer/src/stores/inbox/create-inbox-items-projector.ts`), registered in the inbox source list. It's gated on the same Pull Requests visibility gate plus the `prInboxEnabled` setting. Full invariants: `.claude/memory/contracts/pull-requests-contract.md` § `pr-inbox`.

## Related

The automated merge queue is a **separate** feature from this manual PR manager and is described in [pr-merge-queue.md](pr-merge-queue.md) — the two are frequently confused, so start there if you want queueing rather than reviewing. If you need the marketplace plugin that now carries all the GitHub surfaces this page used to provide, see [plugin-marketplace.md](plugin-marketplace.md). The sibling GitHub features that were removed in the same detachment have their own pages in [github-issues.md](github-issues.md), [github-code-search.md](github-code-search.md) and [github-releases.md](github-releases.md). For how the optional Inbox rows behave once turned on, read [inbox-overview.md](inbox-overview.md), and for the git safety rules that govern anything landing on a shared branch, [git-guardrails.md](git-guardrails.md).