Ce que révèle la fuite du code source de Claude Code

En mars 2026, un bug de build de Bun a inclus les source maps dans le paquet npm de Claude Code. Les fichiers .map contenaient l’intégralité du code source TypeScript en clair : chaque module, chaque commentaire, chaque nom de code interne.¹ Anthropic a rapidement retiré le paquet, mais la communauté avait déjà extrait et analysé les rouages internes.

La fuite du code source de Claude Code a révélé que le mode auto lance un classificateur Sonnet 4.6 distinct à chaque appel d’outil, que la sécurité bash repose sur 23 vérifications numérotées qui laissent deviner de véritables tentatives d’exploitation, et que le cache de prompts surveille 14 vecteurs de rupture au moyen de verrous persistants. Le code a également mis au jour des défenses anti-distillation fondées sur l’injection de faux outils, un module « undercover » qui efface les noms de code internes sans aucun moyen de le désactiver, et une coordination multi-agents entièrement implémentée sous forme d’instructions dans le prompt système plutôt que par un protocole dédié.

Ceci n’est pas un billet du genre « regardez ce qui a fuité ». Je maintiens le guide Claude Code le plus complet du web et je fais tourner par-dessus, au quotidien, 84 hooks, 43 compétences et 19 agents.² La fuite du code a répondu à des questions que je cherchais à percer depuis des mois par rétro-ingénierie comportementale. Ce qui suit est l’analyse d’un praticien : ce que le code révèle du fonctionnement réel de Claude Code, et ce que ces constats impliquent pour celles et ceux qui construisent par-dessus.

En bref : le code confirme que le mode auto lance un classificateur Sonnet 4.6 distinct à chaque appel d’outil (yoloClassifier.ts), que la sécurité bash compte 23 vérifications numérotées qui laissent deviner de véritables tentatives d’exploitation (bashSecurity.ts), que le cache de prompts surveille 14 vecteurs de rupture au moyen de verrous persistants, que la coordination multi-agents tient entièrement dans les instructions du prompt système, et que la détection de la frustration passe par des expressions régulières, non par une inférence LLM. La section Sous le capot du guide traite des conséquences pour les développeurs. Le billet ci-dessous détaille l’anatomie complète.

À retenir

• Pour les développeurs : le mode auto coûte une inférence de classificateur par appel d’outil. Intégrez cette surcharge à vos modèles de coûts pour les flux de travail autonomes. Vos hooks PreToolUse complètent la validation bash intégrée à 23 vérifications, mais ne la remplacent pas.
• Pour les utilisateurs avancés : le cache de prompts se rompt facilement, selon 14 vecteurs. Gardez votre CLAUDE.md stable au fil d’une même session. En cas de boucle de compaction, le système s’arrête après 3 échecs (le disjoncteur existe parce que les tentatives répétées de compaction gaspillaient autrefois 250 000 appels API par jour).
• Pour les chercheurs en sécurité : la profondeur du module de sécurité bash (2 592 lignes, défenses propres à Zsh) laisse deviner un historique de tentatives d’exploitation bien réelles. Derrière chaque vérification numérotée se cache une histoire.

1. Le classificateur du mode auto

Le fichier nommé en interne yoloClassifier.ts compte 1 495 lignes.³ Il implémente le système de permissions dit « mode auto » : le classificateur qui décide s’il faut autoriser, bloquer ou demander confirmation pour chaque appel d’outil.

Le constat clé : le mode auto n’est pas une consigne de prompt. C’est un appel de modèle distinct. Chaque invocation d’outil est évaluée par un classificateur Sonnet 4.6 qui vérifie si l’action correspond à l’intention exprimée par l’utilisateur, et pas seulement si la commande est « sûre » prise isolément. Le mode auto ajoute donc une inférence de classificateur par appel d’outil, ce qui introduit une latence et un coût bien réels.

Claude Code expose cinq modes de permission en interne :¹

Le disjoncteur du mode auto reflète celui qu’Anthropic a documenté publiquement : 3 blocages consécutifs ou 20 au total font basculer en manuel.⁴ Le code confirme qu’il s’agit d’une limite stricte, pas d’une simple recommandation.

2. Sécurité bash : 23 vérifications, des incidents bien réels

Le module de validation bash (bashSecurity.ts) s’étend sur 2 592 lignes et compte 23 vérifications de sécurité numérotées.¹ La profondeur est remarquable, et chaque vérification laisse deviner un incident réel à son origine.

Les défenses propres à Zsh sont notables. La plupart des outils de sécurité visent Bash. Or Claude Code tourne sous Zsh sur macOS (shell par défaut depuis Catalina), et le code montre qu’Anthropic a découvert des vecteurs d’attaque propres à la sémantique d’expansion de Zsh. L’expansion =cmd, par exemple, est une fonctionnalité de Zsh qui remplace =curl par le chemin complet vers curl : une substitution capable de contourner les listes de blocage naïves.

Pour ceux qui écrivent des hooks : vos hooks PreToolUse s’exécutent après ces 23 vérifications. Vous ajoutez une seconde couche, pas la seule. Les vérifications intégrées traitent les attaques au niveau du shell, que vos hooks applicatifs laisseraient passer.

3. Les défenses anti-distillation

Le code révèle des défenses actives contre l’extraction de données d’entraînement :¹

Injection de faux outils. Lorsque le drapeau ANTI_DISTILLATION_CC est activé, Claude Code injecte de fausses définitions d’outils dans la conversation. Ces leurres empoisonnent toute donnée d’entraînement moissonnée dans la session. Un modèle entraîné sur ces données apprendrait des schémas d’outils erronés.

Résumé du texte de liaison. Une seconde défense met en tampon le texte de l’assistant entre les appels d’outils et renvoie des résumés cryptographiques à la place du texte brut. Ces résumés rendent les transcriptions de conversation inutilisables pour la distillation tout en préservant l’expérience utilisateur.

Ces deux défenses ont des contournements connus : un proxy MITM, une redéfinition de variables d’environnement ou le recours à des fournisseurs API tiers suffisent à les neutraliser.¹ Elles font office de ralentisseurs, pas de murs : elles augmentent le coût de la distillation sans l’empêcher tout à fait.

4. Le mode undercover

undercover.ts fait environ 90 lignes et présente une propriété notable : il n’existe aucun moyen de le désactiver.¹

Le module dissimule les noms de code internes (« Capybara », « Tengu »), les canaux Slack, les dépôts internes et les autres références à l’infrastructure d’Anthropic. Lorsque le modèle génère un texte contenant un nom de code, le module undercover le réécrit avant que l’utilisateur ne voie la sortie.

L’absence d’interrupteur signifie que le module tourne dans tous les contextes, y compris lorsque les employés d’Anthropic utilisent Claude Code. Le code révèle aussi que les commits rédigés par l’IA chez les employés d’Anthropic ne portent aucune attribution à l’IA dans leurs contributions open source, précisément parce que le module undercover en supprime les marqueurs.

5. La détection de la frustration

userPromptKeywords.ts détecte la frustration de l’utilisateur par correspondance d’expressions régulières sur les grossièretés.¹ Une expression régulière s’exécute en quelques microsecondes ; un appel de modèle prend plusieurs secondes. L’écart de rapidité et de coût explique ce choix de conception.

Une fois déclenché, il conduit Claude à ajuster son comportement : plus prudent, plus explicite, plus déférent. Si vous avez remarqué que Claude devient soudain plus circonspect après que vous avez exprimé votre agacement, le module de mots-clés en est le mécanisme. Ce basculement comportemental n’émerge pas du modèle : il est câblé dans la couche d’orchestration.

6. L’architecture du cache de prompts

promptCacheBreakDetection.ts surveille 14 vecteurs distincts de rupture de cache au moyen de « verrous persistants ».³ Un verrou persistant signifie qu’une fois qu’une action a rompu le cache, le système ne cherche pas à le rétablir. La rupture vaut pour le reste de la session.

Conséquences pratiques au quotidien :

• Réordonner les sections de votre CLAUDE.md rompt le cache
• Activer ou désactiver la réflexion étendue en cours de session rompt le cache
• Modifier la configuration des serveurs MCP rompt le cache
• Ajouter ou retirer des fichiers de règles rompt le cache

Ces 14 vecteurs expliquent un phénomène que beaucoup d’utilisateurs avancés ont constaté : des sessions rapides au départ qui ralentissent progressivement. Chaque changement de configuration accumule les ruptures de cache. La conception en « verrou persistant » implique que revenir en arrière ne répare rien. Une fois rompu, le cache le reste jusqu’à la fin de la session.

Bonne pratique : fixez votre CLAUDE.md, vos fichiers de règles et votre configuration MCP avant de démarrer une session. Ne les modifiez pas en cours de route.

7. Le disjoncteur de l’autocompact

Un commentaire dans le code documente l’ampleur d’un problème passé :¹

« 1 279 sessions ont connu 50 échecs consécutifs ou plus de l’autocompact (jusqu’à 3 272 dans une seule session), gaspillant environ 250 000 appels API par jour. »

Le correctif : MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3. Après 3 échecs consécutifs de compaction, le système interrompt l’autocompact et remonte une erreur au lieu de brûler des tokens en silence.

Avant ce disjoncteur, une session coincée dans une boucle de compaction réessayait indéfiniment, chaque tentative consommant des tokens pour le prompt de compaction et sa réponse. À grande échelle, 250 000 appels API gaspillés par jour représentent un coût d’infrastructure considérable. Le correctif tient en trois lignes et économise des millions de tokens chaque jour.

Si vous rencontrez des erreurs répétées de type « échec de la compaction », le disjoncteur vous protège d’une boucle infinie ; il ne dysfonctionne pas.

8. Le mode coordinateur : le prompt comme architecture

La coordination multi-agents (coordinatorMode.ts) tient entièrement dans les instructions du prompt système, sans orchestration au niveau du code.³ Le modèle orchestrateur reçoit un prompt décrivant la manière de déléguer, d’agréger et de synthétiser. Les agents subordonnés ne sont pas des processus particuliers : ce sont des instances de Claude dotées de prompts système différents.

Cette conception valide le motif du « prompt comme architecture », que les praticiens ont mis au point de leur côté. Le système de hooks que je décris dans Anatomie d’une griffe suit la même approche : répartiteurs, compétences et agents opèrent via des instructions de prompt, non par un flux de contrôle codé en dur.

Une directive du prompt du coordinateur mérite d’être relevée :

« N’écrivez jamais “d’après vos conclusions” : ces formules délèguent la compréhension aux exécutants au lieu de la prendre en charge vous-même. »

Cette directive fait office de seuil de qualité inscrit dans le prompt d’orchestration. Le coordinateur doit synthétiser, pas transmettre. Le principe vaut pour tout système multi-agents : si l’orchestrateur se contente de faire circuler les messages entre spécialistes, il n’apporte rien.

9. KAIROS : l’agent autonome jamais publié

Le code contient des références à une fonctionnalité non publiée nommée KAIROS : un agent autonome doté d’une mémoire persistante.¹

Ses principaux composants : - Une compétence /dream pour la distillation nocturne de la mémoire - Des journaux quotidiens en ajout seul - Des webhooks GitHub pour un contexte tenant compte du dépôt - Un démon d’arrière-plan avec rafraîchissement cron toutes les 5 minutes - Des drapeaux de fonctionnalité qui en empêchent l’activation

KAIROS ressemble à la réponse d’Anthropic aux assistants-agents persistants, toujours actifs. La compétence /dream est particulièrement intrigante : elle suppose un modèle qui traite et consolide sa mémoire pendant les périodes d’inactivité, à la manière de la consolidation mnésique humaine durant le sommeil.

Les drapeaux de fonctionnalité en bloquent l’activation, et Anthropic n’a pas publié KAIROS. Mais sa présence dans le code indique la direction prise : Claude Code passe d’un outil organisé par sessions à un agent persistant, conscient de ce qui se passe en arrière-plan.

10. Le système d’animal de compagnie

L’une des découvertes les plus surprenantes : Claude Code embarque un système d’animal de compagnie.¹

Chaque animal est déterministe, dérivé d’un hachage de l’identifiant utilisateur via Mulberry32, décrit dans le code comme « assez bon pour choisir des canards ». Chaque animal possède 5 statistiques (DEBUGGING, PATIENCE, CHAOS, WISDOM, SNARK) et un niveau de rareté :

Le système affiche les animaux sous forme de sprites ASCII de 5x12 avec des animations de 3 images. Le code encode les noms de code des espèces en hexadécimal, car l’un d’eux entre en collision avec le nom d’un modèle non publié.

Ce système n’est pas une plaisanterie : c’est un mécanisme de fidélisation. L’attribution déterministe garantit que votre animal reste toujours le même, ce qui crée de l’attachement. Le système de rareté, lui, crée une monnaie sociale. Et le rendu ASCII n’impose aucune charge de performance. Anthropic a conçu un dispositif d’engagement bien pensé, puis l’a dissimulé dans un outil de développement.

11. La fork bomb

Un incident survenu dans la communauté illustre les risques du système de hooks.⁵ Un développeur a créé un hook SessionStart qui lançait 2 instances de Claude Code. Chaque instance ainsi lancée déclenchait à nouveau le hook, d’où une croissance exponentielle : 1 → 2 → 4 → 8 → 16 → 2^N.

Au matin, des centaines d’instances de Claude Code tournaient simultanément. Le système a échappé à une facture API colossale par un mécanisme ironique : la consommation mémoire de chaque instance (Bun, React, TUI) a fait geler la machine avant que la facturation ne s’emballe.

La leçon pour qui écrit des hooks : les hooks SessionStart doivent être idempotents. Si le vôtre lance des processus, ces processus ne doivent pas déclencher le même hook à leur tour. Une variable de garde, un fichier PID ou un drapeau d’environnement suffit à prévenir la récursion.

Ce qu’il faut en retenir

La fuite du code a confirmé ce que les praticiens avaient déduit du comportement observé : Claude Code n’est pas une fine surcouche autour d’un appel API. C’est un véritable système d’ingénierie, avec ses couches de sécurité, ses optimisations de performance, ses ajustements comportementaux et ses fonctionnalités non publiées qui trahissent la feuille de route du produit.

Pour qui construit par-dessus, les implications essentielles figurent dans la section Sous le capot du guide. Pour tous les autres, cette fuite offre une visibilité rare sur le fonctionnement réel d’un outil d’IA en production : non pas ce qu’en dit le marketing, mais ce qu’en fait le code.

Le constat le plus important est aussi le plus simple : le système est plus complexe qu’il n’y paraît, et cette complexité a ses raisons. Les 23 vérifications de sécurité bash existent parce que 23 vecteurs d’attaque ont été découverts. Le disjoncteur de l’autocompact existe parce que 250 000 appels API étaient gaspillés chaque jour. Le module undercover existe parce que les noms de code finissent par filtrer. Derrière chaque ligne de code défensif, il y a une histoire.

Sources

Questions fréquentes

Le code source de Claude Code est-il toujours accessible ?

Non. Anthropic a retiré la version concernée du paquet npm peu après la découverte des source maps. L’analyse de ce billet s’appuie sur la documentation communautaire du code, établie avant son retrait.

Cette fuite compromet-elle la sécurité de Claude Code ?

Les constats liés à la sécurité (validation bash, système de permissions) décrivent des mécanismes de défense, pas des vulnérabilités. Savoir comment fonctionnent les vérifications de sécurité bash ne les rend pas plus faciles à contourner, car elles sont déterministes et ne reposent pas sur le secret de leur fonctionnement.

Dois-je changer ma façon d’utiliser Claude Code à la lumière de ces constats ?

Le constat le plus directement exploitable concerne la fragilité du cache de prompts. Si vous modifiez CLAUDE.md, vos fichiers de règles ou vos configurations MCP en cours de session, vous rompez le cache de prompts. Fixez votre configuration avant de démarrer une session.

Qu’est-ce que KAIROS ?

Une fonctionnalité d’agent autonome non publiée, découverte dans le code. Elle comprend une mémoire persistante, une distillation nocturne et un traitement en arrière-plan. Elle est verrouillée par un drapeau de fonctionnalité et n’est pas accessible aux utilisateurs.