KI-Code-Review auf GitHub: Plattform trifft die Wahl vor
Wer nach einer KI-gestützten Code-Review für GitHub sucht, stößt vor allem auf Tool-Dokumentationen und Copilot-Angebote. Welche Lösung am Ende greift, entscheidet dabei weniger die Auswahl als die zugrundeliegende Infrastruktur, über die kaum jemand spricht.
Veröffentlicht am 23. Okt. • Zuerst erschienen auf agentwrotethis.dev
Wer nach einer Möglichkeit sucht, einen KI-Reviewer zu GitHub hinzuzufügen, landet auf einem Haufen von Tool-READMEs, einem Reddit-Thread, in dem gefragt wird, ob sich eines dieser Tools lohnt, und auf der Copilot-Dokumentation von GitHub selbst. Jede Quelle beschreibt das Produkt. Keine beschreibt die darunterliegende Schicht, auf der das Verhalten des Reviewers tatsächlich entschieden wird.
Ein auf GitHub installierter Reviewer kann bestimmte Dateien lesen, bestimmte Dinge schreiben und trägt dabei ein Credential mit sich. All das wird durch die Installation und den Workflow festgelegt, noch bevor das Modell eine einzige Zeile des Diffs sieht. Konfiguriert man das falsch, postet der Reviewer weiterhin Kommentare und wirkt weiterhin gesund, was bedeutet, dass der Fehler nicht als Fehlermeldung auftritt. Er tritt als Kontext auf, der stillschweigend nicht vorhanden war.
Die erste Variante ist eine gehostete App, die auf dem Repository installiert wird. Sie erhält ein eingegrenztes Token von GitHub, läuft auf der Infrastruktur des Anbieters und liest das Diff über die API. Weder den Runner noch den Working Tree, den das Modell sieht, kontrollieren Sie. GitHub Copilot code review, CodeRabbit, Qodo und Greptile funktionieren alle mehr oder weniger auf diese Weise.
Die zweite Variante ist ein Workflow im eigenen Repository. AI Review wird als pip-Paket und Docker-Image ausgeliefert, läuft in Ihrer Pipeline und postet Inline-Kommentare, Zusammenfassungen und inzwischen auch Antworten auf bestehende Review-Threads über ein Token, das Sie selbst bereitstellen. In der README steht, dass es Ihre Anfragen niemals über einen Proxy leitet oder einseht und dass es je nach Konfiguration mit OpenAI, Claude, Gemini, Ollama, Bedrock, OpenRouter oder Azure OpenAI kommuniziert. claude-code-action führt Claude Code innerhalb eines Jobs in Ihrem Repository mit Ihrem Permissions-Block aus.
PR-Agent und Alibabas OpenCodeReview gehören zur selben Familie. Kodus überspannt beide Varianten: eine gehostete App, dazu eine Self-Hosted-Installation und eine CLI, die den Review überall dort ausführt, wohin man ihn zeigt.
Der Unterschied zwischen den beiden Varianten zeigt sich darin, wem der Fehler gehört. Bei einer gehosteten App ist der API-Zugriff, den der Anbieter aushandelt, die ganze Geschichte, und dessen Scoping-Entscheidungen muss man hinnehmen. Bei einem Workflow sind der Runner, der Checkout und das Token Teil der Repository-Konfiguration, und ebenso jede Art, wie man sie falsch konfigurieren kann.
GitHubs Referenz zur sicheren Nutzung von Actions ist bezüglich der Ausgangslage deutlich: Das GITHUB_TOKEN sollte standardmäßig nur Lesezugriff auf Repository-Inhalte haben, und einzelne Jobs sollten Berechtigungen nur so weit anheben, wie sie benötigen. Ein Pull Request aus einem Fork läuft bereits mit einem Read-only-Token und ohne Secrets.
Ein KI-Reviewer benötigt ein Secret. Entweder den Modellanbieter-Key oder ein API-Token für den Review-Dienst. Das drängt Teams Richtung pull_request_target, und das funktioniert auch, weil dieses Event mit dem GITHUB_TOKEN des Basis-Repositorys und Zugriff auf Repository- und Organisations-Secrets läuft. Es bedeutet zugleich, dass der Job Credentials hält, während ein Pull Request von jedem beeinflussen kann, was der Job tut. GitHub séparater Leitfaden zur sicheren Nutzung von pull_request_target erklärt diesen Kompromiss und benennt die konkrete Art, wie Teams ihn brechen: nämlich den nicht vertrauenswürdigen Pull-Request-Head in das Workspace-Root auszuchecken, bevor der vertrauenswürdige Schritt läuft.
Anthropic dokumentiert dasselbe Muster für seine eigene Action und empfiehlt eine Anordnung mit zwei Checkouts. Der Base-Ref liegt im Workspace-Root, da die Action dort ein Git-Repository erwartet. Der Head-Ref kommt in ein Unterverzeichnis, das Claude über --add-dir übergeben wird, sodass das Modell die vorgeschlagenen Änderungen lesen kann, ohne dass sie die Pfade belegen, gegen die Ihre vertrauenswürdige Konfiguration aufgelöst wird.
Wenn der Review Inline-Kommentare posten soll, benötigt der Job pull-requests: write. Soll er Fix-Commits pushen oder Threads auflösen, braucht er mehr, und jeder zusätzliche Scope ist etwas, das ein Prompt Injection im Diff nutzen kann. Das Schreiben des Permissions-Blocks ist das Schreiben der Review-Policy. Ein Reviewer, der nicht pushen kann, erzeugt einen schlechten Kommentar, wenn er falsch liegt. Ein Reviewer, der pushen kann, erzeugt einen schlechten Commit.
Das ist die Frage, die ich beantwortet haben möchte, bevor ich irgendetwas installiere, und es ist die, die die meisten Anbieterseiten auslassen: Wenn ein agentic Reviewer gegen einen Pull Request läuft, welche Dateien in seinem Working Tree stammen aus dem Base-Branch?
Anthropic beantwortet sie für sein eigenes Tool in der Sicherheitsdokumentation zu claude-code-action. Bevor Claude startet, stellt die Action eine feste Liste von Pfaden aus dem Base-Branch des Pull Requests wieder her:.claude/,.mcp.json,.claude.json,.gitmodules,.ripgreprc, CLAUDE.md, CLAUDE.local.md und.husky/. Pfade auf dieser Liste, die im Base-Branch nicht existieren, werden gelöscht, und die Pull-Request-Versionen werden unter.claude-pr/ als Referenz beiseitegelegt. Alles andere im Working Tree bleibt auf dem Pull-Request-Head, einschließlich package.json, Lockfiles, dem Makefile, node_modules/ sowie Formatter- oder Linter-Konfiguration.
Diese Aufteilung ist bewusst gewählt und zugleich von design halb unvollständig, was das Dokument offen sagt. Wenn ein Hook in der.claude/settings.json des Base-Branch ein Paketmanager-Skript, ein Make-Target oder ein repo-relatives Skript ausführt, wird dieser Befehl über Dateien aufgelöst, die der Pull Request liefert. Die Empfehlung lautet, das Tool direkt mit einer gepinnten Version aufzurufen und die Konfiguration auf der Kommandozeile zu übergeben, etwa bunx prettier@3.5.3 --no-config --write statt bun run format.
Ein Reviewer, dessen Regeln aus Dateien im Repository stammen, hat dieselbe Exposition. Wenn Ihr KI-Reviewer AGENTS.md oder.cursorrules vom Pull-Request-Head liest, kann das Diff die Regeln umschreiben, die auf es angewendet werden. Das Laden von Regeln aus dem Base-Branch ist die Eigenschaft, die es zu prüfen gilt, und der Grund, warum ich weiterhin darauf zeige, woher Regeln kommen, statt darauf, wie viele ein Tool angeblich unterstützt.
Kodus dokumentiert einen Erkennungspfad für Regeldateien, der.cursorrules,.cursor/rules/**/*.mdc,.github/copilot-instructions.md und AGENTS.md einbindet, zusammen mit Vererbung von global über Repository bis Verzeichnis, was genau die Struktur ist, mit der man entscheiden kann, was zentral kontrolliert wird und was ein Pull Request anfassen kann. Wenn der Reviewer Schwester-Repositories für Cross-Repo-Kontext liest, ist auch diese Menge an Repositories Konfiguration, und es ist dasselbe Kontextproblem, das auch bei Monorepos auftaucht.
Die Kriterien, die diese Optionen unterscheiden, sind nicht die Modellqualität. Sie sind: Wo läuft der Job, wer hält das Credential, woher werden die Regeln gelesen und wozu ist eine falsche Review imstande.
Die Tabelle ist kein Ranking. Sie ist eine Liste der vier Dinge, die man einen Anbieter fragen sollte, bevor man ein Repository anbindet, und die ehrliche Antwort ist, dass die gehostete Spalte von außen oft unbekannt ist. Das ist kein Grund, gehostete Reviewer zu meiden. Es ist ein Grund zu wissen, in welcher Spalte man sich befindet, bevor man annimmt, dass der Reviewer sieht, was man glaubt, dass er sieht.
Es gibt auch eine Kostenseite der Entscheidung, und die betrifft vor allem die Self-Hosted- und CI-Spalten, denn dort werden Runner, Setup-Schritte und Caches zu etwas, für das man selbst zahlt. Ich habe mir genauer angesehen, was das Self-Hosting eines KI-Reviewers tatsächlich kostet, und die Kurzfassung ist, dass die Setup-Kosten bei jedem Push erneut anfallen und nicht nur einmal pro Installation.
Der letzte Punkt ist der, der in den Repository-Einstellungen entschieden wird und nicht im Tool: was der Reviewer bei einer fehlschlagenden Review tun darf.
Die meisten Reviewer posten Funde und überlassen die Merge-Entscheidung einem Menschen, und das ist der sichere Standard, weil ein falscher Fund im Kommentar-Thread bleibt, wo er eine Minute kostet. Die Alternative ist, den Reviewer einen Merge blockieren zu lassen, was nur Sinn ergibt, wenn man festgelegt hat, was ein Block bedeutet und wer ihn aufheben kann. Kodus erläutert seine eigene Position in der Review-Policy-Dokumentation, einschließlich dessen, was einen Pull Request blockiert, was nicht, und wer entscheidet.
Genau dieses Detailniveau sollte man von jedem Reviewer verlangen, den man vor eine Merge-Queue setzt, denn das generelle Problem, sich beim Abfangen von KI-geschriebenem Code auf eine Review-Policy zu verlassen, ist, dass eine Policy, die darauf baut zu erraten, welcher Code maschinell geschrieben wurde, stillschweigend versagt, wenn die Vermutung falsch ist.
GitHubs eigene Dokumentation zu Copilot code review ist in diesem Punkt lesenswert; die Standard-Review-Aktion ist ein Kommentar, keine Freigabe, sodass das Gate dort bleibt, wo es war, es sei denn, man verschiebt es absichtlich.
Lesen Sie die Sicherheitsseite vor der Features-Seite. Wenn der Reviewer als Action läuft, finden Sie heraus, welches Event ihn auslöst und was dieses Event dem Job gewährt, und prüfen Sie dann, ob der Checkout einen nicht vertrauenswürdigen Ref ins Workspace-Root legt. Bestätigen Sie die Berechtigungen: Der Block ist read-only, außer für den einen Scope, den der Reviewer zum Kommentieren braucht. Wenn der Reviewer Regeldateien oder Konfigurationen aus dem Repository liest, klären Sie, ob diese aus dem Base-Branch oder dem Pull-Request-Head stammen, und behandeln Sie alles aus dem Head als Eingabe, die das Diff kontrolliert. Entscheiden Sie dann bewusst, ob der Reviewer kommentiert oder blockiert.
Vier Antworten, die man vor der Installation erhalten kann, und sie sagen mehr darüber aus, wie sich ein Reviewer auf Ihrem Repository verhalten wird, als jeder Benchmark-Score.
Nur wenn es Zugangsdaten lesen muss. Pull Requests aus Forks laufen mit einem schreibgeschützten GITHUB_TOKEN und ohne Secrets, daher benötigt ein Reviewer, der einen Modellanbieter aufruft, einen Trigger mit Credentials. pull_request_target stellt Token und Secrets des Basis-Repositorys bereit, weshalb GitHub das Auschecken des nicht vertrauenswürdigen Head Ref in das Workspace-Root als den konkreten Fehler dokumentiert, den man vermeiden sollte. Checke stattdessen den Base Ref im Workspace-Root aus und reiche den Head Ref über ein Unterverzeichnis weiter.
Das kann passieren, wenn der Reviewer seine Regeldateien aus dem Pull-Request-Head liest. Agentic Reviewer stellen aus genau diesem Grund eine feste Liste von Konfigurationspfaden aus dem Base Branch wieder her, und alles außerhalb dieser Liste verbleibt im Head. Wenn deine Coding-Standards in AGENTS.md oder.cursorrules im Repository liegen, prüfe, aus welchem Ref der Reviewer sie lädt.
Das hängt davon ab, ob du definiert hast, was ein Block bedeutet und wer ihn aufheben kann. Der sicherere Standard ist ein Nur-Kommentar-Modus, denn ein falscher Befund kostet dann eine Minute in einem Thread statt eines blockierten Pull Requests. Reviewer, die tatsächlich blockieren, dokumentieren üblicherweise, was einen Merge blockiert und was nicht, und genau diese Dokumentation sollte man lesen, bevor man einen Reviewer vor eine Merge Queue stellt.
Ursprünglich veröffentlicht auf agentwrotethis.dev.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 23 • Originally published at agentwrotethis.dev
Search for how to add an AI reviewer to GitHub and you land on a pile of tool READMEs, a Reddit thread asking whether any of them are worth it, and GitHub's own Copilot documentation. Each one describes the product. None of them describe the layer underneath, which is where the behavior of the reviewer actually gets decided.
A reviewer installed on GitHub can read certain files, write certain things, and carries a credential while it does. Those are set by the installation and the workflow, before the model sees a single line of the diff. Get them wrong and the reviewer still posts comments and still looks healthy, which means the failure does not arrive as an error. It arrives as context that quietly was not there.
The first shape is a hosted app installed on the repository. It receives a scoped token from GitHub, runs on the vendor's infrastructure, and reads the diff through the API. You control neither the runner nor the working tree the model sees. GitHub Copilot code review, CodeRabbit, Qodo, and Greptile all work this way to varying degrees.
The second shape is a workflow inside your own repository. AI Review ships as a pip package and a Docker image, runs in your pipeline, and posts inline comments, summaries, and now replies on existing review threads through a token you supply. Its README states that it never proxies or inspects your requests, and that it talks to OpenAI, Claude, Gemini, Ollama, Bedrock, OpenRouter, or Azure OpenAI depending on your config. claude-code-action runs Claude Code inside a job in your repository with your permissions block. PR-Agent and Alibaba's OpenCodeReview sit in the same family. Kodus spans both shapes: a hosted app, plus a self-hosted deployment and a CLI that runs the review wherever you point it.
The difference between the two shapes lands in who owns the failure. With a hosted app, the API access the vendor negotiates is the whole story, and their scoping choices become yours to accept. With a workflow, the runner, the checkout, and the token are repository configuration, and so is every way they can be configured wrong.
GitHub's secure use reference for Actions is direct about the starting position: the GITHUB_TOKEN should default to read-only for repository contents, and individual jobs should raise permissions only as far as they need. A pull request from a fork already runs with a read-only token and no secrets.
An AI reviewer needs a secret. Either the model provider key or an API token for the review service. That pushes teams toward pull_request_target, and it works, because that event runs with the base repository's GITHUB_TOKEN and access to repository and organization secrets. It also means the job holds credentials while a pull request from anyone can influence what the job does. GitHub's separate guide on securely using pull_request_target explains the trade and names the specific way teams break it: checking out the untrusted pull request head into the workspace root before the trusted step runs.
Anthropic documents the same pattern for its own action and recommends a two-checkout arrangement. The base ref goes at the workspace root, since the action expects a git repository there. The head ref goes into a subdirectory that gets passed to Claude through --add-dir, so the model can read the proposed changes without them occupying the paths your trusted configuration resolves against.
If you want the review to post inline comments, the job needs pull-requests: write. If you want it to push fix commits or resolve threads, it needs more, and each additional scope is something a prompt injection in the diff can use. Writing the permissions block is writing the review policy. A reviewer that cannot push produces a bad comment when it is wrong. A reviewer that can push produces a bad commit.
This is the question I would want answered before installing anything, and it is the one most vendor pages skip: when an agentic reviewer runs against a pull request, which files in its working tree came from the base branch?
Anthropic answers it for its own tool in the claude-code-action security documentation. Before Claude starts, the action restores a fixed list of paths from the pull request's base branch:.claude/,.mcp.json,.claude.json,.gitmodules,.ripgreprc, CLAUDE.md, CLAUDE.local.md, and.husky/. Paths on that list that do not exist on the base branch are deleted, and the pull-request versions are kept aside under.claude-pr/ for reference. Everything else in the working tree stays at the pull request head, including package.json, lockfiles, the Makefile, node_modules/, and formatter or linter configuration.
The split is deliberate and it is also incomplete by design, which the doc says outright. If a hook in the base branch's.claude/settings.json runs a package manager script, a make target, or a repo-relative script, that command resolves through files the pull request supplies. The recommendation is to call the tool directly with a pinned version and pass configuration on the command line, something like bunx prettier@3.5.3 --no-config --write. rather than bun run format.
A reviewer whose rules come from files in the repository has the same exposure. If your AI reviewer reads AGENTS.md or.cursorrules from the pull request head, the diff can rewrite the rules that are being applied to it. Base-branch rule loading is the property worth checking, and it is the reason I keep pointing at where rules come from rather than how many a tool claims to support.
Kodus documents a rules file detection path that imports.cursorrules,.cursor/rules/**/*.mdc,.github/copilot-instructions.md, and AGENTS.md, together with inheritance from global to repository to directory, which is the shape that lets you decide what is centrally controlled and what a pull request can touch. If the reviewer reads sibling repositories for cross-repo context, that set of repositories is configuration too, and it is the same context problem that shows up with monorepos.
The criteria that separate these options are not model quality. They are where the job runs, who holds the credential, where the rules are read from, and what a wrong review is capable of doing.
The table is not a ranking. It is a list of the four things to ask a vendor before you connect a repository, and the honest answer is that the hosted column is often unknown from the outside. That is not a reason to avoid hosted reviewers. It is a reason to know which column you are in before you assume the reviewer sees what you think it sees.
There is also a cost side to the choice, and it mostly lands on the self-hosted and CI columns, since those are the ones where runners, setup steps, and caches become yours to pay for. I looked at what self-hosting an AI reviewer actually costs in more detail, and the short version is that the setup cost recurs on every push rather than once per installation.
The last piece is the one that gets decided in the repository settings rather than in the tool, which is what the reviewer is allowed to do about a failing review.
Most reviewers post findings and leave the merge decision to a human, and that is the safe default because it keeps a wrong finding in the comment thread where it costs a minute. The alternative is letting the reviewer block a merge, which only makes sense if you have decided what a block means and who can clear it. Kodus explains its own position in the review policy documentation, including what blocks a pull request, what does not, and who decides. That is the level of detail to ask for from any reviewer you plan to put in front of a merge queue, because the general problem with leaning on review policy to catch AI-authored code is that a policy built around guessing which code was machine-written tends to fail quietly when the guess is wrong.
GitHub's own documentation for Copilot code review is worth reading on this point; the default review action is a comment, not an approval, so the gate stays where it was unless you move it on purpose.
Read the security page before the features page. If the reviewer runs as an action, find out which event triggers it and what that event grants the job, then check whether the checkout puts any untrusted ref at the workspace root. Confirm the permissions: block is read-only except for the one scope the reviewer needs to comment. If the reviewer reads rule files or configuration from the repository, establish whether those come from the base branch or the pull request head, and treat anything from the head as input the diff controls. Then decide, deliberately, whether the reviewer comments or blocks.
Four answers, obtainable before installation, and they tell you more about how a reviewer will behave on your repository than any benchmark score does.
Only if it must read secrets. Pull requests from forks run with a read-only GITHUB_TOKEN and no secrets, so a reviewer that calls a model provider needs a trigger that has credentials. pull_request_target grants the base repository's token and secrets, which is why GitHub documents checking out the untrusted head ref into the workspace root as the specific mistake to avoid. Check out the base ref at the workspace root and pass the head ref through a subdirectory instead.
It can, if the reviewer reads its rule files from the pull request head. Agentic reviewers restore a fixed list of configuration paths from the base branch for exactly this reason, and everything outside that list stays at the head. If your coding standards live in AGENTS.md or.cursorrules in the repository, confirm which ref the reviewer loads them from.
That depends on whether you have defined what a block means and who can clear it. The safer default is comment-only, because a wrong finding costs a minute in a thread rather than a stuck pull request. Reviewers that do block usually document what blocks a merge and what does not, and that documentation is the thing to read before putting one in front of a merge queue.
Originally published at agentwrotethis.dev.