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

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

Ceci n’est pas un article « regardez ce qui a fuité ». Je maintiens le guide Claude Code le plus complet sur internet et j’utilise quotidiennement 84 hooks, 43 skills et 19 agents par-dessus.² La fuite du code source a répondu à des questions que je cherchais à résoudre par l’observation comportementale depuis des mois. Ce qui suit est une analyse de praticien : ce que le code source révèle sur le fonctionnement réel de Claude Code, et ce que cela signifie pour ceux qui construisent par-dessus.

En résumé : Le code source confirme que le mode auto exécute un classifieur Sonnet 4.6 distinct par appel d’outil (yoloClassifier.ts), que la sécurité bash comporte 23 vérifications numérotées suggérant de véritables incidents d’exploitation (bashSecurity.ts), que le cache de prompts suit 14 vecteurs de rupture avec des verrous persistants, que la coordination multi-agents est entièrement implémentée via des instructions de prompt système, et que la détection de frustration utilise des regex — pas de l’inférence LLM. La section Sous le capot du guide couvre les implications pour les constructeurs de harness. Cet article couvre l’anatomie complète.

Points clés

• Constructeurs de harness : Le mode auto coûte une inférence de classifieur par appel d’outil. Intégrez cela dans vos modèles de coûts pour les workflows autonomes. Vos hooks PreToolUse complètent mais ne remplacent pas la validation bash intégrée à 23 vérifications.
• Utilisateurs avancés : Le cache de prompts est fragile — 14 vecteurs peuvent le casser. Gardez votre CLAUDE.md stable au sein d’une session. Si vous rencontrez des boucles de compaction, le système s’arrête après 3 échecs (auparavant, il gaspillait environ 250 000 appels API/jour avant l’ajout du disjoncteur).
• Chercheurs en sécurité : La profondeur du module de sécurité bash (2 592 lignes, défenses spécifiques à Zsh) suggère un historique de véritables tentatives d’exploitation. Chaque vérification numérotée a une histoire derrière elle.

1. Le classifieur du mode auto

Le fichier nommé en interne yoloClassifier.ts fait 1 495 lignes.³ Il implémente le système de permissions du « mode auto » — le classifieur qui décide d’autoriser, bloquer ou demander confirmation pour chaque appel d’outil.

La découverte principale : le mode auto n’est pas une instruction de prompt. C’est un appel de modèle séparé. Chaque invocation d’outil est évaluée par un classifieur Sonnet 4.6 qui vérifie si l’action correspond à l’intention déclarée de l’utilisateur, et pas seulement si la commande est « sûre » isolément. Le mode auto ajoute donc une inférence de classifieur par appel d’outil — de la latence et du coût réels.

Claude Code expose cinq modes de permission en interne :¹

Le disjoncteur du mode auto reprend celui documenté publiquement par Anthropic : 3 blocages consécutifs ou 20 au total basculent en mode manuel.⁴ Le code source confirme qu’il s’agit d’une limite stricte, pas d’une simple suggestion.

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

Le module de validation bash (bashSecurity.ts) s’étend sur 2 592 lignes avec 23 vérifications de sécurité numérotées.¹ La profondeur est remarquable — et chaque vérification suggère un incident réel derrière elle.

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

Pour les constructeurs de hooks : vos hooks PreToolUse s’exécutent après cette validation à 23 vérifications. Vous ajoutez une deuxième couche, pas la seule. Les vérifications intégrées gèrent les attaques au niveau du shell que vos hooks applicatifs manqueraient.

3. Défenses anti-distillation

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

Injection de faux outils. Lorsque le flag ANTI_DISTILLATION_CC est activé, Claude Code injecte des définitions d’outils factices dans la conversation. Ces faux outils empoisonnent toute donnée d’entraînement récoltée depuis la session — un modèle entraîné sur ces données apprendrait des schémas d’outils incorrects.

Résumé de texte connecteur. Une seconde défense met en tampon le texte de l’assistant entre les appels d’outils et renvoie des résumés cryptographiques au lieu du texte brut. Cela rend la transcription de conversation inutile pour la distillation tout en préservant l’expérience utilisateur.

Les deux défenses ont des contournements connus. Un proxy MITM, des surcharges de variables d’environnement ou des fournisseurs API tiers peuvent les contourner.¹ Ces défenses sont des ralentisseurs, pas des murs — elles augmentent le coût de la distillation sans l’empêcher totalement.

4. Mode incognito

undercover.ts fait environ 90 lignes avec une propriété notable : il n’existe aucun interrupteur de désactivation forcée.¹

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

La conception « sans désactivation forcée » signifie que ce module s’exécute dans tous les contextes, y compris lorsque les employés d’Anthropic utilisent Claude Code. Le code source révèle également que les commits rédigés par l’IA des employés d’Anthropic ne montrent aucune attribution IA dans leurs contributions open source — le module undercover supprime ces marqueurs.

5. Détection de frustration

userPromptKeywords.ts détecte la frustration de l’utilisateur via du pattern matching regex sur les grossièretés.¹ C’est plus rapide et moins coûteux qu’un appel d’inférence LLM — une regex s’exécute en microsecondes, un appel de modèle prend des secondes.

Lorsque c’est déclenché, Claude ajuste son comportement : plus prudent, plus explicite, plus déférent. Si vous avez remarqué que Claude devenait soudainement plus prudent après l’expression de frustration, voici le mécanisme. Le changement comportemental n’est pas émergent du modèle — il est conçu dans le harness.

6. Architecture du cache de prompts

promptCacheBreakDetection.ts suit 14 vecteurs distincts de rupture de cache avec des « verrous persistants ».³ Un verrou persistant signifie qu’une fois qu’une action cassant le cache se produit, le système ne tente pas de restaurer le cache — il reste cassé pour le reste de la session.

Implications pratiques pour l’utilisation quotidienne :

• Réorganiser les sections de votre CLAUDE.md casse le cache
• Activer/désactiver la réflexion étendue en cours de session casse le cache
• Modifier les configurations de serveur MCP casse le cache
• Ajouter ou supprimer des fichiers de règles casse le cache

Les 14 vecteurs expliquent un phénomène que de nombreux utilisateurs avancés ont remarqué : les sessions qui démarrent rapidement ralentissent progressivement. Chaque modification de configuration accumule des ruptures de cache. La conception en « verrou persistant » signifie que vous ne pouvez pas récupérer en annulant le changement — le cache est perdu pour la session.

Bonne pratique : Configurez 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 session.

7. Disjoncteur d’autocompact

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

« 1 279 sessions avaient 50+ échecs consécutifs d’autocompact (jusqu’à 3 272 dans une seule session), gaspillant environ 250 000 appels API/jour. »

La correction : MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3. Après 3 échecs de compaction consécutifs, le système arrête l’autocompact et affiche une erreur au lieu de brûler silencieusement des tokens.

Avant ce disjoncteur, une session bloquée dans une boucle de compaction réessayait indéfiniment — chaque tentative consommant des tokens pour le prompt et la réponse de compaction. À l’échelle, 250 000 appels API gaspillés par jour représentent un coût d’infrastructure significatif. La correction tient en trois lignes et économise des millions de tokens quotidiennement.

Si vous rencontrez des erreurs répétées « compaction failed », voilà pourquoi. Le système vous protège d’une boucle infinie, il ne dysfonctionne pas.

8. Mode coordinateur : les prompts comme architecture

La coordination multi-agents (coordinatorMode.ts) est entièrement implémentée via des instructions de prompt système, et non par une orchestration au niveau du code.³ Le modèle orchestrateur reçoit un prompt décrivant comment déléguer, agréger et synthétiser. Les agents subordonnés ne sont pas des processus spéciaux — ce sont des instances Claude avec des prompts système différents.

Cela valide le patron « prompts comme architecture » que les praticiens construisent indépendamment. Le système de hooks décrit dans Anatomy of a Claw utilise la même approche : dispatchers, skills et agents sont orchestrés via des instructions de prompt, pas via un flux de contrôle au niveau du code.

Une directive du prompt du coordinateur se démarque :

« Ne jamais écrire “based on your findings” — ces formulations délèguent la compréhension aux workers au lieu de la faire soi-même. »

Il s’agit d’une porte de qualité encodée dans le prompt d’orchestration. Le coordinateur doit synthétiser, pas relayer. Le même principe s’applique à tout système multi-agents : si l’orchestrateur ne fait que transmettre des messages entre spécialistes, il n’apporte aucune valeur.

9. KAIROS : l’agent autonome non publié

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

Composants clés : - Un skill /dream pour la distillation nocturne de mémoire - Des journaux quotidiens en ajout seul - Des webhooks GitHub pour un contexte tenant compte des dépôts - Un démon en arrière-plan avec un rafraîchissement cron toutes les 5 minutes - Des feature gates empêchant l’activation

KAIROS semble être la réponse d’Anthropic aux assistants agents persistants et toujours actifs. Le skill /dream est particulièrement intéressant — il implique un modèle qui traite et consolide sa mémoire au repos, de manière similaire à la consolidation mnésique humaine pendant le sommeil.

La fonctionnalité est bloquée par des gates et n’est pas encore disponible. Toutefois, sa présence dans le code source indique la direction : Claude Code évolue d’un outil basé sur les sessions vers un agent persistant et conscient de son contexte.

10. Le système d’animal de compagnie

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

L’animal est déterministe — dérivé d’un hash de l’identifiant utilisateur via Mulberry32, décrit dans le code source comme « good enough for picking ducks ». Chaque animal possède 5 statistiques (DEBUGGING, PATIENCE, CHAOS, WISDOM, SNARK) et un niveau de rareté :

Les animaux sont rendus sous forme de sprites ASCII 5×12 avec des animations à 3 images. Les noms de code des espèces sont encodés en hexadécimal dans le code source car l’un d’entre eux entre en collision avec un nom de modèle non publié.

Ce n’est pas une fonctionnalité humoristique — c’est un mécanisme de rétention. L’attribution déterministe fait que votre animal est toujours le même, créant un attachement. Le système de rareté crée une monnaie sociale. Le rendu ASCII implique zéro surcharge de performance. C’est un système d’engagement bien conçu, dissimulé dans un outil de développement.

11. La bombe fork

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

Au matin, des centaines d’instances Claude Code s’exécutaient simultanément. Le système a été sauvé d’une facture API massive par un mécanisme ironique : la consommation mémoire de chaque instance (Bun → React → TUI) a provoqué le blocage de la machine avant que la facturation ne puisse s’emballer.

La leçon pour les constructeurs de hooks : les hooks SessionStart doivent être idempotents. Si votre hook lance des processus, ces processus ne doivent pas déclencher le même hook. Une variable de garde, un fichier PID ou un flag d’environnement empêche la récursion.

Ce que cela signifie

La fuite du code source a confirmé ce que les praticiens déduisaient du comportement : Claude Code n’est pas un simple wrapper autour d’un appel API. C’est un système d’ingénierie substantiel avec des couches de sécurité, des optimisations de performance, des ajustements comportementaux et des fonctionnalités non publiées qui signalent la feuille de route du produit.

Pour les constructeurs de harness, les implications clés sont couvertes dans la section Sous le capot du guide. Pour tous les autres, la fuite du code source offre une visibilité rare sur le fonctionnement réel d’un outil d’IA en production — non pas tel que le marketing le décrit, mais tel que le code l’implémente.

La découverte la plus importante est aussi la plus simple : le système est plus complexe qu’il n’y paraît, et cette complexité existe pour de bonnes raisons. Les 23 vérifications de sécurité bash existent parce que 23 vecteurs d’attaque ont été découverts. Le disjoncteur d’autocompact existe parce que 250 000 appels API étaient gaspillés quotidiennement. Le module undercover existe parce que les noms de code fuient. Chaque ligne de code défensif a une histoire derrière elle.

Sources

Foire aux questions

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

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

La fuite du code source affecte-t-elle la sécurité de Claude Code ?

Les découvertes liées à la sécurité (validation bash, système de permissions) décrivent des mécanismes défensifs, pas des vulnérabilités. Connaître le fonctionnement des vérifications de sécurité bash ne les rend pas plus faciles à contourner — les vérifications sont déterministes, pas fondées sur l’obscurité.

Devrais-je changer ma façon d’utiliser Claude Code suite à ces découvertes ?

La découverte la plus actionnable concerne la fragilité du cache de prompts. Si vous modifiez CLAUDE.md, les fichiers de règles ou les configurations MCP en cours de session, vous cassez le cache de prompts. Configurez tout avant de démarrer une session.

Qu’est-ce que KAIROS ?

Une fonctionnalité d’agent autonome non publiée trouvée dans le code source. Elle inclut une mémoire persistante, une distillation nocturne et un traitement en arrière-plan. Elle est bloquée par des feature gates et n’est pas accessible aux utilisateurs.