Claude Code est né dans un monde très GitHub : liaison des sessions aux pull requests, application GitHub, marketplaces de plugins sur github.com, protection de la configuration de la CLI gh… Pour les équipes qui travaillent sur GitLab, et elles sont nombreuses, notamment en Europe et dans les entreprises qui auto-hébergent leur forge, l'expérience était moins complète.
Les versions 2.1.232 à 2.1.234, publiées du 13 au 17 août, comblent une bonne partie de cet écart. Tour d'horizon.
En 2.1.233 (14 août), l'option --worktree accepte désormais une URL de merge request GitLab. Comme pour une pull request GitHub, Claude Code peut démarrer directement dans un worktree isolé sur la branche de la merge request :
claude --worktree https://gitlab.com/mon-groupe/mon-projet/-/merge_requests/42
Idéal pour relire ou reprendre une merge request sans toucher à ta branche de travail : tu ouvres, tu testes, tu corriges, et ton dépôt principal reste intact.
Toujours en 2.1.233, la vue claude agents prend en charge les merge requests GitLab, affichées avec la notation GitLab habituelle : !N. Quand tu fais tourner plusieurs sessions en parallèle, tu vois d'un coup d'œil quelle session travaille sur quelle merge request.
En 2.1.234 (17 août), un badge de merge request apparaît dans le pied de page et la status line. Il suffit d'un dépôt avec un remote GitLab et de la CLI glab authentifiée. Le badge affiche MR !N avec son état : brouillon, en attente ou au vert.
Si tu n'utilises pas encore glab, la CLI officielle de GitLab, c'est le moment : c'est elle qui permet à Claude Code de connaître l'état de tes merge requests.
C'est la partie la moins visible, mais peut-être la plus importante. En 2.1.232 (13 août), Claude Code ajoute le masquage des secrets pour les familles de jetons GitLab :
- les jetons de runners, d'OAuth, de déclenchement de pipelines, d'agents, de flux et d'autres types (préfixes
glrt-, gloas-, glptt-, glagent-, glimt-, glsoat-, glcbt-, glft-, glffct-) ;
- et un masquage complet des jetons d'accès personnels (
glpat-) et des jetons de déploiement (gldt-).
Concrètement, si un de ces jetons apparaît dans une sortie de commande ou un fichier lu par Claude, il est désormais masqué (redaction) par Claude Code.
Autre protection : le magasin de configuration de la CLI glab bénéficie désormais des mêmes protections de sandbox et de chemins d'identifiants que celui de la CLI gh. Autrement dit, les commandes sandboxées ne peuvent pas aller lire tes identifiants GitLab plus facilement que tes identifiants GitHub.
C'est cohérent avec les évolutions des derniers mois : sandbox.credentials en juin, le mode mask début août. La protection des secrets devient un axe majeur de Claude Code, et elle s'étend maintenant à GitLab.
Toujours en 2.1.232, les marketplaces de plugins acceptent les dépôts gitlab.com : une URL de dépôt GitLab simple, y compris avec des sous-groupes imbriqués, se clone comme une URL github.com. Et en cas d'échec d'authentification, le message d'aide indique maintenant ton véritable hébergeur Git, au lieu de supposer GitHub.
Pour les équipes qui hébergent leurs plugins internes sur GitLab, c'est un frein de moins à la diffusion d'outils partagés.
Petit détail qui en dit long : depuis la 2.1.233, l'astuce qui propose d'installer l'application GitHub n'apparaît plus dans les dépôts dont le remote origin est sur gitlab.com ou bitbucket.org. Et l'astuce sur les marketplaces d'entreprise couvre désormais les forges Git internes qui ne sont pas GitHub.
Les autres nouveautés de la semaine
Quelques ajouts notables des versions 2.1.229 à 2.1.234 :
- 2.1.229 : les sessions du self-hosted runner prennent en charge les hooks fournis par le serveur, comme les environnements gérés ;
- 2.1.232 : de nouveaux réglages dans
/config, dont le traitement des messages venant de tes autres sessions (accepter, mettre en attente, refuser) ;
- 2.1.233 : une limite optionnelle de mémoire par cgroup pour les commandes Bash sur Linux (
CLAUDE_CODE_TOOL_MEMORY_LIMIT), pour qu'un build qui s'emballe ne bloque pas la session ;
- 2.1.233 :
CLAUDE_CODE_WEBFETCH_CACHE_TTL_MS pour régler la durée du cache des pages récupérées (15 minutes par défaut).
Avec ces nouveautés, un workflow simple de relecture devient possible entièrement depuis le terminal :
- Ouvre la merge request dans un worktree isolé avec
claude --worktree <URL de la MR>.
- Demande un résumé des changements, fichier par fichier, et des points à vérifier en priorité.
- Fais lancer les tests du projet dans le worktree, sans risque pour ta branche.
- Demande une revue ciblée : cas limites, sécurité, cohérence avec le reste du code.
- Rédige tes commentaires avec Claude, puis publie-les toi-même sur GitLab.
Et si tu fais plusieurs relectures en parallèle, Agent View te montre quelle session traite quelle merge request grâce à la notation !N.
- Mets à jour Claude Code.
- Installe et authentifie
glab pour profiter du badge de merge request.
- Essaie
--worktree avec une URL de merge request pour ta prochaine relecture.
- Active la sandbox : elle complète les protections des chemins d'identifiants de
glab.
- 2.1.233 : URL de merge request GitLab acceptée par
--worktree, et MR affichées !N dans Agent View.
- 2.1.234 : badge MR !N dans le pied de page et la status line, via
glab.
- 2.1.232 : masquage des jetons GitLab, protection de la configuration
glab, marketplaces de plugins sur gitlab.com.
- Claude Code devient nettement moins centré sur GitHub.
