+180 XP

Claude mit GitHub verbinden: Repos, Issues und PRs

# Claude mit GitHub verbinden: Repos, Issues und PRs

Bitten Sie Claude, „dieses Repo zusammenzufassen und einen Pull Request zu öffnen, der den fehlschlagenden Test behebt“, und bei 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 genauen Berechtigungen und einen konkreten Workflow vom Zusammenfassen bis zum Fix.

Zwei Wege zu GitHub: der Connector vs. der MCP-Server

Claude spricht über einen von zwei Mechanismen mit GitHub, und es lohnt sich zu wissen, welchen Sie nutzen, denn sie haben unterschiedliche Trust- und Berechtigungsmodelle.

Der GitHub-Connector ist die verwaltete Point-and-Click-Option innerhalb der Claude-Apps. Sie fügen ihn aus dem Connector-Verzeichnis hinzu, authentifizieren sich per OAuth bei GitHub, und Claude erhält einen kuratierten Satz von GitHub-Tools (Dateien lesen, Issues auflisten, kommentieren, PRs öffnen). Anthropic pflegt ihn. Sie betreiben nichts selbst. Sehen Sie sich das Angebot im Claude connectors directory an.

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 gegenüber verfügbar macht. GitHub veröffentlicht einen offiziellen MCP-Server, und Sie richten Claude Code oder die Claude-Desktop-App darauf aus. Das gibt Ihnen feinere Kontrolle über Scopes, kann im eigenen Netzwerk laufen und stellt mehr Tools bereit als der Consumer-Connector. Spec und SDKs finden Sie auf modelcontextprotocol.io.

Daumenregel: Nutzen Sie den Connector in den Claude-Apps für alltägliches Triage und Lesen. Nutzen Sie den MCP-Server, wenn Sie in Claude Code arbeiten, ihn in CI brauchen oder ein fine-grained Token selbst scopen wollen.

Wo was läuft

| Oberfläche | Wie der GitHub-Zugriff funktioniert |

|---|---|

| Claude Web / Desktop / Mobile | GitHub-Connector (OAuth) |

| Claude Code (Terminal) | GitHub-MCP-Server oder die gh CLI, die es aufrufen kann |

| Anthropic API / Agent SDK | Sie hängen den MCP-Server in Ihrer Tool-Konfiguration an |

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 saubeste Setup nutzt den remote GitHub-MCP-Server mit OAuth. Aus Ihrem Repo:

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

Beim ersten Aufruf startet Claude Code einen OAuth-Flow im Browser. Die Verbindung prüfen Sie jederzeit mit:

bash
claude mcp list

Wenn Sie statt OAuth ein Token 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 gleich, denn hier vergeben die meisten Leute zu viel.

Token-Berechtigungen: nur so viel wie nötig

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 sich auf bestimmte Repositories und bestimmte Berechtigungskategorien beschränken. 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 (nötige Basis; GitHub wählt sie automatisch aus)

Das ist alles. Sie brauchen kein Admin, Sie brauchen kein Workflow-Write, sofern Claude nicht Dateien unter .github/workflows/ bearbeitet, und Sie sollten das Token auf das eine 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 eine kurze Laufzeit. Dann:

bash
export GITHUB_PERSONAL_ACCESS_TOKEN="github_pat_xxx"

Ein wichtiges Denkmodell: 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.

GitHub MCP Server with Claude Code

Watch on YouTube

Der konkrete Workflow: Repo zusammenfassen, dann PR öffnen

Hier das End-to-End-Beispiel, das eingangs versprochen wurde. Angenommen, Sie sind in Claude Code in einem ausgecheckten Repo mit angebundenem GitHub-MCP-Server.

Schritt 1: Das Repository zusammenfassen

Sie brauchen keinen raffinierten Prompt. Sagen Sie konkret, was „Zusammenfassung“ für Sie heißt:

> Lies die Struktur dieses Repos, die README und die Haupt-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 auf, sortiert danach, wie bearbeitbar sie aussehen.

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 die Inhalte tatsächlich in den Kontext geholt wurden.

Schritt 2: Einen Fix auswählen und entwerfen

Sagen wir, ein Issue lautet: *„parse_date wirft bei leerem 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, falls etwas fehlschlägt. Das ist der Teil, den die Connector-Variante in der App weniger gut abdeckt, weil sie Ihre Tests nicht *ausführen* kann. Claude Code kann das.

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. Referenziere Issue #42 in der Beschreibung und erkläre den Fix in zwei Sätzen.

Dahinter stehen GitHub-API-Aufrufe, 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 reviewen, Ihre CI läuft, und ein Mensch genehmigt.

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

python
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: Auch bei angebundenem Server legen Sie per Allowlist genau fest, 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.

Wissenscheck

1. Was ist der zentrale Unterschied zwischen dem GitHub-Connector und dem GitHub-MCP-Server in Bezug auf Trust- und Berechtigungsmodelle?

2. Wann sollten Sie laut der Daumenregel der Lektion den GitHub-MCP-Server dem Connector vorziehen?

3. Wofür ist das Model Context Protocol (MCP) grundsätzlich gedacht?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE korrekten Aussagen dazu, wie der GitHub-Zugriff auf den verschiedenen Claude-Oberflächen funktioniert.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Fähigkeiten, die der GitHub-Connector Claude innerhalb der Claude-Apps gibt.

Wählen Sie alle richtigen Antworten aus.

Triage in großem Maßstab: Issues als Feed

PRs zu öffnen ist die spektakuläre Demo, aber der leisere 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 es ein neues Issue mit den offenen vergleicht
  • Einen ersten Antwortkommentar entwerfen, der nach einem Repro fragt, wenn keines vorliegt
  • Einen unruhigen Thread mit 40 Kommentaren zu einer Entscheidung und einem nächsten Schritt 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 dauerhaften Kontext (Ihre Label-Definitionen, Ihre Triage-Regeln), der Connector liefert die 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 das 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 angefasst werden kann, ein Fehlgriff labelt also schlimmstenfalls ein Issue falsch, Code pushen kann er nicht.

Was der Connector nicht kann, und warum das gut ist

Der Consumer-GitHub-Connector kann bewusst keinen beliebigen Code ausführen, Ihre Test-Suite nicht 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 per Allowlist freigegeben haben. Die Fähigkeiten eskalieren nur so bewusst, wie Sie es zulassen.

Ein paar Guardrails, die sich im Team lohnen zu standardisieren:

  • 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 reviewen. Claude entwirft, Menschen mergen. Behandeln Sie Agenten-PRs genau wie den ersten PR eines neuen Contributors.

Key Takeaways

  • Wählen Sie den richtigen Weg: der GitHub-Connector in den Claude-Apps für Lesen und Triage, der GitHub-MCP-Server in Claude Code oder im Agent SDK, wenn Sie Tests laufen lassen 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 Loop von Zusammenfassung zu Fix 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. Ohne Sie wird nichts gemergt.
  • Staffeln Sie Ihre Kontrollen: der Token-Scope begrenzt die Fähigkeiten, allowed_tools gibt bestimmte Aktionen per Allowlist frei, und Branch Protection garantiert menschliches Review vor dem Merge.
  • Kombinieren Sie Features, die Sie schon haben: ein Project für dauerhafte Triage-Regeln, ein Style für den Kommentarton und der Connector für Live-Daten machen aus Ad-hoc-Hilfe einen wiederholbaren Team-Workflow.