Que met Claude Code dans vos commits ?

Ce que Claude Code ajoute dans un commit

Claude Code ajoute un trailer Co-authored-by: à la fin des messages de commit qu’il rédige, ainsi qu’une ligne d’attribution dans les descriptions des pull requests qu’il ouvre. Les sessions exécutées dans le cloud ou via Remote Control ajoutent également un lien vers la session sur claude.ai. Tout cela est du texte brut stocké dans votre historique Git. Dès que vous le poussez vers un dépôt public, il devient public et y reste jusqu’à ce que quelqu’un réécrive l’historique.

La formulation exacte a changé selon les releases. Ne faites donc pas confiance à une copie du trailer reproduite dans un guide, y compris celui-ci. Lisez plutôt vos propres commits. Les commandes git ci-dessous constituent la partie durable de ce sujet : la gestion des trailers par git fonctionne de la même manière depuis des années et continuera de fonctionner ainsi même si la prochaine release modifie le texte.

Ce qu’est réellement un trailer Git

Un trailer est une ligne au format Token: value située dans le dernier bloc du message de commit. Git ne fournit aucune liste prédéfinie de tokens. Signed-off-by:, Reviewed-by:, Fixes: et Co-authored-by: sont des conventions fondées sur le même mécanisme. Un forge, c’est-à-dire le site qui héberge le dépôt, comme GitHub ou GitLab, les lit pour déterminer ce qui doit être affiché sur la page du commit.

Git impose un emplacement précis à ce bloc. La documentation de git interpret-trailers indique que le groupe doit être précédé d’une ou plusieurs lignes vides, se trouver à la fin du message ou immédiatement avant une ligne commençant par ---, et être composé uniquement de trailers ou « contenir au moins un trailer généré par Git ou configuré par l’utilisateur et être composé d’au moins 25 % de trailers ».

Cette dernière règle est importante ici. Une URL seule ou une ligne de texte dans le bloc final n’est pas un trailer. Un nombre suffisant de lignes qui ne sont pas des trailers empêche alors l’interprétation de l’ensemble du bloc comme un groupe de trailers. C’est pourquoi un commit peut sembler contenir une ligne Co-authored-by:, alors que tous les outils qui lisent correctement les trailers n’y trouvent rien.

Comment lire les trailers déjà présents dans mon historique ?

Commencez par le message brut du commit le plus récent.

git log -1 --format=%B

%B affiche le sujet et le corps exactement tels qu’ils sont enregistrés, sans retour à la ligne automatique ni reformatage. Cette sortie fait foi. Tout ce qu’une forge vous affiche est une représentation de ce contenu.

Demandez ensuite à git quelles lignes il considère comme des trailers.

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

--parse est un raccourci pour --only-trailers --only-input --unfold. La sortie contient donc uniquement le bloc de trailers. Le résultat attendu contient une ligne par trailer. Une sortie vide alors qu’une ligne Co-authored-by: est clairement visible signifie que le bloc ne respecte pas les règles de positionnement indiquées plus haut.

Pour parcourir tout l’historique, recherchez le trailer par clé.

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

Les anciennes versions de git ne prennent pas en charge l’option key= avec %(trailers). Une recherche dans le texte du message fonctionne partout.

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

--grep recherche dans le message du commit et -i ignore la casse. C’est important, car la capitalisation de ce trailer n’est pas cohérente entre les différents outils. Avant un push, limitez la recherche aux éléments que vous n’avez pas encore envoyés.

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

Ces commits sont encore locaux. Vous pouvez donc encore les modifier facilement.

Que fait Co-authored-by: pour l’attribution sur GitHub ?

GitHub lit le trailer et affiche un second auteur sur la page du commit. Il associe cet auteur à un profil uniquement lorsque l’adresse e-mail appartient à un compte. La documentation de GitHub indique que les commits apparaissent dans le graphique des contributions lorsqu’ils sont « créés avec une adresse e-mail associée à votre compte GitHub ». Une adresse qui n’appartient à personne ne peut donc pas être associée à un profil. Pour un binôme humain, c’est précisément l’objectif : l’adresse de votre collègue est associée à son compte, et le commit est comptabilisé pour vous deux. Lorsqu’aucun compte ne possède l’adresse, le trailer modifie ce qui est affiché sur la page du commit, mais ne modifie pas la liste des contributeurs du dépôt.

Git ignore complètement le trailer. git shortlog -sn et git log --author lisent l’en-tête de l’auteur, qui contient votre nom et votre adresse e-mail. Aucun décompte local n’affichera donc le co-auteur. Ici, l’attribution est une fonctionnalité de forge ajoutée à une convention en texte brut. C’est la distinction entre git lui-même et la forge sur laquelle vous l’hébergez.

Le lien de session est un autre problème

Un trailer mentionne un coauteur. Une URL de session pointe vers une transcription. La référence de configuration de Claude Code décrit attribution.sessionUrl comme la clé qui omet « le lien de session claude.ai des commits Cloud et Remote Control ». Cela indique également l’origine du lien : les sessions sur le Web et les sessions pilotées via Remote Control.

Le lien n’est pas un identifiant d’authentification. La possibilité pour quelqu’un d’ouvrir cette session dépend de l’accès au compte, et non du fait que l’URL reste inconnue. La raison de l’exclure d’un dépôt public est plus simple. Il s’agit d’un texte public permanent qui contient l’identifiant d’une session interne et qui pointe vers une transcription de travail qui n’a jamais été destinée à un public. Dans un dépôt privé, l’argument inverse s’applique, car un reviewer peut suivre le lien et lire comment la modification a été réalisée. L’emplacement de ces transcriptions et leur durée de conservation sont expliqués dans comment Claude Code stocke les sessions et les reprend.

Paramètres qui contrôlent l’attribution des commits dans Claude Code

Vérifiés dans la référence des paramètres de Claude Code le 1 septembre 2026, ces clés sont documentées sous le titre « Git and attribution » :

• attribution : « Personnaliser l’attribution que Claude Code ajoute aux commits et aux pull requests »
• attribution.commit : « Modifier ou masquer le trailer que Claude Code ajoute aux commits »
• attribution.pr : « Modifier ou masquer la ligne d’attribution dans les descriptions des pull requests »
• attribution.sessionUrl : « Omettre le lien de session claude.ai des commits cloud et Remote Control »
• includeGitInstructions : « Supprimer les instructions intégrées concernant les commits et les pull requests du system prompt »
• includeCoAuthoredBy : marquée comme obsolète, avec la note « utilisez attribution pour masquer ou modifier l’attribution des commits et des pull requests »

Prenez la valeur acceptée par chaque clé dans sa propre entrée de la référence des paramètres, et non dans un guide. Les noms des clés sont stables. Les valeurs acceptées et les valeurs par défaut peuvent changer. Un fichier de paramètres dont la clé est correcte, mais dont la valeur est incorrecte, échoue silencieusement.

L’emplacement du paramètre détermine les utilisateurs concernés. ~/.claude/settings.json s’applique à chaque projet que vous ouvrez. Un fichier .claude/settings.json commité à la racine du dépôt est transmis à toutes les personnes qui le clonent. .claude/settings.local.json vous appartient dans ce projet uniquement. Claude Code l’ajoute à vos exclusions Git globales lors de la première écriture du fichier, afin qu’il ne soit pas inclus dans vos commits. L’ordre de priorité est le suivant : paramètres gérés, ligne de commande, paramètres locaux du projet, paramètres partagés du projet, puis paramètres utilisateur. Le fichier local d’un membre de l’équipe a donc priorité sur le fichier que vous avez commité. Considérez ainsi un paramètre commité comme une valeur par défaut, et non comme une garantie.

Vérifiez ensuite le résultat, car la valeur d’un paramètre que vous pensez avoir défini ne constitue pas une preuve. Demandez à Claude Code de créer le prochain commit selon son fonctionnement habituel, puis vérifiez le résultat.

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

Si le trailer apparaît toujours, la modification n’a pas été prise en compte par la session. Vérifiez le fichier que vous avez modifié ainsi que l’ordre de priorité indiqué ci-dessus avant de conclure que la clé est défectueuse.

Les contrôles qui ne dépendent pas d’un réglage

Un réglage configure un outil. Une règle du dépôt doit résister à l’utilisation d’un autre outil par un contributeur, ou à l’absence totale d’agent. Git fournit un emplacement pour cette règle : le hook commit-msg reçoit le chemin du fichier de message comme premier argument. Il peut modifier ce fichier ou refuser directement le commit.

#!/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

Le premier grep s’arrête immédiatement lorsqu’il n’y a rien à faire. Un commit normal ne coûte donc presque rien. Le second réécrit le message sans la ligne correspondante. Faites correspondre un token exact plutôt que tous les trailers, car un filtre écrit sous la forme « supprimer le dernier bloc » supprimerait aussi une ligne Signed-off-by: requise par le projet.

.git/hooks ne fait pas partie du dépôt. Un hook que vous y placez n’est donc jamais transmis aux autres. core.hooksPath indique à git un répertoire que vous pouvez versionner, mais chaque personne doit tout de même exécuter elle-même cette ligne git config. Git ne le configurera pas à sa place. C’est intentionnel : un dépôt qui pourrait installer ses propres exécutables lors d’un clone permettrait d’exécuter du code sur votre machine.

Pour refuser le commit au lieu de le réécrire, affichez un message sur la sortie d’erreur standard et exit 1 depuis le hook. Refuser est le choix honnête dans un dépôt partagé, car modifier silencieusement le message d’un commit masque la règle au lieu de l’expliquer. Il s’agit d’une couche différente des hooks propres à l’agent, qui s’exécutent lors d’un appel d’outil, avant même l’intervention de git. La correspondance d’un hook Claude Code avec un outil et son blocage traite cet aspect.

Aucune de ces solutions ne s’applique à une pull request provenant d’un fork, car le hook se trouve sur une machine que vous ne contrôlez pas. Un contrôle dans la CI (intégration continue) est la seule couche qui voit chaque commit avant sa fusion.

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

Écrivez également la règle, en plus de l’appliquer. Un fichier AGENTS.md placé à côté d’un fichier CONTRIBUTING.md lisible par les humains transmet la même consigne à l’agent et à la personne. Le contrôle CI est ce qui garantit son respect.

Supprimer le trailer avant le push

Pour le commit que vous venez de créer :

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

-F - lit le nouveau message depuis l’entrée standard. Git supprime les lignes vides au début et à la fin d’un message fourni de cette manière. La ligne vide laissée par le trailer supprimé disparaît donc automatiquement. Relisez le résultat avec git log -1 --format=%B avant de continuer.

Pour plusieurs commits d’une branche, lancez un rebase interactif sur la branche dans laquelle vous allez fusionner la vôtre, puis marquez chaque message à modifier avec reword.

git rebase -i origin/main

Chaque commit situé à partir du premier commit modifié reçoit un nouveau hash, car le hash d’un commit dépend de son message et de son parent. Cette opération est sans conséquence lorsque les commits sont encore locaux, mais elle devient coûteuse dès qu’ils ne le sont plus.

Supprimer le trailer après l’avoir poussé

Sur une branche que vous êtes le seul à utiliser, réécrivez l’historique comme indiqué plus haut, puis poussez-le en le remplaçant.

git push --force-with-lease

--force-with-lease refuse le push si le dépôt distant a évolué depuis votre dernier fetch. Il ne peut donc pas supprimer silencieusement un commit ajouté par quelqu’un d’autre. --force utilisé seul n’effectue pas ce contrôle.

Pour un trailer présent dans un historique volumineux, git filter-repo réécrit tous les messages en une seule passe. Exécutez le clone depuis votre copie de travail existante afin que l’URL provienne du remote déjà configuré.

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"))
'

Le callback reçoit chaque message sous forme d’octets et renvoie le message à enregistrer. C’est pourquoi chaque chaîne qu’il contient porte un préfixe b. filter-repo refuse de s’exécuter sur un dépôt qui n’est pas un clone fraîchement créé, sauf si vous transmettez --force. À la fin, il supprime le remote origin afin que vous ne puissiez pas repousser accidentellement la réécriture. Ajoutez de nouveau le remote délibérément, effectuez un force-push, puis demandez à tout le monde de cloner à nouveau le dépôt, car tous les hash qu’ils possèdent sont désormais incorrects.

Soyez clair sur ce qu’une réécriture ne peut pas faire. Elle modifie votre copie du dépôt. Elle ne modifie pas les forks, les clones existants, les miroirs, les pages de pull request qui citaient déjà le message ni un index de recherche de code qui a exploré votre dépôt la semaine dernière. Pour un secret divulgué, la correction consiste à faire tourner le secret ; la réécriture sert au nettoyage. Un trailer de divulgation n’est pas un secret. Évaluez donc le coût d’une réécriture de tout l’historique, car toutes les pull requests ouvertes devront être reconstruites.

Ce qu’attend le reviewer en face

Les mainteneurs ne sont pas d’accord sur ce point. C’est précisément pourquoi vous devez vérifier avant de supprimer quoi que ce soit. Certains projets veulent conserver la mention et vous demanderont de la remettre, car un reviewer n’examine pas de la même manière un patch écrit par une machine. D’autres l’interdisent, souvent à cause de la question de l’auteur légal de la modification. Les projets qui utilisent un DCO (developer certificate of origin) exigent une ligne Signed-off-by:. Cette ligne affirme que vous avez le droit de soumettre le code. Un filtre de messages mal conçu supprime cette ligne en même temps que l’attribution.

Lisez d’abord CONTRIBUTING.md. Si le projet ne précise rien, choisissez une règle pour le dépôt et documentez-la. Un trailer présent sur la moitié des commits est pire que l’une ou l’autre des deux options. Il donne l’impression qu’un même historique appartient à deux projets.

Si vous exécutez l’agent sur un serveur plutôt que sur votre laptop, la même question se pose à un niveau inférieur. Exécuter Claude Code sur un VPS avec son propre compte détermine les dépôts auxquels il peut accéder. Ce qu’un agent de codage envoie hors de la machine traite du trafic qui n’apparaît jamais dans un message de commit.

FAQ

Un trailer Co-authored-by pour Claude compte-t-il dans les statistiques de contributeurs de mon dépôt ?

Non. GitHub associe un commit à un profil à partir d’une adresse e-mail liée à un compte GitHub, puis comptabilise les contributions sur cette base. Une adresse qui n’est liée à aucun compte ne peut pas être associée à un profil. Le trailer modifie donc la page du commit, mais pas la liste des contributeurs. Git lui-même ne lit jamais les trailers pour cela. git shortlog -sn compte l’en-tête de l’auteur. Le co-auteur n’y apparaît donc jamais.

Comment trouver tous les commits qui contiennent déjà le trailer ?

git log -i --grep='^Co-authored-by:' --format='%h %an %s' les liste dans tout l’historique, sans tenir compte de la casse. Avec une version récente de git, git log --format='%h %(trailers:key=Co-authored-by,valueonly)' lit la valeur à l’aide de son propre analyseur de trailers au lieu de rechercher du texte brut. Pour afficher uniquement les commits qui n’ont pas encore été pushés, ajoutez une plage : git log origin/main..HEAD --format=%B.

Puis-je supprimer le trailer de commits déjà pushés ?

Oui, en réécrivant l’historique, mais le coût est réel. Sur une branche que vous êtes le seul à utiliser, faites un amend ou un rebase, puis git push --force-with-lease. Sur une branche partagée, chaque commit à partir du premier commit modifié reçoit un nouveau hash. Chaque clone et chaque pull request ouverte doivent donc être reconstruits. Une réécriture n’atteint jamais non plus les forks, les miroirs ni le clone créé hier par quelqu’un d’autre.

Le lien de session claude.ai dans un message de commit représente-t-il un risque de sécurité ?

Ce n’est pas un identifiant d’authentification. L’accès à la session dépend du compte, et non du fait que l’URL soit difficile à deviner. Le problème est qu’il s’agit d’un texte public permanent qui pointe vers une transcription rédigée comme des notes de travail. La documentation de référence de la configuration de Claude Code présente attribution.sessionUrl comme la clé qui omet ce lien des commits cloud et Remote Control. Un hook commit-msg le supprime de tout ce que cette configuration ne couvre pas.

Dois-je désactiver cette attribution ?

Cela dépend du dépôt, et non des préférences personnelles. Sur un projet public, suivez CONTRIBUTING.md. Un mainteneur qui souhaite conserver cette mention vous demandera de la rétablir. Dans un dépôt d’entreprise, conserver le trailer est souvent utile. Il indique à un reviewer, un an plus tard, pourquoi une modification a cette forme. Prenez une décision pour l’ensemble du dépôt et faites-la respecter dans la CI afin que l’historique reste cohérent.