Claude Code GitHub Actions: Code-Reviews gezielt automatisieren

Der eigentliche Gewinn liegt darin, wer während der Arbeit verfügbar bleiben muss. Bisher musste ein Entwickler das Repository öffnen, Claude starten, das Ergebnis zurück nach GitHub übertragen und die lokale Sitzung am Laufen halten. Mit einer Action hinterlässt ein Maintainer einen klar begrenzten Auftrag und findet später einen Kommentar oder einen Änderungsvorschlag vor. Die Arbeit kann auch außerhalb seiner Arbeitszeit beginnen. Die Zeit für die Prüfung des Ergebnisses muss das Team weiterhin einplanen.

Diese Anleitung stützt sich auf die aktuelle Dokumentation von Anthropic, geprüft am 15. Oktober 2026. Der folgende Workflow ist bewusst eng begrenzt und als Einstieg gedacht. Er soll nicht den Eindruck erwecken, jedes Issue lasse sich unbeaufsichtigt lösen.

Claude Code GitHub Actions: Unterstützung auf Abruf

Die GitHub App lässt sich als Zugangsausweis verstehen, der Workflow als Arbeitsauftrag und der Runner als vorübergehend bereitgestellter Arbeitsplatz. Ein Workflow ist die Konfigurationsdatei, die GitHub vorgibt, wann die Arbeit beginnt. Der Runner ist der Rechner, der sie ausführt.

Die Action kann auf Erwähnungen in Issues und Pull Requests reagieren. Mit einem vorgegebenen prompt wird daraus ein automatisierter Auftrag. Für kleine Teams sind ausdrückliche Anfragen der einfachste Weg, sinnvolle Aufgaben zu finden, bevor sie für die Prüfung jeder Änderung bezahlen. Verwendung der Action.

Einmal installieren und den Workflow zusammenführen

Für die geführte Installation werden Administratorrechte im Repository benötigt. Zuerst die installierte GitHub CLI mit gh auth login authentifizieren, dann claude im Repository öffnen und /install-github-app ausführen. Anschließend die Workflows sowie die Authentifizierung per API-Schlüssel oder Abonnement auswählen und den vorbereiteten Workflow-PR erstellen und zusammenführen. Die Installation erfolgt lokal; spätere Aufträge laufen auf GitHub. Offizielle Kurzanleitung.

Die manuelle Einrichtung führt zum selben Ergebnis:

1. Die Claude GitHub App im ausgewählten Repository installieren.
2. Im Repository Settings → Secrets and variables → Actions öffnen und eines der Authentifizierungs-Secrets aus der folgenden Tabelle anlegen.
3. Das funktionsfähige Beispiel von Anthropic nach .github/workflows/claude.yml kopieren, den passenden Authentifizierungsparameter auswählen und die Datei zusammenführen.
4. Einen Kommentar mit @claude und einem konkreten Auftrag hinterlassen.

Das sind die offiziellen Schritte zur manuellen Einrichtung, ergänzt um die ausdrückliche Wahl des Authentifizierungsnachweises. Einrichtungsanleitung der Action.

Für die Nutzung eines Abonnements wird lokal claude setup-token ausgeführt und dessen Ausgabe als Secret gespeichert. Anthropic dokumentiert diesen Weg für die Tarife Pro, Max, Team und Enterprise. Das erzeugte Token gilt ein Jahr; die Zuständigkeit für seine Erneuerung sollte deshalb feststehen. Authentifizierung per Token.

Der Authentifizierungsnachweis bestimmt die Abrechnung: Läufe mit API-Schlüssel werden über die API abgerechnet. Läufe mit OAuth-Token nutzen stattdessen das Claude-Abonnement. Die Nutzung der GitHub-Actions-Runner wird separat erfasst. Ein Abonnement-Token gehört der Person, die es erstellt hat. Für Secrets, die über mehrere Repositories hinweg gemeinsam genutzt werden, empfiehlt Anthropic einen API-Schlüssel. Authentifizierung und Kosten.

Für die Standardeinrichtung mit der App ist kein persönliches GitHub-Zugriffstoken erforderlich. Der GitHub-Zugriff und die Claude-Authentifizierung sind getrennt: Den Zugriff stellt die App bereit, die Authentifizierung übernimmt das gewählte Secret. Authentifizierungsparameter.

Mit einem kleinen Workflow auf Zuruf beginnen

Dieses Profil eignet sich für vertrauenswürdige Team-Repositories und kleine Dateiänderungen. Es kann Dateien lesen, bearbeiten und Änderungen über die GitHub API committen. Claude erhält dabei kein Shell-Tool und kann in diesem Profil daher keine Testbefehle ausführen. Für die Tests bleibt die normale CI zuständig, also die automatisierten Prüfungen vorgeschlagener Änderungen.

Die folgende Konfiguration wird als .github/workflows/claude.yml gespeichert. Die Action-Referenzen actions/checkout@v6 und anthropics/claude-code-action@v1 stammen aus dem aktuellen Beispiel von Anthropic. Die Begrenzung auf fünf Arbeitsrunden und das Zeitlimit von fünfzehn Minuten sind hier gewählte Startwerte, keine Standardeinstellungen von Anthropic. Offizieller Workflow.

name: Claude on request
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    timeout-minutes: 15
    concurrency:
      group: claude-small-team
      cancel-in-progress: false
    permissions:
      contents: write
      issues: write
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          use_commit_signing: true
          claude_args: |
            --max-turns 5
            --tools "Read,Glob,Grep,Edit,Write"
            --disallowedTools "Bash,WebFetch,WebSearch"

Für die Abrechnung über ein Abonnement wird die Zeile mit anthropic_api_key durch claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }} ersetzt. Es wird nur eine der beiden Varianten angegeben. id-token: write bleibt erhalten, da die standardmäßige Authentifizierung über die GitHub App diese Berechtigung benötigt. Offizieller Workflow und Authentifizierung, Referenz der Eingabeparameter.

Die einzelnen Einstellungen erfüllen unterschiedliche Aufgaben:

• --tools legt fest, welche integrierten Tools Claude verwenden kann. Read, Glob und Grep dienen zur Untersuchung von Dateien; Edit und Write ändern sie. MCP-Tools werden dadurch nicht eingeschränkt. Das sind separat angebundene Tools, über die die Action mit GitHub kommuniziert.
• --allowedTools erlaubt die Nutzung benannter Tools ohne Rückfrage. Der Parameter ist keine vollständige Liste aller zugelassenen Tools. Die ausdrückliche Angabe von --disallowedTools sperrt in diesem Beispiel Shell- und Web-Tools.
• --max-turns begrenzt die Arbeitsrunden des Agenten. Der Parameter setzt weder ein Token- noch ein Dollar-Limit. Ist die Grenze erreicht, kann der Lauf mit einem Fehler enden, obwohl die Arbeit noch nicht abgeschlossen ist. CLI-Referenz.

Mit use_commit_signing: true erfolgen Commits über die GitHub API. Dadurch kann dieses Profil Änderungen speichern, ohne Claude git-Befehle über eine Shell zu erlauben. Ein zusätzliches Secret zum Signieren ist nicht erforderlich. Die GitHub-Tools der Action bleiben verfügbar; das Profil besitzt also Schreibzugriff. Signieren von Commits, Implementierung der Action.

Die feste Concurrency-Gruppe erlaubt pro Repository jeweils einen laufenden Job dieses Workflows. Beim standardmäßigen Verhalten der Warteschlange kann eine neue wartende Anfrage eine ältere wartende Anfrage ersetzen. Es handelt sich also nicht um eine verlässliche Aufgabenwarteschlange. Das Zeitlimit begrenzt die verstrichene Laufzeit des Jobs einschließlich der Einrichtung. Parallelität in GitHub Actions, Workflow-Syntax.

Als erster Test eignet sich @claude review this PR for missing permission checks; report findings without changing files. Für ein Issue bietet sich @claude fix the null handling described above, change only the parser and its regression test, and state which checks were not run an.

Standardmäßig benötigt die auslösende Person Schreibzugriff auf das Repository; Bots sind gesperrt. Bei einer Fehlerbehebung zu einem Issue ist ein Branch mit einem Link zu erwarten, über den ein Mensch den PR erstellt. Dieser Unterschied sollte in den Anweisungen des Teams festgehalten werden. Sicherheit der Action.

Nach der Erprobung automatische PR-Reviews ergänzen

Für automatische PR-Reviews wird bei der Einrichtung mit /install-github-app der Review-Workflow ausgewählt. Dessen Plugin zur Codeprüfung verwendet --comment und die unten gezeigte Freigabe des Kommentar-Tools, um Befunde zu veröffentlichen. Offizielles Review-Beispiel.

Im separaten Review-Workflow gehören diese Eingabeparameter zur Action:

plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
plugins: "code-review@claude-code-plugins"
prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
claude_args: >-
  --max-turns 5
  --allowedTools "mcp__github_inline_comment__create_inline_comment"

Diese Parameter gehören in den offiziellen pull_request-Workflow, nicht in den oben gezeigten Workflow für Erwähnungen. Checkout, Authentifizierung und Job-Berechtigungen bleiben erhalten. Zusätzlich erhält der Job ein Zeitlimit; PRs aus Forks werden mit if: github.event.pull_request.head.repo.full_name == github.repository übersprungen. Die Begrenzung der Arbeitsrunden ist eine Einstellung für den Pilotbetrieb: Ein Review, dem die Runden ausgehen, ist unvollständig. Der dokumentierte Review-Skill überspringt außerdem bestimmte PRs, darunter Entwürfe.

Installationsumfang und Tool-Zugriff getrennt begrenzen

Die App sollte zunächst nur in ausgewählten Repositories installiert werden. Die offizielle Claude App nutzt ihre Berechtigungen für mehrere Claude-Funktionen gemeinsam. GitHub erlaubt es nicht, nur einen Teil dieses Berechtigungssatzes zu akzeptieren. Ein kleiner permissions-Block im YAML verkleinert den Umfang der App-Installation nicht. Berechtigungsmodell der App.

Ist dieser Installationsumfang zu groß, lässt sich eine eigene App mit Zugriff auf Contents, Issues und Pull requests einrichten. Dafür kommen die Secrets APP_ID und APP_PRIVATE_KEY hinzu, außerdem ein Schritt, der ein App-Token erzeugt und als github_token übergibt. Für Teams, die statische Claude API-Schlüssel ablösen möchten, beschreibt die Einrichtungsanleitung auch Workload Identity Federation. Dabei wird die Identität des GitHub-Jobs gegen kurzlebigen API-Zugriff eingetauscht. Eigene App und Föderation einrichten.

Eine knappe CLAUDE.md hält Review-Prioritäten, zulässige Änderungsbereiche und die erforderlichen Nachweise für eine Fehlerbehebung fest. Anweisungen lenken die Arbeit; Repository-Berechtigungen und Tool-Beschränkungen setzen Zugriffsgrenzen durch. Vor unbeaufsichtigten Läufen sollten konfigurierte Hooks – also bei Ereignissen im Lebenszyklus automatisch ausgeführte Befehle – und zusätzliche Tool-Server geprüft werden. Projektanweisungen. Unser Testbericht zu Claude Code hilft bei der grundsätzlichen Bewertung des Tools. Die Anleitung zu Slash-Befehlen erklärt die während der Einrichtung verwendeten Befehle.

Sechs sinnvolle Aufgaben in der richtigen Reihenfolge

Der Einstieg gelingt mit Aufträgen, die sich leicht beschreiben lassen und deren Ergebnisse einfach zu prüfen sind. Die folgenden Abläufe sind Vorschläge, keine gemessenen Einsparungen oder Garantien.

Das Einstiegsprofil kann weder Abhängigkeiten installieren noch eine Testsuite ausführen. Falls eine Aufgabe das erfordert, braucht es ein separat geprüftes Ausführungsprofil für vertrauenswürdigen Code, mit gezielten Befehlsfreigaben und eigenen Grenzen. Auch ein erlaubter Testbefehl führt Repository-Code aus. Ein harmlos klingender Name macht diesen Code nicht sicher.

Diese Fehler beheben, bevor weitere Auslöser hinzukommen

PRs aus Forks können ohne Zugriff auf Secrets laufen. GitHub gibt Secrets normalerweise nicht an durch Forks ausgelöste Läufe von pull_request und pull_request_review_comment weiter. Bleibt der Claude-Authentifizierungsnachweis in solchen Jobs leer, greift eine Vertrauensgrenze. Nur um an Secrets zu gelangen, sollte man nicht auf pull_request_target wechseln und den Code des Forks ausführen. Auch ein von einem Maintainer ausgelöster issue_comment-Job kann Secrets erhalten. Eine vertrauenswürdige Person im Kommentarverlauf macht die Dateien des PRs daher nicht vertrauenswürdig. GitHubs Sicherheitshinweise zu Forks.

Tool-Grenzen machen Startcode des Projekts nicht unschädlich. Die Action stellt ausgewählte Claude-Konfigurationen aus dem Basisbranch wieder her. Skripte und andere Projektdateien können jedoch weiterhin aus dem PR stammen. Neben den für Claude erlaubten Tools müssen deshalb auch Hooks und die Konfiguration der Tool-Server geprüft werden. Vertrauensgrenzen der Action.

Die Runner-Laufzeit bleibt eine eigene Begrenzung. Standardmäßige, von GitHub gehostete Runner sind für öffentliche Repositories kostenlos. Bei privaten Repositories gelten tarifabhängige Kontingente und kostenpflichtige Überschreitungen. Ist das Kontingent erschöpft und keine Zahlungsmethode hinterlegt, können Jobs stoppen. Deshalb sollte neben der Claude-Nutzung auch die Nutzungsübersicht von Actions geprüft werden. Abrechnung von GitHub Actions.

Anfragelimits können einen korrekt eingerichteten Workflow unterbrechen. API-Limits begrenzen pro Minute sowohl Anfragen als auch Eingabe- und Ausgabetokens, also die Textbausteine, die das Modell verarbeitet. Bei einem 429 mit retry-after vor dem nächsten Versuch warten und die Zahl gleichzeitiger Jobs reduzieren. Ein 429 aufgrund der Ausgabenobergrenze einer Nutzungsstufe ohne diesen Header erfordert eine Klärung der Abrechnung oder des Limits; wiederholte Neustarts helfen hier nicht. Bei der Authentifizierung über ein Abonnement gelten weiterhin dessen Nutzungslimits. API-Anfragelimits, Claude-Nutzungslimits.

Ein stummer Bot und ein ausbleibender CI-Lauf haben unterschiedliche Ursachen. Reagiert der Bot nicht, ist zu prüfen, ob der Workflow im Standardbranch liegt, Actions aktiviert ist, das Secret zum Eingabeparameter passt und die kommentierende Person Schreibzugriff besitzt. Die Erwähnung muss vollständig @claude lauten. Bleibt die nachgelagerte CI aus, sollte geprüft werden, ob jemand die App-Authentifizierung durch github_token: ${{ secrets.GITHUB_TOKEN }} ersetzt hat. GitHub unterdrückt viele Ereignisse, die dieses Token erzeugt; außerdem erfordern manche PR-Workflows eine Freigabe. Verhalten des GitHub-Tokens.

Zwei Angebote, die sich darauf aufbauen lassen

Die stärkste Geschäftsidee ist eine betreute Review-Einrichtung für kleine Teams. Als Käufer kommt ein Entwicklungsleiter infrage, der nützliche Befunde, klare Zuständigkeiten und planbare Betriebsgrenzen sucht. Die am 15. Oktober 2026 abgerufenen Schätzungen von DataForSEO für englischsprachige Suchen in den USA weisen für „ai code review“ 1,300 Suchanfragen pro Monat aus. Das belegt Interesse, keine Kundenzahl. Eine verkäufliche erste Version könnte ein Repository einrichten, dessen Review-Prioritäten festhalten, die Befunde an früheren PRs bewerten und fortlaufend über Nutzung und Fehler berichten. Die Schwierigkeit liegt in der Ermüdung durch Fehlalarme: Dauerhafte Arbeit entsteht dadurch, die Review-Qualität bei einer sich verändernden Codebasis zu erhalten. Eine bloße Hülle um einen allgemeinen Prompt bietet wenig Anlass, dabei zu bleiben.

Für eine Agentur könnte sich ein wiederverwendbares Paket mit Review-Richtlinien für Kunden-Repositories lohnen. DataForSEO schätzt im selben Markt 590 Suchanfragen pro Monat für „ai code review tools“ und 140 für „github ai code review“. Das kleinste sinnvolle Produkt könnte einen wiederverwendbaren Workflow, kundenspezifische Vorlagen für Anweisungen, eine Dokumentation der Verantwortlichen für Zugangsdaten und Prüfungen auf fehlende Limits kombinieren. So ließen sich einheitliche Einrichtungen auch über Projektübergaben hinweg erhalten. Die Schwierigkeit: Berechtigungen und Testumgebungen unterscheiden sich von Kunde zu Kunde. Eine Vorlage bleibt nur mit Wartung und Bewertung nützlich. Die Zielgruppen dieser Suchanfragen überschneiden sich; ihre Suchvolumina dürfen daher nicht zu einer Marktgröße addiert werden.

Die passende Umgebung für die Aufgabe wählen

GitHub Actions passt, wenn die Arbeit an ein Repository-Ereignis gebunden ist und das Team Konfiguration, Berechtigungen und Protokolle zusammen mit seiner CI verwalten möchte. Eine Cloud-Sitzung eignet sich für eine einmalige Aufgabe, die sich bei geschlossenem Laptop im Browser starten und steuern lassen soll. Eine geplante Routine passt zu gespeicherten, wiederkehrenden Aufgaben wie einer nächtlichen Prüfung des Backlogs, wenn Claudes gehostete Zeitplanung und Konfiguration der Pflege von Workflow-YAML vorgezogen werden. Routinen unterstützen auch GitHub- und API-Auslöser. Allein der Bedarf an Zeitplanung zwingt also nicht zur Nutzung von Actions; Routinen befinden sich weiterhin in der Research Preview. Cloud-Sitzungen, Routinen.

Am Montag installiert der Repository-Administrator die App und führt den begrenzten Workflow zusammen. Danach erhält Claude einen bekannten Fehler und einen gezielten Review-Auftrag. Das Team vergleicht die Ausgabe mit seiner eigenen Einschätzung. Weitere Auslöser kommen erst hinzu, wenn die Ergebnisse den Aufwand für Aufmerksamkeit und Nutzung rechtfertigen.

Wer diesen Workflow für sein Team aufbauen und betreuen lassen möchte, findet hier Unterstützung bei der KI-Automatisierung.