Claude mit GitHub verbinden: Repos, Issues und PRs

Bitten Sie Claude, „dieses Repo zusammenzufassen und einen Pull Request zu öffnen, der den fehlgeschlagenen Test behebt“, und mit eingerichtetem GitHub-Connector liest es tatsächlich Ihren Code, entwirft einen Patch und pusht einen Branch mit einem PR, den Sie prüfen können. Diese Lektion zeigt die zwei Wege, über die Claude GitHub erreicht, die genau benötigten Berechtigungen und einen konkreten Summarize-then-fix-Workflow.

Zwei Wege zu GitHub: der Connector vs. der MCPMCPEin offener Standard, mit dem KI-Assistenten einheitlich und kontrolliert an die Werkzeuge und Daten des Unternehmens angebunden werden, statt jede Integration einzeln zu bauen.Vollständige Definition ansehen →-Server

Claude kommuniziert über einen von zwei Mechanismen mit GitHub, und es ist wichtig zu wissen, welchen Sie nutzen, denn die Trust- und Permission-Modelle unterscheiden sich.

Der GitHub-Connector ist die verwaltete Point-and-Click-Option in den Claude-Apps. Sie fügen ihn aus dem Connector-Verzeichnis hinzu, authentifizieren sich bei GitHub via OAuth, und Claude erhält einen kuratierten Satz an GitHub-Tools (Dateien lesen, Issues auflisten, kommentieren, PRs öffnen). Anthropic pflegt ihn. Sie betreiben nichts selbst. Was verfügbar ist, sehen Sie im Claude connectors directory.

Der GitHub-MCP-Server ist die tiefer liegende, selbst gehostete (oder remote gehostete) Option. MCP, das Model Context Protocol, ist der offene Standard, über den sich jedes Tool einem KI-Client zur Verfügung stellen kann. GitHub veröffentlicht einen offiziellen MCP-Server, und Sie verweisen Claude Code oder die Claude-Desktop-App darauf. Das gibt Ihnen feinere Kontrolle über Scopes, kann innerhalb Ihres eigenen Netzwerks laufen und stellt mehr Tools bereit als der Consumer-Connector. Spec und SDKs finden Sie unter modelcontextprotocol.io.

Daumenregel: Nutzen Sie den Connector in den Claude-Apps für alltägliche Triage und zum Lesen. Nutzen Sie den MCP-Server, wenn Sie in Claude Code arbeiten, ihn in CI brauchen oder ein fine-grained TokenTokenEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen → selbst scopen wollen.

Wo was läuft

Den MCP-Server in Claude Code einrichten

Claude Code ist der Terminal-Agent, der bereits auf Ihrem lokalen Checkout arbeitet. Mit dem GitHub-MCP-Server kommt es von Ihren lokalen Dateien ins Remote: Issues, PRs, Actions-Runs, Reviews.

Das saubersten Setup nutzt den remote GitHub-MCP-Server mit OAuth. Aus Ihrem Repo:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/

Bei der ersten Nutzung startet Claude Code einen OAuth-Flow im Browser. Die Verbindung kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen Sie jederzeit prüfen mit:

claude mcp list

Wenn Sie ein Token statt OAuth bevorzugen (in CI üblich), setzen Sie ein fine-grained Personal Access Token als Umgebungsvariable und geben es durch. Welche Berechtigungen dieses Token genau braucht, klären wir als Nächstes, denn hier vergeben die meisten zu viel.

Token-Berechtigungen: so wenig wie möglich vergeben

Das ist der Teil, den Sie richtig machen sollten. **Ein GitHub-Token, das *alles* lesen und schreiben kann, ist ein Risiko**, besonders wenn ein autonomer Agent es hält.

GitHub bietet fine-grained Personal Access Tokens, die auf bestimmte Repositories und bestimmte Berechtigungskategorien beschränkt sind. Für einen Claude-Workflow, der ein Repo liest, Issues triagiert und PRs öffnet, brauchen Sie:

• Contents: Read and write (Quelldateien lesen, Branches erstellen, Commits pushen)
• Pull requests: Read and write (PRs öffnen und aktualisieren)
• Issues: Read and write (Triage, Kommentare, Labels)
• Metadata: Read (erforderliche Basis; GitHub wählt sie automatisch)

Das ist alles. Sie brauchen kein Admin, Sie brauchen kein Workflow-Write, es sei denn, Claude bearbeitet Dateien unter .github/workflows/, und Sie sollten das Token auf das einzelne Repo beschränken, in dem Sie arbeiten, nicht auf Ihren gesamten Account.

Erstellen Sie eines unter GitHub → Settings → Developer settings → Fine-grained tokens, wählen Sie das Ziel-Repo, setzen Sie die vier Berechtigungen oben und geben Sie ihm eine kurze Ablauffrist. Dann:

export GITHUB_PERSONAL_ACCESS_TOKEN="github_pat_xxx"

Ein wichtiges mentales Modell: Der OAuth-Flow des Connectors und Ihr fine-grained Token sind die *Obergrenze* dessen, was Claude tun kann. Das Modell kann diese Scopes nicht überschreiten, egal wie es geprompted wird. Berechtigungen sind Ihre eigentliche Sicherheitskontrolle, nicht der Prompt.

Der konkrete Workflow: Repo zusammenfassen, dann PR öffnen

Hier ist das End-to-End-Beispiel, das der Einstieg versprochen hat. Angenommen, Sie sind in Claude Code in einem ausgecheckten Repo mit verbundenem GitHub-MCP-Server.

Schritt 1: Das Repository zusammenfassen

Sie brauchen keinen raffinierten Prompt. Seien Sie konkret, was „Zusammenfassung“ für Sie bedeutet:

Lies die Struktur dieses Repos, die README und die wichtigsten Entry Points. Gib mir eine Zusammenfassung in einem Absatz, was es tut, den primären Tech-Stack und die drei Bereiche, die am wahrscheinlichsten Bugs enthalten. Liste dann die offenen Issues mit dem Label bug, sortiert danach, wie umsetzbar sie erscheinen.

Claude nutzt die MCP-Tools, um Dateien aufzulisten, README und Package-Manifest zu lesen und den Issues-Endpoint aufzurufen. Da Claude Code auch Ihre lokalen Dateien hat, liest es den Quellcode direkt und nutzt den MCP-Server vor allem für den *Remote*-Zustand (Issues, PR-Liste, CI-Status). Das Ergebnis ist eine fundierte Zusammenfassung, keine Vermutung, weil der Inhalt tatsächlich in den Kontext geladen wurde.

Schritt 2: Einen Fix auswählen und entwerfen

Nehmen wir an, ein Issue lautet: *„parse_date wirft bei einem leeren String eine Exception statt None zurückzugeben.“* Sagen Sie Claude:

Reproduziere Issue #42 mit einem kurzen Test, fixe parse_date so, dass ein leerer oder nur aus Whitespace bestehender String None zurückgibt, und stelle sicher, dass die bestehenden Tests weiterhin durchlaufen.

Claude findet die Funktion, schreibt den Fix, führt Ihre Test-Suite lokal aus und iteriert, wenn etwas fehlschlägt. Das ist der Teil, den die Connector-Variante in der App schlechter beherrscht, weil sie Ihre Tests nicht *ausführen* kann. Claude Code kann es.

Schritt 3: Den Pull Request öffnen

Jetzt der GitHub-spezifische Schritt. Claude erstellt einen Branch, committet, pusht und öffnet einen PR über das Pull-Request-Tool des MCP-Servers:

Erstelle einen Branch fix/parse-date-empty, committe die Änderung mit einer klaren Message, pushe sie und öffne einen PR gegen main. Verweise in der Beschreibung auf Issue #42 und erkläre den Fix in zwei Sätzen.

Im Hintergrund entspricht das GitHub-API-Aufrufen, die das Token autorisiert hat: create-ref, create-commit und create-pull-request. Sie bekommen eine echte PR-URL zurück. Nichts wird automatisch gemergt. Sie prüfen, Ihre CI läuft, und ein Mensch genehmigt.

Wenn Sie das vollständig skriptgesteuert statt im Dialog wollen, ist die gleiche Fähigkeit über das Claude Agent SDK verfügbar, wo Sie den MCP-Server als Tool anhängen und einen verwalteten Agenten die Schleife laufen lassen. Eine minimale Tool-Anbindung sieht so aus:

from claude_agent_sdk import ClaudeSDKClient, ClaudeAgentOptions

options = ClaudeAgentOptions(
    mcp_servers={
        "github": {
            "type": "http",
            "url": "https://api.githubcopilot.com/mcp/",
            "headers": {"Authorization": "Bearer ${GITHUB_PERSONAL_ACCESS_TOKEN}"},
        }
    },
    allowed_tools=["mcp__github__create_pull_request", "mcp__github__get_issue"],
)

async with ClaudeSDKClient(options=options) as claude:
    await claude.query("Triage issue #42 and open a fix PR against main.")
    async for message in claude.receive_response():
        print(message)

Beachten Sie allowed_tools: Selbst mit verbundenem Server setzen Sie genau auf die Allowlist, welche GitHub-Tools der Agent aufrufen darf. Das ist eine zweite Kontrollebene über dem Token-Scope. Die vollständige Tool-API finden Sie in den Claude Agent SDK docs.

Triage im großen Stil: Issues als Feed

PRs zu öffnen ist die spektakuläre Demo, aber der stillere tägliche Gewinn ist Issue-Triage. Mit Read/Write auf Issues kann Claude:

• Eingehende Issues nach Bereich und Schweregrad labeln, anhand Ihrer bestehenden Label-Taxonomie
• Duplikate erkennen, indem ein neues Issue mit den offenen verglichen wird
• Einen ersten Antwortkommentar entwerfen, der nach einer Repro fragt, wenn keine vorliegt
• Einen unübersichtlichen Thread mit 40 Kommentaren zu einer Entscheidung und nächsten Aktion zusammenfassen

Ein Muster, das gut funktioniert: Halten Sie das in einem Project in der Claude-App mit angehängtem GitHub-Connector und einem Style, der den Ton Ihres Teams für Issue-Kommentare durchsetzt. Das Project hält den stehenden Kontext (Ihre Label-Definitionen, Ihre Triage-Regeln); der Connector liefert Live-Issue-Daten; der Style hält Claudes öffentliche Kommentare konsistent. Sie kombinieren drei Claude-Features, die Sie schon kennen, zu einem wiederholbaren Workflow.

Bei Repos mit hohem Volumen verlagern Sie die Triage in die CI: Eine GitHub Action führt Claude Code bei jedem neuen Issue mit einem eng gescopten Token und einem festen Prompt aus. Das Token begrenzt weiterhin, was es anfassen kann, sodass ein Fehlgriff im schlimmsten Fall ein Issue falsch labelt, aber keinen Code pushen kann.

Was der Connector nicht kann, und warum das gut ist

Der Consumer-GitHub-Connector kann bewusst keinen beliebigen Code ausführen, nicht Ihre Test-Suite laufen lassen und keine private Infrastruktur erreichen. Wenn Sie die App bitten, „zu fixen und zu verifizieren“, kann sie lesen und vorschlagen, aber die Verifikation braucht Claude Code oder Ihre CI.

Diese Grenze ist ein Feature. Der App-Connector ist zum Lesen, Denken und Entwerfen da. Sobald Sie Ausführung brauchen, sind Sie in Claude Code oder im Agent SDK, wo Sie explizit ein Token vergeben und Tools auf eine Allowlist gesetzt haben. Die Fähigkeiten eskalieren nur so weit, wie Sie es bewusst zulassen.

Einige GuardrailsGuardrailsRegeln und Kontrollen, die ein KI-System in sicheren, rechtskonformen und markengerechten Grenzen halten und unerwünschte Ausgaben blockieren.Vollständige Definition ansehen →, die sich im Team zu standardisieren lohnen:

• Branch Protection auf `main`, damit kein von einem Agenten geöffneter PR ohne Review und grüne CI gemergt werden kann.
• Kurze Token-Laufzeit und Scoping pro Repo, regelmäßig rotiert.
• Tool-Allowlists in jeder SDK- oder Agent-Konfiguration, niemals „alle Tools“.
• Jeden PR prüfen. Claude entwirft; Menschen mergen. Behandeln Sie Agenten-PRs genau wie den ersten PR eines neuen Contributors.

Wichtigste Erkenntnisse

• Wählen Sie den richtigen Weg: den GitHub-Connector in den Claude-Apps zum Lesen und für Triage, den GitHub-MCP-Server in Claude Code oder im Agent SDK, wenn Sie Tests ausführen und echte PRs pushen müssen.
• Scopen Sie ein fine-grained Token auf vier Berechtigungen: Contents, Pull requests und Issues (read/write) plus Metadata (read), begrenzt auf ein Repo mit kurzer Laufzeit. Berechtigungen, nicht Prompts, sind Ihre Sicherheitskontrolle.
• Die Summarize-then-fix-Schleife ist konkret: Repo und Issues lesen, lokal mit Claude Code reproduzieren und fixen, dann Branch erstellen → committen → pushen → PR über das MCP-Pull-Request-Tool. Nichts wird ohne Sie gemergt.
• Staffeln Sie Ihre Kontrollen: Der Token-Scope begrenzt die Fähigkeiten, allowed_tools setzt bestimmte Aktionen auf die Allowlist, und Branch Protection garantiert menschliches Review vor dem Merge.
• Kombinieren Sie Features, die Sie schon haben: ein Project für stehende Triage-Regeln, ein Style für den Kommentarton und der Connector für Live-Daten machen aus Ad-hoc-Hilfe einen wiederholbaren Team-Workflow.