PR Cockpit: A Local AI Review Workbench for a Repo's Whole PR Queue

What PR Cockpit actually solves, and for whom

The README frames the problem in one line: no more reviewing PRs one at a time in the terminal, and no more scattering fixes and feature work across separate shells. That is a narrower claim than it sounds. The tool is not a linter and not a CI check. It is a workbench that pulls a repository's PR list through `gh` and GraphQL, hands each PR to an AI agent running in an isolated read-only git worktree, and returns structured findings plus a plain-language summary of what the PR is trying to do and the shortest manual test path for it.

The audience is specific. You need to be the kind of reviewer who works through a queue, not a single diff: a maintainer, a tech lead, or a developer on a team where PRs accumulate faster than anyone reads them. You also need a Claude or Codex subscription, because the README states the app runs on your own subscription rather than metered API calls. The `.env.example` spells this out for the Claude path: using the locally logged-in `claude` binary means essentially no extra API cost. If your team's policy forbids sending source code to a model provider at all, this tool does not change that equation. It changes where the code goes, not whether it goes.

Isolated worktrees, read-only review agents, and the human gate

Three mechanisms do the real work, and they are separable.

The first is the worktree. Write-capable paths (fix chat, feature development) run inside isolated git worktrees rather than in your working directory. The README states that git operations on the same repo are serialized, that findings are transactional, that deleted tasks clean up worktrees, and that restarts recover or stop interrupted work. That last pair matters more than it reads: a desktop app that shells out to git will be closed mid-operation, and the design assumes it.

The second is the read-only review agent. Review runs in an isolated read-only worktree with tool-level blocking for git writes, file edits, network access and dangerous commands, plus what the README calls an operating contract and skill linting. This is a policy enforced at the tool layer, not a prompt instruction the model can talk itself out of. Findings come back structured: severity, `path:line`, problem, detail and fix guidance.

The third is the gate. Nothing posts to GitHub until you check a per-finding box, and the note you attach is woven into the comment as an edit instruction rather than leaked verbatim. Before publishing there is a dry-run preview that is cacheable and regenerable, and findings written in any working language are rewritten as professional English GitHub comments. Findings whose `path:line` lands on a line the PR actually changed become inline review comments; the rest are collected into a summary section instead of being dropped. Publishing goes through `gh api .../reviews` with a posting claim and self-healing cleanup of leftover pending reviews, which the README says prevents duplicate concurrent posts.

Installing PR Cockpit and running a first review

The README points at the releases page first: a desktop build needs no clone and no toolchain. Builds are published as a rolling `nightly` pre-release, rebuilt on every push to `main`. macOS Apple Silicon gets a `.dmg`, Windows x64 an `.exe`, Linux x86_64 an `.AppImage`. Intel Macs are not covered by a prebuilt package, so those users build from source.

None of the packages are code-signed, and the README is explicit that every platform warns on first launch. On macOS the app is reported as damaged or from an unidentified developer; clearing the quarantine flag once is the documented fix.

xattr -dr com.apple.quarantine "/Applications/PR Cockpit.app"

On Linux the AppImage needs the executable bit before it will start.

chmod +x pr-cockpit-*-x86_64.AppImage

On Windows the README describes a SmartScreen dialog and the More info then Run anyway path. Before the app can do anything you still need `gh auth login` and a Claude or Codex login.

For source builds, the repository is a Nuxt 4 project with pnpm. The `package.json` scripts are the map: `dev` runs `nuxt dev`, and `electron:dev` runs the Nuxt dev server alongside Electron.

pnpm install
pnpm electron:dev

The `electron:dev` script waits on `tcp:127.0.0.1:3000` before launching Electron, so the window appears after the dev server is listening. Provider defaults live in `.env.example`, which is copied to `.env` and edited.

INFERENCE_PROVIDER=claude
ANTHROPIC_MODEL=sonnet

`INFERENCE_PROVIDER` accepts `claude` or `codex`; `codex` sets the global default while project config can still override it per project. `ANTHROPIC_MODEL` takes aliases (`sonnet`, `opus`, `haiku`, `default`) or a full model name. Once the app is up, the first real use is to point it at a repository, pull the PR list, and open one PR's drawer. That drawer holds the AI review, fix chat, timeline and diff. Read the review, leave the checkboxes alone, and open the pre-publish preview. You should see the inline comments and the summary section separated exactly as they would post.

Where PR Cockpit is the wrong tool

The unsigned nightly is the first limitation and the README does not soften it. There is no stable release channel, only a pre-release rebuilt on every push to `main`. On a managed fleet, an unsigned Electron app that shells out to `gh`, `git` and a model CLI is a conversation with your security team, not a download.

The second limitation is the review agent's own read-only guarantee. Blocking git writes, file edits and network access at the tool layer is the right design, but it means the review agent cannot verify a claim by running the test suite. It reads. If your PRs are the kind where correctness depends on runtime behaviour, the AI findings will be plausible and unverified, and the README's mention of a manual test path is an acknowledgement of that gap rather than a fix for it.

The third is scale. The PR list auto-refreshes on a poll while the page is visible, and each review runs a model turn against a worktree. On a repository with a large open queue, that is a lot of local compute and a lot of subscription quota. The README does not document a queue-level budget or a concurrency cap for reviews, so plan to pull a filtered slice rather than everything.

Finally, the README's own safety section says PR automation is high-risk and disabled by default. If what you wanted was an unattended bot that comments on every PR as it opens, this is the opposite of that product.

How it differs from GitHub Copilot code review and hosted review bots

The obvious alternative is a hosted reviewer: GitHub's own Copilot code review, or one of the CI-mounted bots that comment on a PR when it opens. The difference is not model quality. It is where the review happens and who holds the trigger.

A hosted bot runs in the provider's infrastructure against a PR that GitHub already knows about, and its comments appear as part of the PR's timeline. PR Cockpit runs the review locally, in a worktree on your machine, against a PR it pulled through `gh`. The findings live in a local SQLite database (the repository ships `drizzle.config.ts` and a `db:studio` script) until you publish them. The README's framing is that GitHub remains the external system of record, which is a deliberate inversion: the local app is where review happens, GitHub is where the record ends up.

That inversion buys the gate and the scratchpad. You can re-review after the author pushes new commits and keep your checkboxes and notes; you can chat with the agent about a fix without committing anything, since the fix tab does not commit or push by default and Commit and upload first shows the diff plus an editable conventional commit message. A hosted bot gives you none of that. What it gives you instead is zero setup, no subscription dependency, and a review that runs whether or not anyone's laptop is open.

There is a second, less obvious alternative: doing the same work with the `claude` or `codex` CLI directly in your terminal. That is free of the app and loses the worktree isolation, the structured findings schema, the transactional persistence and the dry-run preview. PR Cockpit is largely an argument that those four things are worth a desktop app.

Maintenance, upgrade cost, and what the MIT licence does not settle

The repository is not archived and the last push was on 2026-09-02, so the project is current as of two weeks before this writing. The only published release is a `nightly` pre-release dated 2026-07-01, rebuilt on every push to `main` according to the README. Practically, that means upgrading is re-downloading the nightly, and there is no changelog surface described in the README beyond the release itself. If you build from source, you are tracking `main` by definition.

The dependency list carries its own upgrade cost. The app pins `@openai/codex` at `0.149.1` while `@anthropic-ai/claude-agent-sdk` floats on `^0.3.246`, and there is a `codex:types` script that regenerates types from the Codex package. A pinned Codex version plus a generated type surface means Codex upgrades are a deliberate, scripted step rather than something a lockfile refresh handles. Nuxt 4, Vue 3 and the rest float on carets.

The MIT licence is permissive and the repository ships a `LICENSE` file. What MIT does not settle is the model side. The README states the app runs on your own Claude or Codex subscription, and the `.env.example` notes that the `claude` path uses the locally logged-in binary and therefore essentially no extra API cost. Whether your subscription terms permit this use, and whether pasting a private repository's diffs into a model session is acceptable to your employer, are questions for your own policies. Nothing in this repository answers them.

Editorial conclusion

Adopt PR Cockpit if you already pay for a Claude or Codex subscription, you review many pull requests in one repository, and you want the AI's findings to arrive as a draft you approve rather than as comments GitHub sees first. Skip it if you need code-signed installers for a managed fleet, if Intel Macs matter to you, or if your review process lives inside GitHub's own UI. Before trusting it on a real repository, run one PR end to end: confirm the review agent cannot write, check that a finding on an unchanged line lands in the summary section rather than disappearing, and confirm that the pre-publish preview matches the comments that actually post. The project is MIT licensed and the last push was on 2026-09-02, so the code you clone is the code that was current two weeks ago.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. taovc/pr-cockpit on GitHub