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 was an amc-builtin integration (virtual project __pull_requests__), and it is gone from src/shared/integration-registry.ts and src/renderer/src/integrations/ui-registry.ts along with the rest of the detachment.

No registry entry records this removal. The pull-requests entry (src/shared/unreleased-features/pull-requests.ts) is still present and still reads status: 'shipped' with no retired flag, but it no longer gates any UI. It survives because the PR Inbox poller still names it as its visibility gate (src/main/services/pr-inbox/pr-inbox-poller.ts, featureId: 'pull-requests'), so the Inbox rows keep working for anyone with prInboxEnabled on. The sibling tabs removed in the same detachment — github-issues, github-code-search, github-releases, github-issue-create — each carry retired: true alongside status: 'in-development' in that registry; pull-requests deliberately does not, because the same id still serves the live Inbox source.

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 — 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. The sibling GitHub features that were removed in the same detachment have their own pages in github-issues.md, github-code-search.md and github-releases.md. For how the optional Inbox rows behave once turned on, read inbox-overview.md, and for the git safety rules that govern anything landing on a shared branch, git-guardrails.md.