Il Codice Sorgente di Claude Code è Finito su GitHub: Cosa Abbiamo Scoperto

Un file mancante. Cinque lettere: .npmignore. Tanto è bastato per esporre l'intero codice sorgente del tool di AI coding che genera 2.5 miliardi di dollari l'anno. E il bello è che nessuno l'ha hackerato -- Anthropic se l'è pubblicato da sola.

Il 31 marzo 2026, alle 04:23 AM ET, Chaofan Shou -- un intern di Solayer Labs che su X si fa chiamare @Fried_rice -- ha notato qualcosa di strano nel pacchetto npm di Claude Code. La versione 2.1.88 conteneva un file .map da 59.8 megabyte. Dentro c'era tutto: 512.000 righe di TypeScript, circa 1.900 file sorgente, l'intera architettura dell'agente di coding più usato al mondo.

Quattro ore dopo Anthropic ha rimosso il pacchetto. Troppo tardi. Internet non dimentica, e soprattutto non perdona.

Come Si Espone il Sorgente di un Prodotto da Miliardi

La catena di errori è quasi didattica nella sua semplicità.

Claude Code è un'applicazione TypeScript compilata con Bun, il runtime JavaScript che Anthropic ha acquisito a dicembre 2025. Bun, a differenza di Node.js, rende estremamente semplice generare source map durante il bundling (basta un flag). I source map sono file che mappano il codice minificato al sorgente originale -- servono per il debug, ma contengono letteralmente tutto il codice leggibile.

Il problema: quando pubblichi un pacchetto su npm, il comando npm publish include tutti i file nella directory del progetto. Per escludere file specifici hai due opzioni: un file .npmignore (che funziona come .gitignore ma per npm) oppure il campo files in package.json. Anthropic non ha usato nessuno dei due.

Risultato: il source map da 59.8 MB è finito nel tarball pubblicato su npm, disponibile a chiunque con un npm pack @anthropic-ai/claude-code.

Il dettaglio che rende tutto più assurdo: questo non è il primo incidente. Un leak simile era già avvenuto a febbraio 2025. Tredici mesi fa. Stessa causa, stessa negligenza.

40 Tool, 50 Comandi, e un Loop Agente da 46.000 Righe

Guardiamo cosa c'è dentro, perché il codice racconta parecchio su come funziona un coding agent di livello produzione.

L'architettura è modulare. Circa 40 tool built-in -- Read, Write, Edit, Bash, Grep, Glob, WebFetch, Agent, LSP, MCP e altri -- ognuno con il proprio sistema di permessi. Circa 50 slash command (/commit, /review-pr e simili). L'interfaccia terminale è costruita con React e Ink, la validazione degli input e delle risposte API passa tutta da Zod v4.

Il modulo più massiccio è il Query Engine: 46.000 righe di TypeScript che gestiscono le chiamate API al modello, lo streaming, il caching e l'orchestrazione degli agenti. Poi c'è il Tool System con 29.000 righe e un'architettura a plugin dove ogni tool è gated da permessi espliciti.

Ci sono anche chicche ingegneristiche non banali. Il rendering del terminale usa tecniche da game engine -- Int32Array per i character pool, bitmask-encoded styling. La sicurezza Bash include 23 check separati, con difese contro Zsh equals expansion e zero-width space injection. La memoria è organizzata su tre livelli: un index layer sempre in contesto (~150 caratteri per puntatore), topic file caricati on demand, e transcript accessibili solo via grep.

Il sistema multi-agente supporta tre modelli: fork, teammate e worktree. Gli agenti forkati ereditano il contesto del parent come copie byte-identical.

Chi sviluppa coding agent ha ora un blueprint completo. E questo è probabilmente l'aspetto più dannoso per Anthropic dal punto di vista competitivo.

187 Verbi per lo Spinner (Incluso "Razzmatazzing")

Non tutto il codice è architettura seria. Wes Bos, developer ed educator con un seguito enorme, ha confessato di essere andato dritto a cercare una cosa sola: i verbi dello spinner.

Ne ha trovati 187, hardcoded. La lista parte da termini ragionevoli come "Thinking" e "Processing", poi deraglia progressivamente verso "Hullaballooing", "Razzmatazzing" e "Flibbertigibbeting". Qualcuno in Anthropic si è divertito, e francamente è il tipo di easter egg che ti fa venire voglia di lavorarci.

Ma non è l'unica curiosità nel codice.

La Regex che Sa Quando Stai Imprecando

Il file userPromptKeywords.ts contiene un sistema di rilevamento della frustrazione dell'utente. Non usa un modello di linguaggio -- sarebbe troppo costoso e lento per un check da fare su ogni prompt. Usa una regex.

Circa 200 caratteri di pattern matching che cercano "wtf", "shit", "dumbass", "awful", "so frustrating" e altre espressioni colorite. Quando il match scatta, il prompt viene taggato come "negativo" nella telemetria.

Due cose da notare. Primo: non logga la conversazione completa né il codice. Registra solo il segnale di sentiment -- "l'utente è frustrato". Secondo: il fatto che abbiano scelto una regex e non un LLM per questo task è una decisione ingegneristica perfettamente razionale. Un'inferenza per controllare se qualcuno sta imprecando costerebbe più del valore dell'informazione.

È surveillance? Tecnicamente è analytics sul sentiment. Praticamente, c'è un file nel codice del tuo coding assistant che contiene una lista curata di parolacce e decide quando stai perdendo la pazienza. Ognuno tragga le sue conclusioni.

Undercover Mode: "Do Not Blow Your Cover"

Qui la faccenda si fa più interessante.

Il file undercover.ts implementa una feature che si attiva quando i dipendenti Anthropic usano Claude Code su repository esterni -- cioè non di proprietà dell'azienda. In pratica, Anthropic contribuisce in segreto a progetti open source.

Cosa fa concretamente:

Rimuove l'attribuzione Co-Authored-By dai commit
Vieta qualsiasi menzione di nomi in codice interni (come "Capybara" o "Tengu"), canali Slack, o modelli non rilasciati
Il system prompt dice letteralmente: "You are operating UNDERCOVER... Your commit messages... MUST NOT contain ANY Anthropic-internal information. Do not blow your cover."
Il modo può essere forzato ON, ma non può essere disabilitato nelle build esterne

L'ironia è quasi troppo perfetta: il sistema progettato per prevenire leak di informazioni interne è stato esso stesso leakato.

La questione etica è reale. Se un'azienda contribuisce a un progetto open source ma nasconde deliberatamente la propria identità, sta giocando pulito? C'è una differenza tra un dipendente che contribuisce nel tempo libero e un'azienda che orchestra contributi anonimi con un sistema dedicato.

Anti-Distillation: Tool Falsi per Avvelenare i Competitor

Nel file claude.ts, alla linea 301, c'è un flag chiamato ANTI_DISTILLATION_CC. Quando è attivo, il sistema invia un parametro anti_distillation: ['fake_tools'] nelle richieste API. Il server risponde iniettando silenziosamente definizioni di tool falsi nel system prompt.

Lo scopo: se un competitor sta intercettando e registrando il traffico API di Claude Code per addestrare un proprio modello (pratica nota come distillation), i tool falsi inquinano i dati di training. Il modello competitor impara tool che non esistono, e le sue performance peggiorano.

C'è anche un secondo meccanismo. In betas.ts, linee 279-298, l'API bufferizza il testo dell'assistente tra una tool call e l'altra, lo riassume e restituisce il riassunto con una firma crittografica. Nei turni successivi il testo originale può essere ripristinato dalla firma, ma chi intercetta vede solo il riassunto -- inutilizzabile per il training.

Il tutto è gated dietro un feature flag GrowthBook chiamato tengu_anti_distill_fake_tool_injection. Tengu, per chi non lo sapesse, è un demone del folklore giapponese noto per l'inganno.

La guerra tra provider AI non si combatte solo sui benchmark. Si combatte nel protocollo, con trappole invisibili nel traffico di rete.

KAIROS: L'Agente che Lavora Mentre Dormi

Il nome più ricorrente nel sorgente -- oltre 150 menzioni -- è KAIROS, dal greco antico "il momento giusto". È un agente autonomo non ancora rilasciato, nascosto dietro un feature flag inattivo.

Dalle tracce nel codice, KAIROS è un salto concettuale rispetto a Claude Code come lo conosciamo. Non è reattivo -- è proattivo. Le feature identificate:

Daemon mode: Claude Code che gira come processo always-on in background
Heartbeat prompts: il sistema riceve periodicamente tick prompt per decidere se agire o restare in attesa, con un budget di blocco massimo di 15 secondi per non interrompere il flusso dello sviluppatore
autoDream: un processo di "memory consolidation" che si attiva durante l'idle dell'utente. Fa merge delle osservazioni, rimuove contraddizioni, converte insight vaghi in fatti strutturati. In pratica, Claude Code che "digerisce" quello che ha imparato durante la sessione
GitHub webhooks e background workers: monitoring continuo di repository
Append-only logging di tutte le decisioni, per audit

È il passaggio da "tool che risponde quando chiedi" a "agente che agisce quando serve". Un coding assistant che di notte consolida la memoria della sessione diurna, e la mattina dopo ha già elaborato cosa fare.

Se e quando verrà rilasciato, ridefinirà il concetto stesso di coding assistant. Il codice è già lì. Aspetta solo un flag.

DRM in Zig Sotto il JavaScript

Un dettaglio tecnico che merita attenzione: Claude Code implementa un sistema di attestazione crittografica del client a un livello insolitamente basso dello stack.

Le richieste API includono un placeholder cch=00000 che lo stack HTTP nativo di Bun -- scritto in Zig, non in JavaScript -- sostituisce con un hash calcolato prima della trasmissione. È una prova crittografica che la richiesta proviene dal client ufficiale. Impedisce a tool di terze parti di impersonare Claude Code per accedere alle API.

Il paradosso: Anthropic ha costruito un sistema DRM sofisticato, implementato in un linguaggio di basso livello sotto il layer JavaScript per renderne il reverse engineering più difficile. Poi ha pubblicato tutto il sorgente su npm. La protezione crittografica diventa sostanzialmente inutile quando il codice che la genera è pubblico.

100.000 Stelle in un Giorno: Il Record Assoluto di GitHub

La reazione della community è stata immediata e spettacolare.

Claw Code, una repo creata da Sigrid Jin (@instructkr), è diventata la prima repository nella storia di GitHub a superare 100.000 stelle. Il traguardo delle 50.000 è arrivato in sole due ore dalla pubblicazione. I fork hanno superato gli 82.000. Il progetto è un clean-room rewrite -- prima in Python, poi in Rust -- per evitare problemi legali con il codice originale.

Un secondo progetto, ClaURST di Kuberwastaken, è una reimplementazione pura in Rust che elimina completamente la dipendenza da Node.js e npm. Il README è esplicito: "This repository does not hold a copy of the proprietary Claude Code TypeScript source code."

Ma la frenesia ha avuto anche un lato oscuro. Sviluppatori che si sono affrettati a compilare i materiali leakati sono stati bersaglio di un attacco supply chain secondario: pacchetti npm con nomi interni di Anthropic (color-diff-napi, modifiers-napi) sono stati registrati da account con email usa-e-getta, configurati per attacchi di dependency confusion. L'ironia: un leak causato da negligenza su npm ha generato un attacco su npm.

Due Leak in Una Settimana: Il Paradosso della Safety Company

Il contesto rende tutto più tagliente.

Cinque giorni prima del leak di Claude Code -- il 26 marzo -- una misconfiguration del CMS di Anthropic aveva esposto circa 3.000 file pubblicamente. Tra questi, draft di blog post su Mythos (nome in codice "Capybara"), un modello descritto come capace di porre "unprecedented cybersecurity risks" e con "dramatically higher scores" su coding e reasoning rispetto a Claude Opus 4.6.

Due incidenti di sicurezza in cinque giorni. Per l'azienda che ha fatto dell'AI safety il proprio marchio di fabbrica. Che pubblica paper sulla sicurezza, che predica il responsible deployment, che chiede regolamentazione ai governi.

Anthropic ha minimizzato con una dichiarazione asciutta: "This was a release packaging issue caused by human error, not a security breach. No sensitive customer data or credentials were involved." Tecnicamente corretto. Ma il punto non è se i dati dei clienti sono stati esposti. Il punto è che un'azienda valutata 350-380 miliardi di dollari, con un ARR di 14 miliardi, non riesce a gestire un .npmignore.

I numeri per contesto: Claude Code da solo fa $2.5 miliardi di ARR -- da zero a questa cifra in circa nove mesi dal lancio pubblico di maggio 2025. È quasi un quinto dell'intero fatturato di Anthropic. E il suo codice sorgente è stato accessibile a chiunque per quattro ore su un registry pubblico.

La Lezione per Chi Sviluppa

Mettiamo da parte le ironie e guardiamo cosa resta sul tavolo.

Per chi pubblica su npm: il .npmignore non è un optional. Non lo è mai stato, ma ora c'è un caso studio da 2.5 miliardi di dollari che lo dimostra. Se usi Bun come bundler e abiliti i source map nella configurazione di build, questi finiscono nella directory di output. Se non li escludi esplicitamente dal pacchetto npm, finiscono nel tarball pubblicato. Meglio ancora: usa il campo files in package.json per dichiarare esplicitamente cosa includere, invece di affidarti a un file che dichiara cosa escludere. La whitelist batte la blacklist, sempre.

Per chi costruisce coding agent: il leak è un blueprint. L'architettura a 40 tool con permessi gated, il query engine da 46.000 righe, la memoria a tre livelli, il sistema multi-agente con fork/teammate/worktree -- sono decisioni architetturali validate in produzione su milioni di utenti. Non è più teoria. È codice reale di un prodotto reale.

Per chi valuta la sicurezza della supply chain: lo stesso giorno del leak di Claude Code, pacchetti axios malevoli con RAT sono apparsi su npm. Il giorno dopo, pacchetti con nomi interni di Anthropic. npm resta un terreno minato. Verificate sempre i pacchetti prima di installarli, soprattutto quelli che appaiono in momenti di hype.

Per chi si fida ciecamente dei vendor AI: le aziende che predicano la safety non sono immuni dall'errore umano. Anzi, la pressione per rilasciare velocemente -- Claude Code ha raddoppiato i ricavi dall'inizio del 2026 -- è esattamente il tipo di pressione che produce .npmignore mancanti. La prossima volta potrebbe non essere codice sorgente. Potrebbero essere credenziali, chiavi API, o dati degli utenti.

Un intern con un buon occhio ha trovato il problema in pochi minuti. Immaginate cosa troverebbe qualcuno con intenzioni diverse e più tempo a disposizione.

Fonti: