OpenReview: a self-hosted code review bot that pushes its own fixes

A review bot you trigger by typing its name

OpenReview sits in a category that has become crowded, so it is worth being precise about what it does rather than what it promises. You comment `@openreview` on a pull request, optionally with an instruction, and a workflow starts. An agent reviews the diff, explores the surrounding codebase, runs whatever project tooling it decides is relevant, and posts findings as review comments with inline suggestions GitHub can apply in one click. If it changed files along the way, those changes are committed back to your branch. The sandbox is then torn down.

The instruction is optional and the three the README gives show the range of intended use:

@openreview check for security vulnerabilities
@openreview run the linter and fix any issues
@openreview explain how the authentication flow works

That last one is a good sign of ambition and a mild warning sign at the same time. A reviewer that explains your authentication flow is answering a question, not reviewing a diff, which means it will spend tokens and wall-clock time on a task that a teammate could do better for free. The tool is genuinely better suited to the mechanical half of review, where a machine that can run the linter and apply its output beats a person reading a diff.

There is also a reaction loop that is unusual among review bots. Reacting with a thumbs up or a heart approves a suggestion and applies it; a thumbs down or a puzzled face skips it. The event goes back through GitHub as a reaction webhook and starts a fresh workflow run, so approving is a one-click action rather than a round trip through the web interface.

The sandbox is the part that matters

Most automated review tools work from the diff alone, which means they cannot tell whether a change breaks a test, cannot know your lint configuration, and cannot verify that the thing they suggest compiles. OpenReview's answer is to give the agent a real environment through a Vercel Sandbox with full repository access, described in the README as capable of running linters, formatters and tests.

The sequence diagram in the README makes the mechanics concrete. A webhook event starts a workflow, which checks push access, creates a sandbox, clones the branch, installs dependencies and configures git. The agent then reads files and runs tools, receives command output back, and posts inline comments. Afterwards the workflow checks for uncommitted changes and, if there are any, commits and pushes to the branch before stopping the sandbox.

Running the project's own tooling is the substantive difference, and it is why the feature list includes code changes at all. A reviewer that can execute `npm run lint` and fix what it reports is doing something a diff-only model structurally cannot. It also means the agent's quality depends on your dependency installation succeeding, so a repository with a slow or flaky install will make the bot slow, and a repository with no install at all will limit it to reading.

Built as a Vercel stack test, and labeled as beta

The README's opening note is unusually direct. OpenReview is described as in beta, built as an internal project to help the Vercel team test their technologies together, with rough edges and breaking changes expected. Read the dependency list and it becomes clear how much of the stack is in play: Next.js 16.1.6, React 19.2.3, the Vercel AI SDK at version 6, Octokit for GitHub, Chat SDK 4.15 for the comment adapter, Vercel Sandbox at 1.7.1, and two Workflow packages that are both still beta, `workflow` at 4.1.0-beta.56 and `@workflow/ai` at 4.0.1-beta.54.

Durable workflow execution is the load-bearing piece. A review that installs dependencies, runs tools and pushes a commit can take minutes and can fail in the middle, so the engine has to be resumable rather than request-scoped, which is what the Vercel Workflow dependency is for. Two beta dependencies in the execution path is the main stability concern if you deploy this, and the README's own warning is the honest description of that state.

The tree is small and tells a similar story. Beyond the Next.js application there is a `workflow/` directory for the durable steps, `.agents/` for skills, `.claude/` for agent configuration, a `skills-lock.json` pinning skill versions, and formatting and lint configuration through `.oxfmtrc.jsonc` and `.oxlintrc.json` with the `ultracite` wrapper. The package is marked private at version 0.1.0 and uses Bun as its package manager, with a `bun.lock` rather than a package-lock. There are no published releases, so there is no upgrade path documented in the repository and no changelog to check before pulling new commits.

A skills system that keeps context small

Review quality on a large repository is usually a context problem: the model cannot hold the whole codebase at once. OpenReview's answer is a progressive skill system, described in the README as loading specialized instructions only when relevant so that context stays focused and reviews stay thorough. Skills are discovered at runtime from a `.agents/skills/` directory, which means you can add your own without forking.

The built-ins are telling, because they are all Vercel-ecosystem skills rather than general code review heuristics: Next.js best practices covering file conventions, server component boundaries, data patterns, async APIs, metadata and error handling; a caching skill covering partial prerendering, the `use cache` directive, cache lifetime and tag primitives, and tag updates; a Next.js upgrade skill that follows official migration guides and codemods; React composition patterns; and React performance guidance.

That concentration is both the strength and the limit. If your codebase is a large Next.js application, this bot has unusually well-matched prior knowledge. If it is a Go service, a Rust crate or an internal framework, the built-ins are dead weight and the review quality will rest entirely on the agent reading the diff. The custom skills hook is the answer, and it is the first thing you would build on.

The README also notes that model support is Claude Sonnet 4.6 through the AI SDK. That is a single provider today, which means the model choice is not a configuration decision you get to make yet.

Setup, and what the GitHub App is allowed to do

Deployment is one click from the Vercel template, and the configuration surface is small. You create a GitHub App pointing its webhook at your deployment, then supply five environment variables: the Anthropic API key, the App ID, the installation ID, the private key with escaped newlines, and the webhook secret. A Redis URL is optional and only affects persistence, since state falls back to in-memory without it.

The permissions are where the decision lives. The App requests contents read and write, issues read and write, pull requests read and write, and metadata read-only, and subscribes to issue comment and pull request review comment events. It checks push access before doing anything, which is a sensible guard, but the grant itself is broad: contents write access is exactly what lets the bot commit to your branch, and issues write access is what lets it post the review.

That combination is coherent with the feature list but it is a real risk surface. An agent that can read your repository, execute code in a sandbox, and push commits to a branch is close to a continuous integration system with a language model in the middle. The reaction flow helps, since approval is one click, but nothing in the description suggests the push path requires approval. If you deploy this, do it on a repository where an unwanted push is an inconvenience rather than an incident, and require branch protection on the target branch so a bot commit is at least reviewable by a human before it lands.

Maintenance state and the license gap

Two facts from the repository metadata are worth stating plainly, because the project's positioning does not quite cover them.

First, activity. GitHub reports 1,687 stars, 118 forks and 12 open issues, which for a project of this visibility is a low issue count and suggests active triage or a small user base. The repository was last pushed on 2026-03-06. That is roughly seven months ago, so this is not something being fixed continuously, and you should plan on pinning a commit rather than tracking a moving default branch.

Second, licensing. The repository description calls OpenReview an open-source, self-hosted project, and the README never mentions a license. GitHub reports no license for the repository and there is no license file in the tree. That is a genuine gap rather than a technicality: without an explicit grant you do not have permission to copy, modify or redistribute the code, whatever the README calls it. If your intent is to run it internally that may not block you, but if you intend to fork, vendor or contribute changes back, get clarification first.

The homepage is a Vercel Labs deployment, the repository is not archived, and the default branch is `main`. Taking all of that together, OpenReview is an interesting, well-scoped reference implementation of agentic code review on a specific cloud stack, published without a license and last touched in March 2026. That is a fine thing to study and a thing to be careful about deploying.

Editorial conclusion

OpenReview is best understood as a demonstration of Vercel's own stack rather than as a finished product, and the README says so: it was built internally to test Vercel technologies together, it is in beta, and breaking changes are expected. Read that way, the interesting parts are the durable workflow around a long-running agent, the sandbox that can actually install dependencies and run the project's linters instead of guessing, and the reaction loop that lets a human approve or reject a suggestion without reading a wall of text. Two things give me pause. The agent can commit and push to your branch, so the trust boundary is a prompt plus a GitHub App with contents set to read and write, and that combination deserves a hard look before you install it on a repository that matters. And GitHub reports no license for this repository, with no license file in the tree, so the open-source framing in the description is not matched by a license grant. It was last pushed on 2026-03-06.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. vercel-labs/openreview on GitHub