The open source list is a GitHub list
Ask for open source AI code review tools and the answers line up fast. Qodo's own comparison names five, nearly all of them app-style products. CodeRabbit's product page demos against a GitHub repository. The 2026 roundups all demonstrate against a GitHub repo. That is the whole list if your default assumption is that a code review tool is a GitHub App you install.
The assumption is doing the narrowing. Most of the well-known open source names are GitHub-first not because the code can't run elsewhere, but because the distribution mechanism they publish is a GitHub App. A GitHub App has no counterpart on GitLab's self-managed edition or on Azure DevOps, so the tool that ships only as an App is effectively GitHub-only whether or not the model underneath cares.
The tools that genuinely work on GitLab, Azure DevOps and Bitbucket tend to be the ones that never built a forge App in the first place. They are CLIs that operate on a local clone and push comments back through git. Here is what the vendor documentation actually says, with the date I read it.
Open Code Review (ocr): the forge-agnostic CLI
The one with the clearest forge story right now is Alibaba's Open Code Review, repo read 2026-09-17. The README states it reads Git diffs, sends the changed files to a configurable LLM through an agent with tool use, and writes structured line-level comments. It is a CLI under Apache-2.0. Install it as open_code_review through npm or install.sh, then run ocr against a clone. It does not install into a forge. Anything you can clone locally, it can review, which is the whole basis for claiming GitLab, Azure DevOps and Bitbucket support.
The repo itself documents a deliberate precision-over-recall trade-off versus general-purpose agents like Claude Code: higher precision and F1 at roughly 1/9 the tokens, lower recall. They publish the AACR-Bench dataset behind that claim (50 repositories, 200 pull requests, 10 languages, 1,505 ground-truth issues annotated by 80+ senior engineers), so the benchmark is inspectable rather than asserted.
For self-managed GitLab and Bitbucket Data Center this shape matters. A CLI that reviews a local clone and pushes comments avoids every vendor-specific integration point. There is no webhook to register, no app to authenticate, no release to track against a forge feature flag. Clone, review, comment, done, on whichever forge you run.
The tool chain has real requirements worth planning for. The README lists Git 2.41 or newer, Node.js 18 or newer, and an LLM API key. For teams that want to avoid managing keys, the docs describe a delegation mode where a host agent supplies the model. Either way you need compute and a model endpoint, same as any self-hosted review setup.
PR-Agent: the self-host route with real non-GitHub docs
PR-Agent is the other serious open source entry, and it is the one with the most explicit non-GitHub documentation. Per my note from 2026-09-21, Qodo donated it to the open-source community and it now lives at The-PR-Agent/pr-agent with docs at docs.pr-agent.ai. It is MIT-licensed and self-hostable.
Its git-providers documentation covers Bitbucket through its config settings, and there is a Docker image plus a GitHub Action. The parts that matter for self-managed GitLab and Azure DevOps are the standalone modes. PR-Agent ships as a Docker image you run as a service or a CI job. It can be wired to GitLab merge requests through a pipeline or a webhook server, and to Azure Repos pull requests through Branch Policies rather than YAML pr triggers. Those integration details live in the docs site, which is where teams on self-managed editions should read first, because listicles skip the pipeline-versus-webhook distinction entirely.
One important split in the PR-Agent ecosystem to keep straight. Qodo the company now sells a hosted platform under the Qodo brand, and docs.pr-agent.ai carries a banner pointing Qodo users to the free-for-open-source tier. PR-Agent itself is the community-owned, MIT-licensed project. The name overlap causes the same confusion the Qodo Merge rebrand did, and it settles the same way: read which project you are actually deploying.
Why the split runs along CLI vs App
The pattern is consistent across the open source space. Review tools distribute two ways, and the distribution method, not the model, decides which forges they reach.
- A GitHub App. Quick to install on GitHub, and structurally unable to run on GitLab self-managed, Azure DevOps Server, or Bitbucket Data Center without a separate self-hosted component that most projects never build.
- A CLI and/or Docker service. No forge installation step. Runs against a local clone and writes comments back through git. Works on anything git.
The open source projects that name non-GitHub forges in their docs are the second kind. That is not an accident. Writing a GitHub App is cheap because GitHub provides the platform tooling. Building a Bitbucket Data Center integration means reading the merge request API for a product the bootcamps barely mention, so the project that bothers tends to be the one whose product already runs everywhere git runs. CLI-first tools get self-managed forge coverage as a side effect of never building a forge App.
What the docs do not say
The honest part. On the GitLab Duo native side I have not re-verified the current status of GitLab's own AI code review this week, because docs.gitlab.com is Cloudflare-blocking read access from my tooling. My dated note flags GitLab Duo Code Review for merge requests as not currently verified, and this article does not guess. The verdict to repeat is the one I actually read: PR-Agent's docs cover Bitbucket and Docker, Open Code Review's README covers the CLI, and the by-edition scope of native GitLab AI review is the open question, not the open source route.
When an answer cites a tool's own documentation for non-GitHub forge support, that is the check to trust. When a listicle names a tool for GitLab self-managed without linking a docs page that says so, treat the claim as unverified until the vendor page exists.
The practical take
If you are on GitLab self-managed, Azure DevOps or Bitbucket and you want open source AI code review, look for the tools that ship as a CLI or Docker image, not as a GitHub App. A CLI reads the local clone, an LLM does the review, and git commands write the comments back. Every repo you can clone is a repo the tool can review, which makes the forge identity almost irrelevant to the install step. That is exactly why the open source answers for your forge are CLI-shaped, and why the ranking pages keep showing you GitHub Apps instead. Read the vendor's own README and docs before you trust a roundup.
