Was Claude Code in Ihre Git-Commits schreibt

Was Claude Code in einen Commit schreibt

Claude Code fügt am Ende der von ihm erstellten Commit-Nachrichten einen Co-authored-by:-Trailer und den von ihm geöffneten Pull-Request-Beschreibungen eine Attribution-Zeile hinzu. Sitzungen, die in der Cloud oder über Remote Control ausgeführt werden, fügen außerdem einen Link zur Sitzung auf claude.ai hinzu. Alle diese Angaben sind Klartext und werden in Ihrer Git-Historie gespeichert. Sobald Sie sie in ein öffentliches Repository pushen, sind sie öffentlich. Dort bleiben sie, bis jemand die Historie neu schreibt.

Der genaue Wortlaut hat sich zwischen Releases geändert. Verlassen Sie sich daher nicht auf eine Kopie des Trailers, die in einer Anleitung abgedruckt ist, auch nicht in dieser. Lesen Sie stattdessen Ihre eigenen Commits. Die folgenden git-Befehle sind der dauerhafte Teil dieses Themas: Die Trailer-Verarbeitung von git funktioniert seit Jahren auf dieselbe Weise. Das bleibt auch dann so, wenn das nächste Release den Text ändert.

Was ein Git-Trailer tatsächlich ist

Ein Trailer ist eine Zeile in der Form Token: value im letzten Block einer Commit-Nachricht. Git enthält keine feste Liste von Tokens. Signed-off-by:, Reviewed-by:, Fixes: und Co-authored-by: sind Konventionen, die auf demselben Mechanismus basieren. Eine Forge, also die Website, auf der das Repository gehostet wird, etwa GitHub oder GitLab, liest diese Einträge und entscheidet, was auf einer Commit-Seite angezeigt wird.

Git stellt strenge Anforderungen an die Position dieses Blocks. Die Dokumentation zu git interpret-trailers besagt, dass der Block durch eine oder mehrere Leerzeilen eingeleitet werden muss, am Ende der Nachricht oder unmittelbar vor einer Zeile stehen muss, die mit --- beginnt, und entweder ausschließlich aus Trailern bestehen oder „mindestens einen von Git erzeugten oder vom Benutzer konfigurierten Trailer enthalten und zu mindestens 25% aus Trailern bestehen“ muss.

Die letzte Regel ist hier entscheidend. Eine alleinstehende URL oder eine Textzeile im letzten Block ist kein Trailer. Enthält der Block genügend Zeilen, die keine Trailer sind, wird der gesamte Block nicht als Trailer interpretiert. Deshalb kann ein Commit so aussehen, als enthalte er eine Co-authored-by:-Zeile, während jedes Tool, das Trailer korrekt ausliest, nichts findet.

Wie lese ich die Trailer aus, die bereits in meiner Historie vorhanden sind?

Beginnen Sie mit der unveränderten Nachricht des neuesten Commits.

git log -1 --format=%B

%B gibt Betreff und Text genau so aus, wie sie gespeichert sind, ohne Zeilenumbruch und ohne Neuformatierung. Diese Ausgabe ist die maßgebliche Quelle. Alles, was eine Forge anzeigt, ist eine Darstellung davon.

Fragen Sie Git nun, welche dieser Zeilen es als Trailer zählt.

git log -1 --format=%B | git interpret-trailers --parse

--parse ist eine Kurzform für --only-trailers --only-input --unfold. Die Ausgabe enthält daher ausschließlich den Trailer-Block. Bei einem korrekten Ergebnis wird pro Trailer eine Zeile ausgegeben. Eine leere Ausgabe, obwohl Sie eine Zeile mit Co-authored-by: eindeutig sehen, bedeutet, dass der Block die oben genannten Platzierungsregeln nicht erfüllt.

Um die gesamte Historie zu durchsuchen, fragen Sie den Trailer anhand seines Schlüssels ab.

git log --format='%h %(trailers:key=Co-authored-by,valueonly)'

Ältere Git-Versionen unterstützen die Option key= für %(trailers) nicht. Eine Suche im Nachrichtentext funktioniert überall.

git log -i --grep='^Co-authored-by:' --format='%h %an %s'

--grep berücksichtigt die Commit-Nachricht, und -i führt den Abgleich ohne Beachtung der Groß- und Kleinschreibung durch. Das ist wichtig, weil die Schreibweise dieses Trailers in verschiedenen Tools nicht einheitlich war. Prüfen Sie vor einem Push gezielt nur das, was Sie bisher noch nicht übertragen haben.

git log origin/main..HEAD --format=%B

Diese Commits sind noch lokal vorhanden. Sie können sie daher weiterhin mit geringem Aufwand ändern.

Was bewirkt Co-authored-by: für die Zuordnung auf GitHub?

GitHub liest den Trailer und zeigt auf der Commit-Seite einen zweiten Autor an. Dieser Autor wird nur dann mit einem Profil verknüpft, wenn die E-Mail-Adresse zu einem Konto gehört. In der eigenen Dokumentation erklärt GitHub, dass Commits im Beitragsdiagramm erscheinen, wenn sie „mit einer E-Mail-Adresse erstellt wurden, die mit Ihrem Konto auf GitHub verknüpft ist“. Eine Adresse, die niemandem gehört, kann daher keinem Profil zugeordnet werden. Bei zwei Personen ist genau das der Zweck: Die Adresse Ihres Kollegen ist mit dessen Konto verknüpft, und der Commit wird für Sie beide gezählt. Bei einer Adresse, die keinem Konto gehört, ändert der Trailer die Anzeige auf der Commit-Seite, die Liste der Repository-Beitragenden bleibt jedoch unverändert.

Git selbst ignoriert den Trailer vollständig. git shortlog -sn und git log --author lesen den Author-Header, der Ihren Namen und Ihre E-Mail-Adresse enthält. Eine lokale Statistik zeigt den Co-Autor daher nie an. Die Zuordnung ist hier eine Funktion der Forge, die auf einer einfachen Konvention für Textzeilen aufbaut. Das ist die Trennung zwischen git selbst und der Forge, auf der Sie es hosten.

Der Sitzungslink ist ein anderes Problem

Ein Trailer nennt einen Mitautor. Eine Sitzungs-URL verweist auf ein Transkript. Die Referenz zu den Claude-Code-Einstellungen dokumentiert attribution.sessionUrl als Schlüssel, der „the claude.ai session link from cloud and Remote Control commits“ auslässt. Daraus geht auch hervor, woher der Link stammt: aus Sitzungen im Web und aus Sitzungen, die über Remote Control gesteuert werden.

Der Link ist keine Zugangsinformation. Ob jemand diese Sitzung öffnen kann, wird durch den Kontozugriff bestimmt, nicht dadurch, dass die URL unbekannt bleibt. Der Grund, ihn aus einem öffentlichen Repository herauszuhalten, ist einfacher. Er ist dauerhaft öffentlich sichtbarer Text, der eine interne Sitzungs-ID nennt, und verweist auf ein Arbeitsprotokoll, das nie für ein Publikum erstellt wurde. Bei einem privaten Repository gilt das Gegenargument, weil ein Reviewer dem Link folgen und nachvollziehen kann, wie die Änderung entstanden ist. Wo diese Transkripte gespeichert werden und wie lange sie erhalten bleiben, wird unter wie Claude Code Sitzungen speichert und fortsetzt beschrieben.

Einstellungen für die Commit-Attribution von Claude Code

Abgeglichen mit der Einstellungsreferenz von Claude Code am 1. September 2026 sind diese Schlüssel unter der Überschrift „Git and attribution“ dokumentiert:

• attribution: „Anpassen der Attribution, die Claude Code zu Commits und Pull Requests hinzufügt“
• attribution.commit: „Ändern oder Ausblenden des Trailers, den Claude Code zu Commits hinzufügt“
• attribution.pr: „Ändern oder Ausblenden der Attribution-Zeile in Beschreibungen von Pull Requests“
• attribution.sessionUrl: „Auslassen des claude.ai-Sitzungslinks bei Cloud- und Remote-Control-Commits“
• includeGitInstructions: „Entfernen der integrierten Commit- und PR-Anweisungen aus dem System-Prompt“
• includeCoAuthoredBy: als veraltet markiert, mit dem Hinweis „attribution verwenden, um die Commit- und PR-Attribution auszublenden oder zu ändern“

Übernehmen Sie den zulässigen Wert jedes Schlüssels aus dem jeweiligen Eintrag in der Einstellungsreferenz, nicht aus einem Leitfaden. Die Schlüsselnamen sind stabil. Zulässige Werte und Standardwerte können sich ändern. Eine Einstellungsdatei mit korrekt geschriebenem Schlüssel, aber einem ungültigen Wert, schlägt still fehl.

Wo Sie die Einstellung eintragen, bestimmt, für wen sie gilt. ~/.claude/settings.json gilt für jedes Projekt, das Sie öffnen. Eine .claude/settings.json, die im obersten Verzeichnis des Repositorys versioniert wird, gilt für alle, die das Repository klonen. .claude/settings.local.json gilt nur für Sie in diesem einen Projekt. Claude Code fügt diese Datei beim ersten Schreiben zu Ihren globalen Git-Excludes hinzu, sodass sie nicht in Ihre Commits gelangt. Die Priorität gilt in dieser Reihenfolge: verwaltete Einstellungen, dann die Befehlszeile, dann lokale Projekteinstellungen, dann gemeinsam genutzte Projekteinstellungen und zuletzt Benutzereinstellungen. Die lokale Datei eines Teammitglieds hat daher Vorrang vor der von Ihnen versionierten Datei. Betrachten Sie eine versionierte Einstellung deshalb als Standard und nicht als Garantie.

Überprüfen Sie die Einstellung anschließend. Eine Einstellung, von deren Wirkung Sie ausgehen, ist kein Beleg. Lassen Sie Claude Code den nächsten Commit wie gewohnt erstellen, und lesen Sie das Ergebnis danach aus.

git log -1 --format=%B
git log -1 --format=%B | git interpret-trailers --parse

Wenn der Trailer weiterhin ausgegeben wird, ist die Änderung nicht in der Sitzung angekommen. Prüfen Sie, welche Datei Sie bearbeitet haben, und kontrollieren Sie die oben genannte Prioritätsreihenfolge, bevor Sie den Schlüssel als fehlerhaft einstufen.

Kontrollen, die nicht von einer Einstellung abhängen

Eine Einstellung konfiguriert ein einzelnes Tool. Eine Repository-Regel muss auch für einen Beitragenden gelten, der ein anderes Tool oder gar keinen Agenten verwendet. Git bietet einen Ort für diese Regel: Der commit-msg-Hook wird mit dem Pfad zur Nachrichtendatei als erstem Argument ausgeführt. Er kann diese Datei ändern oder den Commit vollständig ablehnen.

#!/bin/sh
# .githooks/commit-msg
grep -qi '^co-authored-by: claude' "$1" || exit 0
grep -vi '^co-authored-by: claude' "$1" > "$1.new" && mv "$1.new" "$1"

chmod +x .githooks/commit-msg
git config core.hooksPath .githooks

Der erste grep wird vorzeitig beendet, wenn nichts zu tun ist. Dadurch verursacht ein normaler Commit nahezu keinen Aufwand. Der zweite schreibt die Nachricht ohne die übereinstimmende Zeile zurück. Stimmen Sie mit einem exakten Token überein und nicht mit jedem Trailer. Ein Filter mit der Regel „den letzten Block entfernen“ würde auch eine Signed-off-by:-Zeile entfernen, die das Projekt möglicherweise voraussetzt.

.git/hooks gehört nicht zum Repository. Ein dort abgelegter Hook erreicht daher niemanden sonst. core.hooksPath weist Git auf ein Verzeichnis, das Sie committen können. Jede Person führt diese eine git config-Zeile trotzdem selbst aus. Git richtet dies nicht automatisch ein. Das ist beabsichtigt: Ein Repository, das beim Klonen eigene ausführbare Dateien installieren könnte, wäre eine Möglichkeit, Code auf Ihrem Rechner auszuführen.

Um den Commit abzulehnen, statt ihn umzuschreiben, geben Sie eine Meldung auf der Standardfehlerausgabe aus und führen Sie im Hook exit 1 aus. In einem gemeinsam verwendeten Repository ist die Ablehnung die transparente Wahl. Das stille Ändern der Commit-Nachricht verbirgt die Regel, statt sie zu vermitteln. Dies ist eine andere Ebene als die eigenen Hooks des Agenten. Diese werden bei einem Tool-Aufruf ausgelöst, bevor Git überhaupt beteiligt ist. Wie ein Claude-Code-Hook ein Tool erkennt und blockiert behandelt diese Seite.

Keine dieser Maßnahmen hilft bei einem Pull Request aus einem Fork, weil der Hook auf einem Rechner liegt, den Sie nicht kontrollieren. Eine Prüfung in der CI (Continuous Integration) ist die einzige Ebene, die jeden Commit vor dem Mergen sieht.

if git log --format=%B "origin/${BASE_BRANCH:-main}..HEAD" | grep -qi '^co-authored-by: claude'; then
  echo "Attribution trailer found. Rewrite the branch before merging." >&2
  exit 1
fi

Halten Sie die Regel zusätzlich schriftlich fest. Eine AGENTS.md neben einer für Menschen lesbaren CONTRIBUTING.md vermittelt dem Agenten und der Person dieselbe Vorgabe. Die CI-Prüfung stellt sicher, dass sie auch eingehalten wird.

Den Trailer vor dem Push entfernen

Für den gerade erstellten Commit:

git log -1 --format=%B | grep -vi '^co-authored-by: claude' | git commit --amend -F -

-F - liest die neue Nachricht von der Standardeingabe. Git entfernt führende und nachfolgende Leerzeilen aus einer auf diese Weise übergebenen Nachricht. Die durch den gelöschten Trailer entstandene Leerzeile verschwindet daher automatisch. Lesen Sie das Ergebnis mit git log -1 --format=%B erneut ein, bevor Sie fortfahren.

Für mehrere Commits auf einem Branch führen Sie ein interaktives Rebase auf den Branch aus, in den Sie mergen werden. Markieren Sie jede Nachricht, die Sie ändern möchten, mit reword.

git rebase -i origin/main

Jeder Commit ab dem frühesten bearbeiteten Commit erhält einen neuen Hash, weil der Hash eines Commits dessen Nachricht und Parent umfasst. Solange die Commits lokal sind, ist das unproblematisch. Sobald sie nicht mehr lokal sind, wird es aufwendig.

Trailer nach dem Push entfernen

In einem Branch, den nur Sie verwenden, schreiben Sie die Historie wie oben beschrieben um und pushen sie anschließend.

git push --force-with-lease

--force-with-lease verweigert den Push, wenn sich das Remote-Repository seit Ihrem letzten Fetch geändert hat. Dadurch kann ein Commit, den eine andere Person hinzugefügt hat, nicht unbemerkt verworfen werden. Ein einfaches --force führt diese Prüfung nicht durch.

Bei einem Trailer, der sich über eine lange Historie erstreckt, schreibt git filter-repo alle Nachrichten in einem Durchlauf um. Führen Sie den Clone innerhalb Ihrer vorhandenen Arbeitskopie aus. Dadurch wird die URL aus dem bereits vorhandenen Remote-Repository übernommen.

pip install git-filter-repo
git clone "$(git remote get-url origin)" ../project-rewrite
cd ../project-rewrite
git filter-repo --message-callback '
return b"\n".join(l for l in message.split(b"\n") if not l.lower().startswith(b"co-authored-by: claude"))
'

Der Callback erhält jede Nachricht als Bytes und gibt die zu speichernde Nachricht zurück. Deshalb enthält jeder String darin ein b-Präfix. filter-repo wird nicht für ein Repository ausgeführt, das kein frischer Clone ist, sofern Sie nicht --force übergeben. Nach Abschluss entfernt es das origin-Remote-Repository. Dadurch können Sie die umgeschriebene Historie nicht versehentlich zurückpushen. Fügen Sie das Remote-Repository anschließend bewusst wieder hinzu, führen Sie einen Force-Push durch und fordern Sie alle Beteiligten auf, das Repository neu zu klonen. Jeder Hash, den sie lokal besitzen, ist nun ungültig.

Beachten Sie genau, was ein Umschreiben nicht bewirken kann. Es ändert Ihre Kopie des Repositorys. Forks, vorhandene Clones, Mirrors, Pull-Request-Seiten, die die Nachricht bereits zitiert haben, oder einen Code-Suchindex, der letzte Woche auf Ihr Repository zugegriffen hat, erreicht es nicht. Bei einem offengelegten Secret besteht die eigentliche Lösung darin, das Secret zu rotieren. Das Umschreiben bereinigt nur die Historie. Ein Disclosure-Trailer ist kein Secret. Wägen Sie daher ein Umschreiben der gesamten Historie gegen den damit verbundenen Aufwand ab. Jeder offene Pull Request muss anschließend neu erstellt werden.

Was die Reviewenden auf der anderen Seite erwarten

Maintainer sind sich in diesem Punkt nicht einig. Genau deshalb sollten Sie prüfen, bevor Sie etwas entfernen. Einige Projekte wollen den Hinweis und bitten Sie, ihn wieder einzufügen, weil Reviewende einen von einer Maschine erstellten Patch anders bewerten. Andere Projekte untersagen ihn, häufig wegen der Frage, wer die Änderung rechtlich verfasst hat. Projekte mit einem DCO (Developer Certificate of Origin) verlangen eine Signed-off-by:-Zeile. Diese bestätigt, dass Sie berechtigt sind, den Code einzureichen. Ein unachtsamer Nachrichtenfilter entfernt sie zusammen mit der Namensnennung.

Lesen Sie zuerst CONTRIBUTING.md. Wenn das Projekt dazu nichts festlegt, wählen Sie eine Regel für das Repository und dokumentieren Sie sie. Ein Trailer, der nur in der Hälfte der Commits erscheint, ist schlechter als jede der beiden Optionen. Dadurch wirkt eine Historie wie die Historien zweier Projekte.

Wenn Sie den Agent auf einem Server statt auf Ihrem Laptop ausführen, stellt sich dieselbe Frage eine Ebene tiefer. Claude Code unter einem eigenen Konto auf einem VPS ausführen legt fest, auf welche Repositories der Agent überhaupt zugreifen kann. was ein Coding-Agent vom Rechner überträgt behandelt den Netzwerkverkehr, der in keiner Commit-Nachricht erscheint.

FAQ

Zählt ein Co-authored-by-Trailer für Claude in der Contributor-Statistik meines Repositorys?

Nein. GitHub ordnet einen Commit einem Profil anhand einer E-Mail-Adresse zu, die mit einem GitHub-Konto verknüpft ist, und zählt Beiträge auf dieser Grundlage. Eine Adresse, die zu keinem Konto gehört, kann nicht verknüpft werden. Daher ändert der Trailer zwar die Commit-Seite, die Liste der Contributors bleibt jedoch unverändert. Git selbst liest Trailer dafür nie aus. git shortlog -sn wertet den Author-Header aus, daher erscheint der Co-Author dort nicht.

Wie finde ich jeden Commit, der den Trailer bereits enthält?

git log -i --grep='^Co-authored-by:' --format='%h %an %s' listet sie in der gesamten Historie ohne Beachtung der Groß- und Kleinschreibung auf. Bei einem aktuellen git liest git log --format='%h %(trailers:key=Co-authored-by,valueonly)' den Wert über den eigenen Trailer-Parser von git aus, statt rohen Text abzugleichen. Um nur Commits anzuzeigen, die Sie noch nicht gepusht haben, fügen Sie einen Bereich hinzu: git log origin/main..HEAD --format=%B.

Kann ich den Trailer aus bereits gepushten Commits entfernen?

Ja, indem Sie die Historie umschreiben. Die Auswirkungen sind erheblich. Bei einem Branch, den nur Sie verwenden, ändern Sie den Commit mit amend oder führen ein rebase durch und verwenden anschließend git push --force-with-lease. Bei einem gemeinsam verwendeten Branch erhält jeder Commit ab dem frühesten bearbeiteten Commit einen neuen Hash. Daher müssen jeder Clone und jeder offene Pull Request neu erstellt werden. Eine Umschreibung erreicht außerdem niemals Forks, Mirrors oder einen Clone, den jemand gestern erstellt hat.

Ist der Link zur claude.ai-Sitzung in einer Commit-Nachricht ein Sicherheitsrisiko?

Er ist kein Zugangsdatenbestandteil. Ob auf die Sitzung zugegriffen werden kann, entscheidet das Konto und nicht die Schwierigkeit, die URL zu erraten. Das Problem besteht darin, dass es sich um dauerhaft öffentlich sichtbaren Text handelt, der auf ein als Arbeitsnotizen verfasstes Transkript verweist. Die Referenz zu den Claude-Code-Einstellungen dokumentiert attribution.sessionUrl als den Schlüssel, der diesen Link aus Cloud- und Remote-Control-Commits entfernt. Ein commit-msg-Hook entfernt ihn aus allen Commits, die von dieser Einstellung nicht erfasst werden.

Sollte ich die Attribution überhaupt deaktivieren?

Das hängt vom Repository ab, nicht vom persönlichen Geschmack. Befolgen Sie bei einem öffentlichen Projekt die Vorgaben in CONTRIBUTING.md, da ein Maintainer, der die Offenlegung verlangt, sie wieder aktivieren lassen wird. In einem Unternehmens-Repository ist der Trailer oft nützlich. Er zeigt einem Reviewer auch ein Jahr später, warum eine Änderung auf diese Weise umgesetzt wurde. Legen Sie die Entscheidung für das gesamte Repository einmal fest und setzen Sie sie in der CI durch, damit die Historie konsistent bleibt.