Git und Forges

Forges heißen die Plattformen um ein Git-Repository: GitHub, GitLab, Bitbucket oder ein eigener Server. Dort liegen Issues, Pull Requests und die Prüfläufe der CI. Was Git selbst leistet und warum ein Agent ohne Git riskant arbeitet, erklärt Vibe-Coding / Agentic Engineering, Kapitel 04. Dieses Kapitel zeigt, an welchen Stellen Claude Code Git und die Forges bedient: in der eigenen Sitzung, über eine Erwähnung auf GitHub, beim Reparieren eines Pull Requests und in der Cloud. Am Ende steht, was davon für GitHub Enterprise Server, GitLab und andere Hosts gilt.

Was Claude in einer Sitzung mit Git tut

In einer Sitzung bedient Claude Git über die Kommandozeile, wie ein Mensch am Terminal. Es merkt Änderungen für den Commit vor, schreibt die Commit-Nachricht und legt Branches an (Überblick der Doku (externe Seite, code.claude.com)). Einen Pull Request öffnet es, wenn man darum bittet (Arbeitsabläufe (externe Seite, code.claude.com)). Für GitHub empfiehlt Anthropic dazu die Kommandozeile gh. Claude kann damit Issues anlegen, Pull Requests öffnen und Kommentare lesen (Empfehlungen (externe Seite, code.claude.com)). Ohne gh kann Claude die Schnittstelle von GitHub nutzen. Anfragen ohne Anmeldung stoßen dort aber oft an die Grenze für Anfragen.

Wie ein Commit und ein Pull Request aussehen sollen, steht in Anweisungen, die Claude Code mitliefert (Ein­stel­lungs­re­fe­renz (externe Seite, code.claude.com)). Öffnet Claude einen Pull Request mit gh pr create oder einen Merge Request mit glab mr create, verknüpft Claude Code die Sitzung damit. Wie man sie darüber wiederfindet, zeigt die zweite Ebene.

Unter jeden Commit setzt Claude Code in der Voreinstellung eine Zeile Co-Authored-By, unter einen Pull Request einen Hinweis in Textform. Die Zeile nennt das Modell, das beim Commit gerade arbeitet. Seit Version 2.0.62 vom 09.12.2025 regelt die Einstellung attribution beide Zeilen (Versionsliste (externe Seite, code.claude.com)). Claude Code teilt Claude mit, dass eine eigene Anweisung dazu, etwa in der CLAUDE.md, diesen Zeilen vorgeht. Ausgenommen sind Zeilen, die eine Organisation fest vorgibt.

Ob Claude ohne Rückfrage committen oder pushen darf, entscheiden die Regeln für Befehle und der Modus. Die Doku zeigt eine Regel, mit der Claude Code Commits ohne Rückfrage ausführt und jeden Befehl ablehnt, der mit git push beginnt (Doku zu Berechtigungen (externe Seite, code.claude.com)). Die Regel vergleicht den Text des Befehls. Einen Push in anderer Schreibweise, etwa git -C . push, erfasst sie nicht. Über ihn entscheiden dann die übrigen Regeln und der Modus. Wie man solche Regeln schreibt und wo sie aufhören, erklärt Kapitel 16.

Claude auf GitHub erwähnen

Am 22.05.2025 stellte Anthropic zusammen mit dem Claude Code SDK eine Anbindung an GitHub vor, als Beta (Ankündigung (externe Seite, anthropic.com)). In einem Pull Request erwähnt, sollte Claude laut Ankündigung auf Hinweise aus dem Review antworten, Fehler der CI beheben oder Code ändern. Eingerichtet wurde das schon damals mit /install-github-app.

Heute heißt die Anbindung Claude Code GitHub Actions. Wer @claude in einem Kommentar zu einem Issue oder Pull Request erwähnt, lässt Claude den Code untersuchen, ändern und Commits pushen (Doku zu GitHub Actions (externe Seite, code.claude.com)). Claude antwortet in einem Kommentar am selben Ort und schreibt ihn fort, während es arbeitet. Auslösen kann das nur, wer Schreibrechte am Repository hat. Einzelne Nutzer ohne Schreibrechte lassen sich ausdrücklich zulassen. Claude läuft dabei in einem Workflow des Repositorys auf Rechnern von GitHub. Was das kostet, steht auf der dritten Ebene.

/install-github-app installiert die GitHub-App von Claude, legt das Geheimnis für die Anmeldung an und bereitet den Pull Request mit dem Workflow vor. Dafür braucht man Adminrechte am Repository. Der Befehl funktioniert nur mit Repositorys auf github.com. Was im Workflow steht, welche Geheimnisse er braucht und wie er über Amazon Bedrock, Googles Agent Platform oder Microsoft Foundry läuft, beschreibt Kapitel 29.

Dieselbe GitHub-App bedient alle Funktionen von Claude, die mit GitHub verbunden sind, darunter die Action, Code Review und den Auto-fix für Pull Requests. Wer sie installiert, nimmt ihre Rechte als ganzen Satz an. Einen Teil davon auszuwählen, lässt GitHub nicht zu. Wie Code Review an jedem Pull Request arbeitet, steht in Kapitel 25.

Auto-fix hält den Pull Request grün

In der Woche vom 23. bis 27.03.2026 kam ein Schalter für Pull Requests, die in Claude Code im Web entstanden (Wochenbericht 13 (externe Seite, code.claude.com)). Ist er an, beobachtet Claude die CI, behebt die Fehler, erledigt die Kleinigkeiten aus dem Review und pusht, bis alles grün ist. In der Woche vom 06. bis 10.04.2026 folgte /autofix-pr. Der Befehl schaltet den Auto-fix aus dem Terminal ein (Wochenbericht 15 (externe Seite, code.claude.com)).

Claude abonniert dafür die Ereignisse des Pull Requests auf GitHub. Schlägt eine Prüfung fehl oder kommentiert ein Reviewer, sieht Claude nach und pusht eine Korrektur, wenn sie eindeutig ist (Doku zu Cloud-Sitzungen (externe Seite, code.claude.com)). Ist ein Kommentar mehrdeutig oder berührt er die Architektur, fragt Claude vorher nach. Voraussetzung ist die GitHub-App von Claude im Repository. Gearbeitet wird in einer Cloud-Sitzung. /autofix-pr braucht gh und Zugang zu Cloud-Sitzungen (Befehlsreferenz (externe Seite, code.claude.com)).

Zwei Grenzen nennt die Doku. Entsteht ein Konflikt, weil der Zielbranch vorgerückt ist, schickt GitHub kein Ereignis, und der Auto-fix bemerkt ihn nicht. Den Konflikt löst Claude erst auf Bitte. Außerdem erscheinen Claudes Antworten auf Kommentare unter dem eigenen GitHub-Konto, gekennzeichnet als Text von Claude Code. Startet in einem Repository ein Kommentar eine Automatik, etwa ein Deployment, kann eine solche Antwort sie auslösen. Die Doku rät, die Automatik vorher durchzusehen. Die Desktop-App beobachtet einen Pull Request auch lokal. Das zeigt die zweite Ebene.

Cloud-Sitzungen brauchen GitHub

Cloud-Sitzungen gibt es in den Tarifen Pro, Max und Team, in Enterprise für Premium-Plätze und Plätze für Chat und Claude Code (Doku zu Cloud-Sitzungen (externe Seite, code.claude.com)). Eine Cloud-Sitzung holt ihren Code von GitHub. Klonen und Pull Requests anlegen geht dort nur mit GitHub. Ein Repository von GitLab, Bitbucket oder einem anderen Host lässt sich mit CCR_FORCE_BUNDLE=1 als Bündel hochladen. Zurückschreiben kann die Sitzung dorthin dann nichts. Den Zugang zu GitHub gibt man über die GitHub-App oder mit /web-setup. Der Befehl reicht die Anmeldung der lokalen gh an das Konto bei Claude weiter. In den Umgebungen, die Anthropic betreibt, bleiben die Zugangsdaten zu GitHub verschlüsselt auf Anthropics Servern und gelangen nie in die virtuelle Maschine der Sitzung. Wie man Arbeit in die Cloud gibt und zurückholt, zeigen Kapitel 28 und Kapitel 30.

GitHub Enterprise Server, GitLab und andere Hosts

Wer GitHub auf eigenen Servern betreibt, nutzt GitHub Enterprise Server, kurz GHES. Claude Code unterstützt das in den Tarifen Team und Enterprise (Doku zu GHES (externe Seite, code.claude.com)). Ein Owner verbindet die Instanz einmal. Danach laufen Cloud-Sitzungen und Code Review ohne Einstellung je Repository. GitHub Actions geht dort ebenfalls, den Workflow richtet man aber von Hand ein.

Für GitLab gibt es Claude Code für GitLab CI/CD, als Beta (Doku zu GitLab (externe Seite, code.claude.com)). Gepflegt wird diese Anbindung von GitLab. Den Job in der Pipeline startet ein Auslöser, den man selbst wählt, zum Beispiel ein Kommentar mit @claude in einem Issue oder Merge Request. Auf eine solche Erwähnung reagiert der Job erst, wenn ein eigener Dienst die Kommentare abhört und die Pipeline startet. Jede Änderung kommt als Merge Request, und die Freigaben im Projekt gelten weiter. Im Terminal erkennt Claude Code seit Version 2.1.259 vom 02.09.2026 die Befehle von glab für Merge Requests (Versionsliste (externe Seite, code.claude.com)).

Liegt das Repository auf codeberg.org oder gitea.com, setzt Claude Code aus einem Verweis wie owner/repo#123 keinen Link, der Verweis bleibt Text (Doku zum interaktiven Modus (externe Seite, code.claude.com)). Eine Anbindung an Forgejo oder Gitea beschreibt die Doku nicht, Stand 12.10.2026. Commits, Branches und Push laufen im Terminal über Git und damit mit jedem Host, den Git erreicht.

Was für wen gilt

Quelle: Her­stel­ler­do­ku­men­ta­tion zu Cloud-Sitzungen, GitHub Actions, Code Review (externe Seite, code.claude.com), GHES und GitLab, Stand 12.10.2026.

Codex von OpenAI bindet GitLab an seine eigene Cloud an, als Beta in allen Tarifen von ChatGPT (Codex-Doku zu GitLab (externe Seite, learn.chatgpt.com)). Den Vergleich zeigt die dritte Ebene.

Die erste Ebene hat die Stellen gezeigt, an denen Claude Code in Git und die Forges eingreift. Hier geht es um die Bedienung. Welche Zeilen setzt Claude Code unter einen Commit? Wie trennt eine Regel Commit und Push? Was richtet /install-github-app ein, und wie lässt sich der Auto-fix eingrenzen? Am Ende steht, was ein Owner für GitHub Enterprise Server tun muss und was Claude Code im Terminal mit GitLab anfängt.

Was unter einem Commit steht

In der Voreinstellung endet jeder Commit mit einer Zeile Co-Authored-By. Sie nennt das Modell, das den Commit macht. Committet ein Subagent, steht dort sein Modell (Ein­stel­lungs­re­fe­renz (externe Seite, code.claude.com)). Erkennt Claude Code kein Modell von Claude, etwa bei einem fremden Modell hinter einer eigenen Adresse, schreibt es Claude Code. Unter die Beschreibung eines Pull Requests setzt es einen Satz mit Verweis auf Claude Code.

Die Einstellung attribution hat drei Teile:

• commit ersetzt die Zeile unter Commits. Eine leere Zeichenkette lässt sie weg.
• pr ersetzt den Satz unter Pull Requests, ebenfalls leer zum Weglassen.
• sessionUrl betrifft Sitzungen in der Cloud und über Remote Control. Dort hängt Claude Code einen Link zur Sitzung an. Den Link gibt es für Sitzungen im Web seit Version 2.1.9 vom 16.01.2026 (Versionsliste (externe Seite, code.claude.com)). Den Schalter gibt es seit 2.1.183 vom 19.06.2026.

{
  "attribution": {
    "commit": "",
    "pr": "",
    "sessionUrl": false
  }
}

Seit Version 2.1.281 vom 23.09.2026 geht dasselbe kürzer mit "attribution": false. Ältere Fassungen lehnen diesen Wert ab und überspringen dann die ganze Datei, in der er steht. In einer Datei, die mehrere Versionen lesen, ist die ausgeschriebene Form deshalb die sichere. Die alte Einstellung includeCoAuthoredBy gilt seit 2.0.62 als veraltet und wird noch gelesen.

Eine zweite Einstellung betrifft das, was Claude über Git erfährt. includeGitInstructions schaltet die eingebauten Anweisungen für Commits und Pull Requests ab, zusammen mit dem Abzug des Git-Stands vom Sitzungsbeginn. Der Abzug enthält den aktuellen Branch, den Hauptbranch, die Ausgabe von git status und die letzten Commits. Für eine einzelne Sitzung geht das über die Umgebungsvariable CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS. Cloud-Sitzungen bekommen den Abzug nie.

Commit erlauben, Push sperren

Die Regel aus der Doku sieht so aus (Doku zu Berechtigungen (externe Seite, code.claude.com)):

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "deny": ["Bash(git push *)"]
  }
}

Sie greift nur, wo der Befehl mit git push beginnt. git -C . push, git -c push.default=current push oder ein push in Anführungszeichen erfasst sie nicht. Über diese Formen entscheiden die übrigen Regeln und der Modus. Laut Doku deckt eine Regel zum Ablehnen oder Nachfragen nur den Aufruf ab, den Claude gewöhnlich schreibt. Eine Grenze für Dateisystem und Netz, die am Text des Befehls nicht hängt, zieht die Sandbox (Kapitel 16). Den ganzen Befehl mit eigener Logik prüfen kann ein Hook vor dem Aufruf (Kapitel 18). Auch in der Sandbox, die Befehle in der Voreinstellung ohne Rückfrage ausführt, erzwingt eine Regel zum Nachfragen wie Bash(git push *) weiter die Rückfrage.

Die Zugangsdaten der beiden Kommandozeilen schützt Claude Code eigens. Seit Version 2.1.232 vom 13.08.2026 bekommt der Speicher von glab denselben Schutz wie der von gh, und Claude Code schwärzt Token von GitLab (Versionsliste (externe Seite, code.claude.com)).

Eine Sitzung über ihren Pull Request finden

Claude Code verknüpft eine Sitzung mit einem Pull Request, sobald Claude ihn mit gh pr create oder glab mr create anlegt. Dasselbe gilt, wenn Claude an einem bestehenden Pull Request arbeitet (Arbeitsabläufe (externe Seite, code.claude.com)). Zwei Wege führen zurück:

• claude --from-pr 1234 öffnet die Auswahl der Sitzungen, gefiltert auf diesen Pull Request. Der Schalter nimmt eine Nummer oder eine Adresse von GitHub, GitHub Enterprise, GitLab oder Bitbucket (CLI-Referenz (externe Seite, code.claude.com)). Seit 2.1.27 vom 30.01.2026 gibt es ihn für GitHub, seit 2.1.119 vom 23.04.2026 für die übrigen Hosts (Versionsliste (externe Seite, code.claude.com)).
• In /resume fügt man die Adresse in die Suche ein, seit 2.1.122 vom 28.04.2026.

Unter der Eingabe zeigt Claude Code den Pull Request des aktuellen Branches als Plakette mit Link. Wer Pull Requests in einem eigenen Werkzeug prüft, lenkt diesen Link mit prUrlTemplate dorthin, seit 2.1.119. Für GitLab gibt es die Plakette seit 2.1.234 vom 17.08.2026. Sie braucht ein angemeldetes glab. Den Befehl /pr-comments, der die Kommentare eines Pull Requests holte, gibt es laut Befehlsreferenz seit 2.1.91 nicht mehr. Man bittet Claude direkt darum (Befehlsreferenz (externe Seite, code.claude.com)).

Was /install-github-app einrichtet

Der Befehl braucht eine angemeldete Kommandozeile gh (Doku zu GitHub Actions (externe Seite, code.claude.com)). Er führt in Schritten durch die Einrichtung:

1. Er installiert die GitHub-App von Claude im gewählten Repository.
2. Er legt das Geheimnis für die Anmeldung an. Hat Claude Code schon einen API-Schlüssel, nimmt es diesen. Sonst wählt man zwischen einem langlebigen Token aus dem eigenen Abo und einem eingefügten Schlüssel. Gespeichert wird es als Geheimnis des Repositorys, ANTHROPIC_API_KEY oder CLAUDE_CODE_OAUTH_TOKEN.
3. Er pusht einen Branch mit den gewählten Workflows und öffnet GitHub im Browser mit einem vorbereiteten Pull Request, den man nur noch anlegt. Erst wenn man ihn anlegt und zusammenführt, reagiert @claude im Repository.

Nach dem ersten Schritt lässt sich mit Skip for now aufhören, dann ist nur die App installiert. Das geht seit Version 2.1.187 vom 23.06.2026 (Versionsliste (externe Seite, code.claude.com)). Wählt man den Workflow für Reviews, schreibt Claude seine Befunde als Kommentare an den Pull Request. Vor 2.1.229 vom 12.08.2026 standen sie nur im Protokoll des Laufs. Liegt das Repository auf gitlab.com oder bitbucket.org, meldet der Befehl das und beendet sich. Wie man die Action für eine ganze Organisation ausrollt, steht in Kapitel 29.

Auto-fix aus dem Terminal

/autofix-pr startet eine Cloud-Sitzung, die den Pull Request des aktuellen Branches beobachtet (Befehlsreferenz (externe Seite, code.claude.com)). Den Pull Request findet der Befehl über gh pr view. Für einen anderen Pull Request wechselt man vorher auf dessen Branch. Ohne weitere Angabe soll die Sitzung jeden Fehler der CI und jeden Kommentar aus dem Review beheben. Ein Text hinter dem Befehl ändert den Auftrag, etwa /autofix-pr only fix lint and type errors.

Einschalten lässt sich der Auto-fix auch an anderen Stellen (Doku zu Cloud-Sitzungen (externe Seite, code.claude.com)):

• in einer Cloud-Sitzung, die den Pull Request angelegt hat, über die Statusleiste der CI auf claude.ai/code,
• in der Claude-App auf dem Telefon mit einer Bitte in eigenen Worten,
• für jeden bestehenden Pull Request, indem man seine Adresse in eine Sitzung einfügt und um den Auto-fix bittet.

Der Schalter gilt je Pull Request. Ausschalten geht in derselben Statusleiste oder mit der Bitte, den Pull Request nicht mehr zu beobachten. Ist ein Ereignis doppelt oder verlangt es keine Änderung, vermerkt Claude das in der Sitzung und macht weiter.

Den Pull Request in der Desktop-App beobachten

Nach dem Öffnen steht der Pull Request mit dem Stand seiner CI-Prüfungen in der Karte Changes der Sitzungsdetails (Doku zur Desktop-App (externe Seite, code.claude.com)). Zwei Schalter stehen im Menü ⋮ neben seinem Titel, im früheren Layout hinter CI in der Statusleiste.

• Auto-fix lässt Claude rote Prüfläufe reparieren. In einer lokalen Sitzung geht Claude auch auf neue Kommentare ein. Sie müssen vom Owner des Repositorys, einem Mitglied der Organisation, einem Collaborator oder einer GitHub-App kommen.
• Merge when ready schaltet für den Pull Request das Auto-merge von GitHub ein. In einer lokalen Sitzung verlangt die App einen Squash, außer der Zielbranch nutzt eine Merge Queue. In Sitzungen über SSH und WSL ist der Schalter gesperrt, dort schaltet man Auto-merge auf GitHub selbst ein. Das Repository muss Auto-merge in seinen Einstellungen erlauben.

In einer lokalen Sitzung braucht diese Überwachung ein angemeldetes gh auf dem eigenen Rechner. In einer Sitzung über SSH gehören git und gh auf den Server. Der Auto-fix aus dem vorigen Abschnitt läuft dagegen in der Cloud und braucht die GitHub-App.

Cloud-Sitzungen mit GitHub verbinden

Für Cloud-Sitzungen gibt es zwei Wege zu GitHub (Doku zu Cloud-Sitzungen (externe Seite, code.claude.com)):

Quelle: Doku zu Cloud-Sitzungen (externe Seite, code.claude.com), Stand 12.10.2026.

Zwei Funktionen brauchen die App in jedem Fall: der Auto-fix und Projects. Jeder Thread eines Projekts braucht sie in jedem Repository, das er klont. Seit Version 2.1.248 vom 27.08.2026 warnt /web-setup, wenn dem Token von gh das Recht für Workflows fehlt (Versionsliste (externe Seite, code.claude.com)). Organisationen mit Zero Data Retention oder HIPAA-Konfiguration können weder /web-setup noch Cloud-Sitzungen nutzen. In Team und Enterprise ist die Schnell­ein­rich­tung der Organisation in der Voreinstellung aus. Solange sie aus ist, blendet Claude Code /web-setup aus.

Hat das Repository keinen Remote oder fehlt die App in einem Repository auf github.com, packt claude --cloud das lokale Repository ein und lädt es hoch. Das Bündel enthält die Historie samt den Änderungen, die noch in keinem Commit stehen, an Dateien, die Git verfolgt. Unter macOS, Linux und WSL bleiben dabei Änderungen an Dateien auf dem Rechner, deren Name nach Zugangsdaten oder Schlüsseln aussieht, etwa .env oder id_rsa. Das Bündel muss unter 100 MB bleiben. Ist es größer, nimmt Claude Code nur den aktuellen Branch und danach einen einzelnen Stand des Arbeitsbaums ohne Historie. Ist auch der zu groß, scheitert das Hochladen. Mit CCR_FORCE_BUNDLE=1 geht derselbe Weg für Repositorys auf GitLab, Bitbucket und anderen Hosts. Pushen kann die Sitzung dorthin nicht.

GitHub Enterprise Server einrichten

Die Einrichtung macht ein Owner oder Primary Owner der Organisation bei Claude. Er braucht zusätzlich das Recht, auf dem eigenen GHES GitHub-Apps anzulegen (Doku zu GHES (externe Seite, code.claude.com)). Unter Organization settings, Git providers erzeugt eine geführte Einrichtung eine Beschreibung der App und leitet zum eigenen Server weiter, wo die App mit einem Klick entsteht. Danach installiert man die App in den gewünschten Repositorys und schaltet Code Review in den Einstellungen für Admins ein. Blockiert das eigene Netz die Weiterleitung, geht es auch von Hand.

Für Sitzungen in Anthropics Cloud muss der Server von Anthropics Infrastruktur aus erreichbar sein. Hinter einer Firewall gibt man Anthropics ausgehende Adressen frei. Entwickler stellen danach nichts mehr ein. Claude Code erkennt den Server am Remote des Arbeits­ver­zeich­nisses.

Quelle: Doku zu GHES (externe Seite, code.claude.com), Stand 12.10.2026.

GitLab im Terminal

Die Pipeline-Anbindung für GitLab stammt von GitLab und steht in Kapitel 29. Im Terminal hat Anthropic GitLab seit August 2026 Schritt für Schritt nachgezogen (Versionsliste (externe Seite, code.claude.com)):

• 2.1.232 vom 13.08.2026: Marktplätze für Plugins auf gitlab.com lassen sich klonen wie die auf github.com.
• 2.1.233 vom 14.08.2026: --worktree nimmt die Adresse eines Merge Requests. Was dabei passiert, zeigt Kapitel 21.
• 2.1.257 vom 01.09.2026: /code-review --comment schreibt seine Befunde über glab mr note an einen Merge Request.
• 2.1.259 vom 02.09.2026: Claude Code erkennt glab mr create, merge, close, reopen, note und update und zeigt den Merge Request als MR !N. In einem Repository auf GitLab erklärt /install-github-app seither, dass es nur für GitHub gilt, und verweist auf die Doku zu GitLab CI/CD.
• 2.1.260 vom 03.09.2026: Ein Verweis wie owner/repo#123 führt in einem Repository auf GitLab zum Issue auf gitlab.com.

Die Anbindungen an GitHub und GitLab sind seit Mai 2025 in kleinen Schritten gewachsen, über das Terminal, die Cloud und die Desktop-App verteilt. Diese Ebene ordnet sie nach Datum und stellt die Wege zum Pull Request nebeneinander. Am Ende steht, was die Doku für Hosts jenseits von GitHub und GitLab hergibt.

Wie die Anbindungen dazukamen

Quelle: Versionsliste (externe Seite, code.claude.com), Ankündigung vom 22.05.2025 (externe Seite, anthropic.com), Wochenbericht 13 (externe Seite, code.claude.com) und Wochenbericht 15 (externe Seite, code.claude.com), Stand 12.10.2026. Die Zeile vom 12.08.2026 stammt aus der Doku zu GitHub Actions.

Die Ankündigung vom 22.05.2025 nannte die Anbindung an GitHub ein Beispiel dafür, was sich mit dem neuen SDK bauen lässt. Der Auto-fix kam zuerst im Web und erst zwei Wochen später ins Terminal. Der Wochenbericht 15 sagt das ausdrücklich. Für /autofix-pr selbst hat die Versionsliste keinen Eintrag. Der Befehl taucht dort erst mit einer Korrektur in 2.1.161 vom 02.06.2026 auf.

Vier Wege am Pull Request

Neben der Sitzung im Terminal und der Cloud-Sitzung setzen vier Wege an einem Pull Request auf GitHub an. Sie unterscheiden sich darin, wo Claude läuft und was man dafür einrichtet:

Quelle: Her­stel­ler­do­ku­men­ta­tion zu GitHub Actions, Code Review (externe Seite, code.claude.com), Cloud-Sitzungen und Desktop-App, Stand 12.10.2026. Code Review beschreibt Kapitel 25.

Der Unterschied zeigt sich an den Kosten und an den Grenzen. Ein Lauf der Action verbraucht Minuten auf den Runnern von GitHub (Doku zu GitHub Actions (externe Seite, code.claude.com)). Dazu kommen die Token für Claude. Meldet man den Workflow mit einem Token aus dem eigenen Abo an, zählen sie auf das Abo statt auf die Abrechnung der API. Eine Cloud-Sitzung zählt auf das Kontingent des Tarifs (Doku zu Cloud-Sitzungen (externe Seite, code.claude.com)). Die Desktop-App kann für einen Pull Request das Auto-merge von GitHub einschalten, in einer lokalen Sitzung als Squash. Das Repository muss Auto-merge erlauben (Doku zur Desktop-App (externe Seite, code.claude.com)). Der Auto-fix in der Cloud reagiert auf Ereignisse von GitHub. Einen Konflikt mit dem Zielbranch meldet GitHub nicht, also sieht er ihn nicht.

Unter wessen Namen Claude schreibt

Die Wege unterscheiden sich auch darin, wer auf GitHub als Absender erscheint:

• Action: Ohne eigenes Token meldet sich die Action als GitHub-App von Claude an (Doku zu GitHub Actions (externe Seite, code.claude.com)). Übergibt man ihr das Standard-Token des Workflows, starten Claudes Commits keine weiteren Workflows, denn GitHub löst bei Commits mit diesem Token nichts aus. Die CI läuft dann auf Claudes Commits nicht.
• Auto-fix: Antworten auf Kommentare erscheinen unter dem eigenen Konto, jede mit dem Hinweis, dass Claude Code sie geschrieben hat (Doku zu Cloud-Sitzungen (externe Seite, code.claude.com)).
• Sitzung im Terminal: Commits laufen über das eigene Git, mit der Zeile Co-Authored-By darunter. Aus Cloud- und Remote-Control-Sitzungen kommt ein Link zur Sitzung dazu.

Gegen Schleifen sichert sich die Action selbst ab. Sie weist einen Bot als Auslöser zurück, solange er nicht ausdrücklich erlaubt ist. Beim Auto-fix nennt die Doku eine andere Gefahr. Seine Antworten stehen unter dem eigenen Konto und können eine Automatik auslösen, die auf Kommentare hört.

GitLab bekommt Claude Code von zwei Seiten

Für GitLab gibt es zwei Anbindungen mit zwei Urhebern. Die Pipeline-Anbindung pflegt GitLab, als Beta (Doku zu GitLab (externe Seite, code.claude.com)). Sie baut auf der Kommandozeile und dem Agent SDK auf. Sie läuft auf den Runnern des eigenen GitLab, mit dessen Schutz für Branches und Freigaben. Die Unterstützung im Terminal kommt von Anthropic und ist seit August 2026 gewachsen, wie die zweite Ebene zeigt. Eine Cloud-Sitzung liest ein Repository auf GitLab nur als Bündel. Pushen kann sie dorthin nichts.

Codex von OpenAI geht bei GitLab einen anderen Weg. Seine Anbindung läuft in der Cloud von Codex, als Beta in allen Tarifen von ChatGPT (Codex-Doku zu GitLab (externe Seite, learn.chatgpt.com)). Ein Kommentar @codex review an einem Merge Request startet einen Review. Für Aufgaben, die Code ändern, legt man je Projekt eine Umgebung an. Auch selbst betriebene GitLab-Instanzen lassen sich anbinden, über eine Vorlage, die ein Admin des Workspace einrichtet. Knöpfe wie das Anlegen eines Pull Requests in der Desktop-App von Codex gehören nicht zu dieser Beta.

Auf GitHub kennen beide die Erwähnung im Kommentar. Bei Codex startet @codex mit einer anderen Bitte als einem Review einen Chat in der Cloud von Codex, mit dem Pull Request als Kontext. Die Doku führt diesen Chat als ältere Form (Codex-Doku zu GitHub (externe Seite, learn.chatgpt.com)). Claude Code läuft für @claude im Workflow des Repositorys. Das kostet Minuten von GitHub Actions. Dafür arbeitet Claude in der Umgebung, die der Workflow aufbaut. Der Schritt actions/checkout legt dort eine lokale Kopie des Repositorys an (Doku zu GitHub Actions (externe Seite, code.claude.com)).

Forgejo, Gitea und andere Hosts

Forgejo kommt in der Doku von Claude Code nicht vor, Stand 12.10.2026. Gitea erscheint in zwei Tabellen. In der einen steht, dass ein Verweis wie owner/repo#123 in einem Repository auf codeberg.org oder gitea.com als Text stehen bleibt (Doku zum interaktiven Modus (externe Seite, code.claude.com)). Ein Host, der dort gar nicht genannt ist, bekommt Links nach dem Muster von GitHub. Die andere Tabelle betrifft die Telemetrie. Mit OTEL_METRICS_INCLUDE_REPOSITORY=true versieht Claude Code seit Version 2.1.269 Messwerte mit dem Repository (Doku zum Monitoring (externe Seite, code.claude.com)). Als Anbieter erkennt es dabei auch Gitea.

Für einen eigenen Server bleibt damit das Terminal. Commits, Branches und Push laufen über Git. Für Pull Requests beschreibt die Doku die Kommandozeilen gh und glab. Cloud-Sitzungen lesen ein solches Repository mit CCR_FORCE_BUNDLE=1 als Bündel und schreiben nichts zurück. Auto-fix und Code Review setzen GitHub voraus, @claude dazu GitHub oder eine Pipeline von GitLab mit einem eigenen Dienst für Kommentare.

Was offen bleibt

• Seit wann GHES unterstützt wird, sagt keine der Quellen. In der Versionsliste erscheint GitHub Enterprise Server zuerst mit einer Korrektur in 2.1.267 vom 09.09.2026.
• Wann /pr-comments entfiel, steht nur in der Befehlsreferenz (2.1.91 vom 02.04.2026). Die Versionsliste nennt die Streichung nicht.
• Ob Claude in einer gewöhnlichen Sitzung von sich aus committet, regeln die eingebauten Anweisungen. Ihren Wortlaut gibt die Doku nicht wieder. Für Hintergrund-Sitzungen in der Agent View ist es beschrieben: Hat eine solche Sitzung in einem Worktree, den Claude betreten hat, Code geändert, soll Claude die Arbeit vor dem Ende sichern (Doku zur Agent View (externe Seite, code.claude.com)). Dann committet Claude ohne Rückfrage und pusht den Branch, wenn das Repository einen Remote hat. Mehr dazu in Kapitel 21.
• Für Hilfe bei der Pipeline-Anbindung verweist die Doku auf ein Issue bei GitLab. Wie schnell die Beta dort nachzieht, ist offen.