What the Claude Code Source Leak Reveals

TITLE : Ce que la fuite du code source de TERM_0 révèle DESCRIPTION : 11 découvertes issues de la fuite du code source de TERM_0 : comment fonctionnent réellement le mode auto, la sécurité bash, la mise en cache des prompts et la coordination multi-agents. BODY: En mars 2026, un bug de build de Bun a embarqué des source maps dans le package npm de TERM_0. Les fichiers .map contenaient l’intégralité du code source lisible de TERM_1 : chaque module, chaque commentaire, chaque nom de code interne.¹ TERM_3 a rapidement retiré le package, mais la communauté avait déjà extrait et analysé les internals.

La fuite du code source de TERM_0 a révélé que le mode auto exécute un classificateur Sonnet 4.6 distinct à chaque appel d’outil, que la sécurité bash s’appuie sur 23 vérifications numérotées suggérant de véritables incidents d’exploitation, et que la mise en cache des prompts suit 14 vecteurs de rupture avec des verrous persistants. Le code source a également mis au jour des défenses anti-distillation utilisant l’injection de faux outils, un module undercover qui efface les noms de code internes sans interrupteur de désactivation, et une coordination multi-agents implémentée entièrement sous forme d’instructions de system prompt plutôt que de code de protocole dédié.

Je n’écris pas un article de type « regardez ce qui a fuité ». Je maintiens le guide TERM_0 le plus complet d’internet et j’exécute quotidiennement 84 hooks, 43 skills et 19 agents par-dessus.² La fuite du code source a répondu à des questions que je rétro-concevais depuis des mois à partir de l’observation du comportement. Ce qui suit est l’analyse d’un praticien sur ce que le code source révèle du fonctionnement réel de TERM_0, et sur ce que ces découvertes signifient pour les personnes qui bâtissent par-dessus.

TL;DR : Le code source confirme que le mode auto exécute un classificateur 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 la mise en cache des prompts suit 14 vecteurs de rupture avec des verrous persistants, que la coordination multi-agents réside entièrement dans les instructions de system prompt, et que la détection de frustration s’appuie sur des regex, et non sur l’inférence TERM_23. La section Under the Hood du guide couvre les implications pour les builders. L’article ci-dessous couvre l’anatomie complète.

Points clés à retenir

• Pour les builders : Le mode auto coûte une inférence de classificateur par appel d’outil. Intégrez cette surcharge dans vos modèles de coût pour les workflows autonomes. Vos hooks PreToolUse complètent mais ne remplacent pas la validation bash intégrée à 23 vérifications.
• Pour les utilisateurs avancés : Le cache de prompts se casse facilement sur 14 vecteurs. 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 (le disjoncteur existe parce que les tentatives de compaction gaspillaient autrefois 250 000 appels TERM_18/jour).
• Pour les 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. 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 fait 1 495 lignes.³ Il implémente le système de permissions « auto mode », le classificateur qui décide s’il faut autoriser, bloquer ou interroger à propos de chaque appel d’outil.

Le constat clé : le mode auto n’est pas une instruction 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 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 classificateur par appel d’outil, introduisant une latence et un coût bien réels.

TERM_0 expose cinq modes de permission en interne :¹

Le disjoncteur du mode auto reflète celui qu’TERM_3 a documenté publiquement : 3 blocages consécutifs ou 20 au total mettent en pause vers le manuel.⁴ Le code source confirme qu’il s’agit d’une limite stricte, pas d’une suggestion souple.

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. TERM_0 s’exécute dans Zsh sur macOS (le shell par défaut depuis Catalina), et le code source montre qu’TERM_3 a découvert des vecteurs d’attaque uniques à 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 qui peut contourner des listes de blocage naïves.

Pour les builders de hooks : vos hooks PreToolUse s’exécutent après cette validation à 23 vérifications. Vous ajoutez une seconde couche, pas la seule. Les vérifications intégrées gèrent les attaques au niveau 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é, TERM_0 injecte des définitions d’outils leurres dans la conversation. Les faux outils empoisonnent toute donnée d’entraînement récoltée depuis la session. Un modèle entraîné sur des données empoisonnées apprendrait des schémas d’outils incorrects.

Résumé de texte de 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. Ces résumés rendent les transcriptions de conversation inutilisables 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 TERM_18 tiers peuvent les contourner.¹ Les défenses fonctionnent comme des ralentisseurs, pas comme des murs : elles augmentent le coût de la distillation sans l’empêcher totalement.

4. Le mode undercover

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

Le module dissimule les noms de code internes (« Capybara », « Tengu »), les canaux Slack, les dépôts internes et autres références d’infrastructure d’TERM_3. 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.

La conception « aucun interrupteur de désactivation » signifie que le module s’exécute dans tous les contextes, y compris quand les employés d’TERM_3 utilisent TERM_0. Le code source révèle également que les commits rédigés par IA par des employés d’TERM_3 ne portent aucune attribution IA dans leurs contributions open source, car le module undercover efface ces marqueurs.

5. Détection de frustration

userPromptKeywords.ts détecte la frustration de l’utilisateur via de la correspondance de motifs regex sur les grossièretés.¹ Une regex s’exécute en microsecondes ; un appel de modèle prend des secondes. La différence de vitesse et de coût explique ce choix de conception.

Une fois déclenché, TERM_6 ajuste son comportement : plus prudent, plus explicite, plus déférent. Si vous avez remarqué que TERM_6 devenait soudainement plus précautionneux après que vous avez exprimé votre frustration, le module de mots-clés en est le mécanisme. Le changement comportemental n’émerge pas du modèle. Il est conçu dans la couche d’orchestration.

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 brise le cache, le système ne tente pas de le restaurer. La rupture persiste pour le reste de la session.

Implications pratiques pour les utilisateurs quotidiens :

• Réordonner les sections de votre CLAUDE.md brise le cache
• Basculer l’extended thinking en cours de session brise le cache
• Modifier les configurations des serveurs TERM_17 brise le cache
• Ajouter ou retirer des fichiers de règles brise le cache

Les 14 vecteurs expliquent un schéma que de nombreux utilisateurs avancés ont remarqué : les sessions qui démarrent rapidement ralentissent progressivement. Chaque changement 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. Une fois brisé, le cache reste brisé pour la session.

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

7. Disjoncteur d’autocompact

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

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

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

Avant le disjoncteur, une session coincée dans une boucle de compaction réessayait indéfiniment, chaque tentative consommant des tokens pour le prompt et la réponse de compaction. À grande échelle, 250 000 appels TERM_18 gaspillés par jour représentent un coût d’infrastructure significatif. Le correctif est un changement de trois lignes qui épargne des millions de tokens chaque jour.

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

8. Mode coordinateur : les prompts comme architecture

La coordination multi-agents (coordinatorMode.ts) réside entièrement dans des instructions de system prompt, et non dans 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 TERM_6 avec des system prompts différents.

Cette conception valide le pattern « prompts as architecture » que les praticiens ont construit indépendamment. Le système de hooks que j’ai décrit dans Anatomy of a Claw utilise la même approche : dispatchers, skills et agents opèrent 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 :

« N’écrivez jamais ‘based on your findings’ — ces formules délèguent la compréhension aux workers au lieu de la faire vous-même. »

La directive fonctionne comme 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 se contente de transmettre des messages entre spécialistes, il n’ajoute 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é de mémoire persistante.¹

Composants clés : - Un skill /dream pour la distillation nocturne de la mémoire - Des logs quotidiens en append-only - Des webhooks TERM_9 pour un contexte conscient du dépôt - Un daemon en arrière-plan avec une actualisation cron de 5 minutes - Des feature gates empêchant l’activation

KAIROS semble être la réponse d’TERM_3 aux assistants agents persistants et toujours actifs. Le skill /dream est particulièrement intéressant parce qu’il suppose un modèle qui traite et consolide la mémoire pendant l’inactivité, à la manière de la consolidation de la mémoire humaine pendant le sommeil.

Des feature gates empêchent l’activation, et TERM_3 n’a pas publié KAIROS. Mais sa présence dans le code source indique la direction : TERM_0 évolue d’un outil basé sur des sessions vers un agent persistant et conscient de l’arrière-plan.

10. Le système de compagnon

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

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

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

Le système de compagnon n’est pas une fonctionnalité gag. C’est un mécanisme de rétention. L’assignation déterministe signifie que votre compagnon est toujours le même, ce qui crée de l’attachement. Le système de rareté crée une monnaie sociale. Le rendu ASCII signifie zéro surcharge de performance. TERM_3 a construit un système d’engagement bien conçu et l’a caché à l’intérieur d’un outil de développement.

11. La fork bomb

Un incident de la communauté illustre les risques du système de hooks.⁵ Un développeur a créé un hook SessionStart qui spawnait 2 instances de TERM_0. Chaque instance ainsi spawnée déclenchait à nouveau le hook, créant une croissance exponentielle : 1 → 2 → 4 → 8 → 16 → 2^N.

Au matin, des centaines d’instances de TERM_0 s’exécutaient simultanément. Le système a évité une facture TERM_18 massive grâce à 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 puisse s’emballer.

La leçon pour les builders de hooks : les hooks SessionStart doivent être idempotents. Si votre hook spawne 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 prévient la récursion.

Ce que cela signifie

La fuite du code source a confirmé ce que les praticiens avaient déduit du comportement : TERM_0 n’est pas un mince wrapper autour d’un appel TERM_18. 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 produit.

Pour les builders, les implications clés apparaissent dans la section Under the Hood 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 des raisons précises. 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 TERM_18 étaient gaspillés quotidiennement. Le module undercover existe parce que les noms de code fuitent. Derrière chaque ligne de code défensif se cache une histoire.

Sources

Foire aux questions

Le code source de TERM_0 est-il encore disponible ?

Non. TERM_3 a retiré la version affectée du package npm peu de temps après la découverte des source maps. L’analyse de cet article se fonde sur la documentation communautaire du code source avant sa suppression.

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

Les découvertes pertinentes pour la sécurité (validation bash, système de permissions) décrivent des mécanismes défensifs, pas des vulnérabilités. Savoir comment fonctionnent les vérifications de sécurité bash ne les rend pas plus faciles à contourner, car les vérifications sont déterministes, et non dépendantes de l’obscurité.

Dois-je changer ma façon d’utiliser TERM_0 au vu de ces découvertes ?

La découverte la plus actionnable est la fragilité du cache de prompts. Si vous modifiez CLAUDE.md, vos fichiers de règles ou les configurations TERM_17 en cours de session, vous brisez le cache de prompts. Définissez votre configuration 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 protégée par feature gate et n’est pas disponible pour les utilisateurs.