Claude-Code-Connector-Tutorial: GitHub-Repos in 20 Minuten triagieren

In diesem Tutorial zeige ich dir, wie du Claude Code per Claude-Connector (auf Basis des Model Context Protocol) mit GitHub verbindest und damit ein Open-Source-Repository von Anfang bis Ende triagierst. 

Der Workflow klont nichts, braucht keinen Vektorspeicher und berührt keine einzige Zeile im Ziel-Repo. Stattdessen liest Claude Code Issues über den Connector aus und schreibt Artefakte auf dein lokales Dateisystem, die du prüfst, bevor du entscheidest, was (wenn überhaupt) gepostet wird.

Am Ende dieses Tutorials hast du:

• Eine funktionierende Claude-Code- und GitHub-MCP-Einrichtung mit einem schreibgeschützten Token,
• Einige wiederverwendbare Prompts, die du auf jedes öffentliche Repo richten kannst,
• Ein vollständiges Triage-Artefakt für langchain-ai/langchain zum Vergleichen.

Was ist der Claude-Code-GitHub-Connector (MCP)?

Claude Code ist Anthropics Terminal-basierter Coding-Agent. 

Out of the box hat er bereits Zugriff auf dein Dateisystem, die Shell und git. Claude-Code-Connectoren erweitern ihn um externen Kontext, etwa GitHub-Issues, Linear-Tickets, Slack-Nachrichten, Postgres-Abfragen und mehr, auf die das Terminal allein nicht zugreifen kann.

Das Protokoll für die Connectoren heißt MCP (Model Context Protocol) und ist ein offener Standard, um LLM-Agenten Tools und Daten bereitzustellen. 

Anthropic pflegt ein Verzeichnis mit einsatzbereiten Connectoren. Du kannst auch eigene schreiben oder dich mit Drittanbieter-MCP-Servern verbinden.

Für dieses Tutorial verwenden wir den offiziellen GitHub-MCP-Server, der lokal via Docker läuft. Zentrale Ideen hinter dem Setup:

• Läuft als lokaler Docker-Container ohne Cloud-Zwischenebene, sodass die Zugangsdaten auf deinem Rechner bleiben.
• Authentifizierung per standardmäßigem GitHub Personal Access Token (PAT), keine OAuth-App-Registrierung nötig.
• Unterstützt eingeschränkte Berechtigungen, z. B. ein ungescoptes PAT mit Lesezugriff auf öffentliche Repos, sodass auf GitHub-API-Ebene keine Schreibvorgänge möglich sind.
• Wird per claude mcp add in Claude Code eingebunden, dann stehen die Tools in jeder Session bereit.

Open-Source-Triage ist leselastig, erfordert viel Urteilsvermögen und ist günstig, wenn man danebenliegt. 

50 Issues zu lesen und zu clustern ist für Menschen mühsam, für ein Modell mit großem Kontextfenster jedoch ideal. 

Außerdem schreiben wir Ausgaben zuerst als lokale Dateien. Ein schlechtes Cluster oder ein holpriger Entwurf kostet nichts und lässt sich bei der Durchsicht abfangen.

Claude-Code-GitHub-Connector-Tutorial: Triage für langchain-ai/langchain aufbauen

In diesem Abschnitt richten wir den GitHub-Connector in Claude Code ein und lassen vier Triage-Prompts gegen langchain-ai/langchain laufen. Das ist ein großes ML-Repo mit einem wirklich unübersichtlichen Issue-Tracker. Auf hoher Ebene bauen wir Folgendes:

• Claude Code per offiziellem MCP-Server in Docker mit GitHub verbinden,
• Ein PAT ohne Scopes verwenden, damit der Connector konstruktionsbedingt nur lesen kann,
• Triage-Prompts ausführen, die Ergebnisse als lokale Dateien speichern,
• Ausgaben prüfen, inklusive Fällen, in denen Claude sich weigerte, Issues als Duplikate zu clustern.

Legen wir Schritt für Schritt los.

Schritt 1: Voraussetzungen für Claude Code und Docker installieren

Bevor wir den Connector einrichten, brauchst du drei Dinge:

• Claude Code: Du kannst es über Anthropics offizielle Installationsanleitung installieren,
• Docker Desktop: Der offizielle GitHub-MCP-Server läuft in einem Container, daher muss Docker installiert und gestartet sein,
• Ein GitHub-Konto: Wird im nächsten Schritt zum Erstellen des PAT benötigt.

Wenn alle Voraussetzungen erfüllt sind, prüfe, ob Docker läuft:

docker info | head -5

Wenn Docker nicht installiert ist oder der Daemon nicht läuft, siehst du den Fehler "Cannot connect to the Docker daemon". Unter macOS startest du Docker Desktop mit:

open -a Docker

Docker Desktop braucht 15–60 Sekunden, bis es vollständig bereit ist, und docker info wirft in diesem Zeitfenster weiterhin Fehler. Statt manuell zu prüfen, nutze eine kleine Warteschleife, die so lange pollt, bis der Daemon läuft:

until 

docker info >/dev/null 2>&1; do sleep 2; echo "waiting..."; done && echo "Docker ready"

Sobald Docker ready ausgegeben wird, kannst du weitermachen.

Schritt 2: Ein schreibgeschütztes GitHub-Token erstellen

Wenn Docker eingerichtet ist, gehe zu github.com/settings/tokens und generiere ein neues klassisches Token.

Hinweis: Lass alle Scopes abgewählt. Ein ungescoptes Token kann über die GitHub-API weiterhin öffentliche Repositories lesen – genau das braucht unser Agent. Ohne gewählte Scopes kann das Token nichts auf GitHub schreiben, ändern oder löschen, egal, was wir Claude beauftragen. Das ist eine harte Garantie auf GitHub-Seite, keine bloße Zusicherung über das Verhalten des Agents.

Kopiere und speichere das Token direkt nach der Erstellung und exportiere es dann in deiner Shell:

export GITHUB_PERSONAL_ACCESS_TOKEN="ghp_your_token_here"

Wenn du bereits in einer Claude-Code-Session bist, könntest du versucht sein, das !-Präfix zu nutzen, um den Export direkt in deiner Shell auszuführen (z. B. ! export GITHUB_PERSONAL_ACCESS_TOKEN="..."). 

Da ! jedoch eine temporäre Subshell startet, verschwindet die Variable sofort nach Ende des Befehls und Claude sieht sie nicht.

Um das Token sicher zu setzen, ohne es in den Modell-Prompt zu kopieren, hast du zwei Optionen:

1. Tippe /exit, um Claude zu verlassen, führe den Export-Befehl in deinem normalen Terminal aus und starte Claude neu.
2. Oder speichere das Token in einer lokalen .env-Datei in deinem Arbeitsverzeichnis. Claude Code liest sie beim Start automatisch ein.

Prüfe beide Voraussetzungen, ohne das Token selbst auszugeben:

docker info | head -3
echo "Token set: ${GITHUB_PERSONAL_ACCESS_TOKEN:+yes}"

Der zweite Befehl druckt Token set: yes, wenn die Variable existiert, und Token set: (nichts nach dem Doppelpunkt), wenn sie leer ist. 

Das ist sicherer, als das Token direkt zu echoen, da es so nicht im Klartext in deinem Shell-Verlauf landet.

Schritt 3: Den GitHub-Connector in Claude Code registrieren

Der offizielle GitHub-MCP-Server wird als Docker-Image ausgeliefert. 

Wir registrieren ihn in Claude Code mit claude mcp add:

claude mcp add github \
  -e GITHUB_PERSONAL_ACCESS_TOKEN=$GITHUB_PERSONAL_ACCESS_TOKEN \
  -- docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN \
  ghcr.io/github/github-mcp-server

Die zwei -e-Flags sind hier kein Tippfehler:

• Das erste -e (vor --) setzt eine Umgebungsvariable für den MCP-Prozess, den Claude Code startet,
• Das zweite -e (innerhalb der docker run-Argumente) weist Docker an, diese Variable in den Container durchzureichen.

Fehlt eines davon und der Container startet mit leerem Token, schlägt die Authentifizierung gegen die GitHub-API fehl.

So prüfst du, ob der Connector erfolgreich registriert wurde:

claude mcp list

Du solltest Folgendes sehen:

github — docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server —  Connected

Wenn Failed to connect erscheint, sind die häufigsten Ursachen: Docker läuft nicht oder GITHUB_PERSONAL_ACCESS_TOKEN wurde nicht in derselben Shell exportiert, in der du claude mcp add ausgeführt hast.

Schritt 4: Verbindung prüfen

Unser GitHub-Token steht nun bereit. Als Nächstes erstellen wir ein Arbeitsverzeichnis und öffnen die Claude-Code-CLI:

mkdir demo && cd demo
claude

Der Befehl claude startet eine interaktive Session im aktuellen Verzeichnis. 

Alle Dateien, die Claude während der Triage schreibt, landen hier. 

Stelle dann eine einfache Leseabfrage, um zu bestätigen, dass der Connector genutzt wird:

Using the GitHub MCP connector, fetch the 5 most recently updated open issues in langchain-ai/langchain. Just list titles and numbers.

Beim ersten Einsatz eines GitHub-Tools in Claude Code wirst du um Zustimmung gebeten. 

Erlaube schreibgeschützte Tools wie list_issues, get_issue, search_issues usw. 

Wenn Claude stattdessen per curl gegen die öffentliche GitHub-API fällt, werden die MCP-Tools nicht genutzt. Beende dann die Session und starte neu.

Ein erfolgreicher Lauf liefert in etwa Folgendes:

Sobald echte Issue-Nummern per MCP zurückkommen, können wir die eigentliche Triage starten.

Schritt 5: Eine Backlog-Zusammenfassung erzeugen

Die Aufwärmaufgabe ist reines Lesen. Wir wollen zunächst eine Landkarte des Issue-Trackers, bevor wir weitergehen.

Prompt:
Using the GitHub MCP connector, pull the 50 most recently updated open issues from langchain-ai/langchain. 
Read their titles, bodies, and labels. Group them by likely area — bugs, feature requests, documentation, questions, and "needs more info." 
For each group, give me a count and 3-5 representative issue numbers with a one-line reason. Save as backlog-summary.md in the current directory.

Claude Code holt die Issues über den Connector, liest sie und schreibt eine Markdown-Datei, die sie nach Bereichen gruppiert und repräsentative Issue-Nummern aufführt. Diese Datei allein ist für Maintainer nützlich: In 60 Sekunden weiß man, was in der Woche ansteht.

Schritt 6: Duplikat-Kandidaten markieren

Bei der Duplikaterkennung spielt ein Agent seine Stärken aus. 

50 Issues komplett zu lesen und nach zugrunde liegendem Problem zu clustern, ist für Menschen mühsam. Ein Modell kann alle gleichzeitig im Kontext halten und Überschneidungen erkennen, die eine Stichwortsuche übersehen würde.

Prompt:
From the same 50 issues you already pulled, identify clusters of likely duplicates: issues describing the same underlying problem, even if titles differ. For each cluster, output issue numbers, a one-sentence shared-problem description, and confidence (high/medium/low). Save as duplicate-candidates.md.

Das hat Claude in meinem Lauf tatsächlich erzeugt:

Der interessanteste Teil sind die Cluster 2 bis 4. 

Ein naiver, schlüsselwortbasierter Duplikatdetektor hätte alle vier Cluster als Duplikate geschlossen. 

Claude hat sich ausdrücklich geweigert, sie als Duplikate zu bezeichnen. 

Es hat sie als Komponenten-Cluster mit demselben Subsystem, aber unterschiedlichen Ursachen markiert und mir gesagt, welche tatsächlich geschlossen werden sollten (nur Cluster 1) und welche gemeinsam triagiert, aber offen bleiben sollten.

Das ist genau das Verhalten, das man sich von einer sorgfältigen menschlichen Triagistin wünschen würde – und genau deshalb lohnt sich das Muster „lokale Dateien, dann Review“ als zusätzlicher Schritt. 

Hätten wir direkt in die GitHub-API verdrahtet und alles automatisch geschlossen, was Claude markiert hat, wären drei echte Bugs fälschlich geschlossen worden.

Schritt 7: Prüfen – und dann entscheiden, was gepostet wird

Das ist der ganze Punkt des Local-Files-Musters. 

Bevor irgendetwas GitHub berührt, prüfe jede von Claude gespeicherte .md-Datei und ob die Gruppierung deiner Intuition entspricht. 

Sehen die High-Confidence-Cluster wirklich wie Duplikate aus? Lies 2–3 Antwortentwürfe und prüfe, ob sie klingen wie von dir.

Wenn du Kommentare wirklich posten oder Labels setzen willst, hast du zwei Optionen:

• Manuell: Du kannst die Entwürfe selbst in GitHub einfügen. Für eine einmalige Triage in einem fremden Repo ist das oft die richtige Wahl.
• Schreibrechte für ein eigenes Repo autorisieren: Erzeuge ein separates PAT mit Repo-Scope, füge es als eigenen Connector-Eintrag hinzu (z. B. github-write) und führe die Prompts erneut aus, damit Claude Labels setzt und Kommentare postet. Claude Code fragt beim ersten Einsatz jedes Schreib-Tools nach Bestätigung.

Der zentrale Sicherheitskniff für den Write-Pfad ist, Lese- und Schreib-Token strikt zu trennen. 

Fazit

In diesem Tutorial habe ich gezeigt, wie du Claude Code per MCP mit GitHub verbindest und damit ein reales Open-Source-Repository Ende-zu-Ende triagierst. 

Statt einen eigenen GitHub-Bot zu bauen oder Webhooks zu verdrahten, liest der Workflow Issues über den offiziellen GitHub-MCP-Server, schreibt vier Triage-Artefakte als lokale Dateien und lässt dich alles prüfen, bevor du entscheidest, was gepostet wird.

Die übergeordnete Erkenntnis: Connectoren machen aus Claude Code mehr als nur einen Coding-Agenten – sie ermöglichen, deine Tools zu lesen und Arbeit für dich zur Prüfung vorzubereiten. 

Die sinnvolle Grundeinstellung ist, diese Arbeit lokal zu behalten, bis du sie gesehen hast. Wenn du dem Muster vertraust, kannst du dem Agenten gezielt dort Aktionen erlauben, wo die Kosten eines Fehlers gering sind.

Von hier aus kannst du das Projekt auf mehrere Arten erweitern:

• Schreibfähige Connectoren in eigenen Repos hinzufügen, damit Labels und Kommentare nach dem Review automatisch angewendet werden,
• Linear- oder Slack-Connectoren einbinden, um Triage-Entscheidungen in den Workflow deines Teams zu spiegeln,
• Die Prompts in einen geplanten CI-Job verwandeln, der wöchentlich eine Triage-PR erstellt,
• Oder die obigen Prompts zu einem wiederverwendbaren Claude-Code-Slash-Befehl generalisieren, der mit jeder Repo-URL funktioniert.