Co ujawnia wyciek kodu źródłowego Claude Code

W marcu 2026 roku błąd w kompilacji Bun spowodował dołączenie map źródłowych do pakietu npm Claude Code. Pliki .map zawierały pełny, czytelny kod źródłowy w TypeScript — każdy moduł, każdy komentarz, każdą wewnętrzną nazwę kodową.¹ Anthropic szybko wycofało pakiet, ale społeczność zdążyła już wyodrębnić i przeanalizować wewnętrzne mechanizmy.

To nie jest wpis w stylu „zobaczcie, co wyciekło”. Prowadzę najbardziej kompleksowy przewodnik po Claude Code w internecie i codziennie korzystam z 84 hooków, 43 umiejętności oraz 19 agentów zbudowanych na jego bazie.² Wyciek kodu źródłowego odpowiedział na pytania, które od miesięcy próbowałem rozwikłać poprzez obserwację zachowań. Poniżej przedstawiam analizę praktyka: co kod źródłowy ujawnia o tym, jak Claude Code naprawdę działa, i co to oznacza dla osób budujących rozwiązania na jego bazie.

W skrócie: Kod źródłowy potwierdza, że tryb automatyczny uruchamia osobny klasyfikator Sonnet 4.6 przy każdym wywołaniu narzędzia (yoloClassifier.ts), zabezpieczenia bash obejmują 23 ponumerowane kontrole sugerujące realne incydenty eksploatacji (bashSecurity.ts), buforowanie promptów śledzi 14 wektorów przerwania z mechanizmem „trwałych zatrzasków”, koordynacja wieloagentowa jest zaimplementowana wyłącznie jako instrukcje w promptach systemowych, a wykrywanie frustracji wykorzystuje wyrażenia regularne — nie wnioskowanie LLM. Sekcja Pod maską w przewodniku omawia implikacje dla twórców obudów. Niniejszy wpis przedstawia pełną anatomię.

Kluczowe wnioski

• Twórcy obudów: Tryb automatyczny generuje jedno wywołanie klasyfikatora na każde użycie narzędzia. Należy to uwzględnić w modelach kosztowych autonomicznych przepływów pracy. Hooki PreToolUse uzupełniają, ale nie zastępują wbudowanej 23-punktowej walidacji bash.
• Zaawansowani użytkownicy: Pamięć podręczna promptów jest krucha — 14 wektorów może ją przerwać. Warto utrzymywać stabilny CLAUDE.md w ramach sesji. W przypadku pętli kompaktowania system zatrzymuje się po 3 niepowodzeniach (wcześniej marnował około 250 tys. wywołań API dziennie, zanim dodano bezpiecznik).
• Badacze bezpieczeństwa: Głębokość modułu zabezpieczeń bash (2592 linie, obrona specyficzna dla Zsh) sugeruje historię rzeczywistych prób eksploatacji. Za każdą ponumerowaną kontrolą kryje się konkretna historia.

1. Klasyfikator trybu automatycznego

Plik o wewnętrznej nazwie yoloClassifier.ts liczy 1495 linii.³ Implementuje system uprawnień „trybu automatycznego” — klasyfikator decydujący, czy zezwolić, zablokować, czy zapytać o każde wywołanie narzędzia.

Kluczowe odkrycie: tryb automatyczny to nie instrukcja w prompcie. To osobne wywołanie modelu. Każde użycie narzędzia jest oceniane przez klasyfikator Sonnet 4.6, który sprawdza, czy działanie odpowiada zamiarowi użytkownika, a nie tylko czy polecenie jest „bezpieczne” w izolacji. Oznacza to, że tryb automatyczny dodaje jedno wywołanie klasyfikatora na każde użycie narzędzia — realny narzut na opóźnienie i koszty.

Wewnętrznie Claude Code udostępnia pięć trybów uprawnień:¹

Bezpiecznik trybu automatycznego odzwierciedla ten opisany publicznie przez Anthropic: 3 kolejne lub 20 łącznych blokad przełącza na tryb ręczny.⁴ Kod źródłowy potwierdza, że jest to twardy limit, nie miękka sugestia.

2. Zabezpieczenia bash: 23 kontrole, realne incydenty

Moduł walidacji bash (bashSecurity.ts) obejmuje 2592 linie z 23 ponumerowanymi kontrolami bezpieczeństwa.¹ Ich głębokość jest imponująca — a za każdą kontrolą kryje się prawdopodobnie realny incydent.

Obrona specyficzna dla Zsh jest godna uwagi. Większość narzędzi bezpieczeństwa celuje w Bash. Claude Code działa w Zsh na macOS (domyślna powłoka od Cataliny), a kod źródłowy pokazuje, że Anthropic odkryło wektory ataku unikalne dla semantyki rozwijania Zsh. Rozwijanie =cmd to na przykład mechanizm Zsh zamieniający =curl na pełną ścieżkę do curl — podstawienie mogące ominąć naiwne listy blokowanych poleceń.

Dla twórców hooków: hooki PreToolUse uruchamiają się po tej 23-punktowej walidacji. Dodają drugą warstwę, nie jedyną. Wbudowane kontrole obsługują ataki na poziomie powłoki, które hooki aplikacyjne by przeoczyły.

3. Obrona przed destylacją

Kod źródłowy ujawnia aktywne mechanizmy obronne przed ekstrakcją danych treningowych:¹

Wstrzykiwanie fałszywych narzędzi. Gdy flaga ANTI_DISTILLATION_CC jest włączona, Claude Code wstrzykuje definicje narzędzi-wabików do konwersacji. Te fałszywe narzędzia zatruwają dane treningowe pozyskane z sesji — model wytrenowany na takich danych nauczyłby się nieprawidłowych schematów narzędzi.

Podsumowywanie tekstu łącznikowego. Drugi mechanizm buforuje tekst asystenta między wywołaniami narzędzi i zwraca kryptograficzne podsumowania zamiast surowego tekstu. Dzięki temu transkrypt konwersacji staje się bezużyteczny dla destylacji, zachowując jednocześnie doświadczenie użytkownika.

Oba mechanizmy mają znane obejścia. Proxy MITM, nadpisywanie zmiennych środowiskowych lub zewnętrzni dostawcy API mogą je ominąć.¹ Mechanizmy te to progi zwalniające, nie mury — podnoszą koszt destylacji, nie zapobiegając jej całkowicie.

4. Tryb incognito

undercover.ts to około 90 linii z jedną godną uwagi właściwością: brak przełącznika wymuszającego wyłączenie.¹

Moduł ukrywa wewnętrzne nazwy kodowe — „Capybara”, „Tengu” — a także kanały Slack, wewnętrzne repozytoria i inne odwołania do infrastruktury Anthropic. Gdy model generuje tekst zawierający nazwę kodową, moduł incognito przepisuje go, zanim użytkownik go zobaczy.

Architektura „bez wymuszania wyłączenia” oznacza, że moduł działa we wszystkich kontekstach, w tym gdy pracownicy Anthropic korzystają z Claude Code. Kod źródłowy ujawnia również, że commity autorstwa AI od pracowników Anthropic nie zawierają atrybucji AI w ich wkładach open source — moduł incognito usuwa te znaczniki.

5. Wykrywanie frustracji

userPromptKeywords.ts wykrywa frustrację użytkownika poprzez dopasowywanie wyrażeń regularnych do wulgaryzmów.¹ Jest to szybsze i tańsze niż wywołanie LLM — wyrażenie regularne wykonuje się w mikrosekundach, wywołanie modelu trwa sekundy.

Po aktywacji Claude dostosowuje swoje zachowanie: staje się ostrożniejszy, bardziej precyzyjny, bardziej uprzejmy. Jeśli ktoś zauważył, że Claude nagle staje się bardziej powściągliwy po wyrażeniu frustracji — to właśnie ten mechanizm. Zmiana zachowania nie wynika z modelu — jest wbudowana w obudowę.

6. Architektura pamięci podręcznej promptów

promptCacheBreakDetection.ts śledzi 14 odrębnych wektorów przerwania pamięci podręcznej z mechanizmem „trwałych zatrzasków”.³ Trwały zatrzask oznacza, że gdy nastąpi zdarzenie przerywające pamięć podręczną, system nie próbuje jej przywrócić — pozostaje przerwana do końca sesji.

Praktyczne implikacje dla codziennych użytkowników:

• Zmiana kolejności sekcji w CLAUDE.md przerywa pamięć podręczną
• Przełączanie rozszerzonego myślenia w trakcie sesji przerywa pamięć podręczną
• Zmiana konfiguracji serwerów MCP przerywa pamięć podręczną
• Dodawanie lub usuwanie plików reguł przerywa pamięć podręczną

Te 14 wektorów wyjaśnia wzorzec zauważony przez wielu zaawansowanych użytkowników: sesje, które zaczynają się szybko, stopniowo zwalniają. Każda zmiana konfiguracji kumuluje przerwania pamięci podręcznej. Architektura „trwałych zatrzasków” oznacza, że cofnięcie zmiany nie przywraca pamięci podręcznej — jest utracona na resztę sesji.

Zalecenie praktyczne: Warto ustawić CLAUDE.md, pliki reguł i konfigurację MCP przed rozpoczęciem sesji. Nie należy ich modyfikować w jej trakcie.

7. Bezpiecznik autokompaktowania

Komentarz w kodzie źródłowym dokumentuje skalę wcześniejszego problemu:¹

„1279 sesji miało ponad 50 kolejnych niepowodzeń autokompaktowania (do 3272 w pojedynczej sesji), marnując około 250 tys. wywołań API dziennie.”

Rozwiązanie: MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3. Po 3 kolejnych niepowodzeniach kompaktowania system wstrzymuje autokompaktowanie i wyświetla błąd zamiast cicho spalać tokeny.

Przed wprowadzeniem tego bezpiecznika sesja uwięziona w pętli kompaktowania ponawiała próby w nieskończoność — każda pochłaniając tokeny na prompt i odpowiedź kompaktowania. Na dużą skalę 250 tys. zmarnowanych wywołań API dziennie to znaczący koszt infrastrukturalny. Poprawka to trzyliniowa zmiana oszczędzająca miliony tokenów dziennie.

Jeśli pojawiają się powtarzające się błędy „kompaktowanie nieudane”, to właśnie dlatego. System chroni przed nieskończoną pętlą, a nie działa nieprawidłowo.

8. Tryb koordynatora: prompty jako architektura

Koordynacja wieloagentowa (coordinatorMode.ts) jest zaimplementowana wyłącznie jako instrukcje w promptach systemowych, nie jako orkiestracja na poziomie kodu.³ Model orkiestratora otrzymuje prompt opisujący sposób delegowania, agregowania i syntetyzowania. Agenci podrzędni nie są specjalnymi procesami — to instancje Claude z innymi promptami systemowymi.

Potwierdza to wzorzec „promptów jako architektury”, który praktycy budowali niezależnie. System hooków opisany w Anatomy of a Claw wykorzystuje to samo podejście: dyspozytorzy, umiejętności i agenci są orkiestrowani poprzez instrukcje w promptach, nie przez przepływ sterowania na poziomie kodu.

Jedna dyrektywa z promptu koordynatora szczególnie się wyróżnia:

„Nigdy nie pisz «na podstawie twoich ustaleń» — takie frazy delegują zrozumienie pracownikom zamiast wykonać je samemu.”

To bramka jakościowa zakodowana w prompcie orkiestracyjnym. Koordynator musi syntetyzować, nie przekazywać. Ta sama zasada dotyczy każdego systemu wieloagentowego: jeśli orkiestrator jedynie przekazuje wiadomości między specjalistami, nie wnosi wartości dodanej.

9. KAIROS: niewydany agent autonomiczny

Kod źródłowy zawiera odniesienia do niewydanej funkcji o nazwie KAIROS — autonomicznego agenta z trwałą pamięcią.¹

Kluczowe komponenty: - Umiejętność /dream do nocnej destylacji pamięci - Dzienne logi w trybie append-only - Webhooki GitHub do kontekstu uwzględniającego repozytoria - Demon działający w tle z 5-minutowym odświeżaniem cron - Bramki funkcji zapobiegające aktywacji

KAIROS wydaje się odpowiedzią Anthropic na trwałych, stale aktywnych asystentów agentowych. Umiejętność /dream jest szczególnie interesująca — sugeruje model przetwarzający i konsolidujący swoją pamięć w stanie bezczynności, podobnie jak ludzka konsolidacja pamięci zachodzi podczas snu.

Funkcja jest zablokowana bramkami i jeszcze niewydana. Niemniej jej obecność w kodzie sygnalizuje kierunek rozwoju: Claude Code ewoluuje od narzędzia sesyjnego w stronę trwałego agenta świadomego kontekstu.

10. System zwierząt towarzyszących

Jedno z bardziej zaskakujących odkryć: Claude Code zawiera system zwierząt towarzyszących.¹

Zwierzę jest deterministyczne — wyprowadzane z hasha identyfikatora użytkownika za pomocą algorytmu Mulberry32, opisanego w kodzie jako „wystarczająco dobry do wybierania kaczek”. Każde zwierzę ma 5 statystyk (DEBUGGING, PATIENCE, CHAOS, WISDOM, SNARK) i poziom rzadkości:

Zwierzęta są renderowane jako sprite’y ASCII 5×12 z 3-klatkowymi animacjami. Nazwy kodowe gatunków są zakodowane szesnastkowo w kodzie źródłowym, ponieważ jedna z nich koliduje z nazwą niewydanego modelu.

To nie jest żartobliwa funkcja — to mechanizm retencji. Deterministyczne przypisanie oznacza, że zwierzę użytkownika jest zawsze takie samo, budując przywiązanie. System rzadkości tworzy walutę społeczną. Renderowanie ASCII oznacza zerowy narzut wydajnościowy. To dobrze zaprojektowany system angażowania ukryty wewnątrz narzędzia deweloperskiego.

11. Bomba rozwidleniowa

Incydent społecznościowy ilustruje ryzyka systemu hooków.⁵ Pewien programista utworzył hook SessionStart uruchamiający 2 instancje Claude Code. Każda uruchomiona instancja wyzwalała ten sam hook ponownie, tworząc wzrost wykładniczy: 1 → 2 → 4 → 8 → 16 → 2^N.

Do rana działały jednocześnie setki instancji Claude Code. System uratował przed ogromnym rachunkiem za API ironiczny mechanizm: zużycie pamięci przez każdą instancję (Bun → React → TUI) spowodowało zawieszenie maszyny, zanim koszty zdążyły się spiralnie rosnąć.

Lekcja dla twórców hooków: hooki SessionStart muszą być idempotentne. Jeśli hook uruchamia procesy, te procesy nie mogą wyzwalać tego samego hooka. Zmienna zabezpieczająca, plik PID lub flaga środowiskowa zapobiegają rekurencji.

Co to oznacza

Wyciek kodu źródłowego potwierdził to, co praktycy wywnioskowali z obserwacji zachowań: Claude Code nie jest cienką nakładką na wywołanie API. To rozbudowany system inżynieryjny z warstwami bezpieczeństwa, optymalizacjami wydajności, dostosowaniami behawioralnymi i niewydanymi funkcjami sygnalizującymi kierunek rozwoju produktu.

Dla twórców obudów kluczowe implikacje omówiono w sekcji Pod maską przewodnika. Dla wszystkich pozostałych wyciek kodu źródłowego daje rzadki wgląd w to, jak naprawdę działa produkcyjne narzędzie AI — nie jak opisuje je marketing, lecz jak implementuje je kod.

Najważniejsze odkrycie jest zarazem najprostsze: system jest bardziej złożony, niż się wydaje, a ta złożoność istnieje z konkretnych powodów. 23 kontrole bezpieczeństwa bash istnieją, ponieważ odkryto 23 wektory ataku. Bezpiecznik autokompaktowania istnieje, ponieważ 250 tys. wywołań API było marnowanych dziennie. Moduł incognito istnieje, ponieważ nazwy kodowe wyciekały. Za każdą linią kodu obronnego kryje się historia.

Źródła

Często zadawane pytania

Czy kod źródłowy Claude Code jest nadal dostępny?

Nie. Anthropic wycofało dotkniętą wersję pakietu npm wkrótce po odkryciu map źródłowych. Analiza w tym wpisie opiera się na dokumentacji społecznościowej kodu źródłowego sporządzonej przed jego usunięciem.

Czy wyciek kodu źródłowego wpływa na bezpieczeństwo Claude Code?

Odkrycia związane z bezpieczeństwem (walidacja bash, system uprawnień) opisują mechanizmy obronne, nie luki. Znajomość sposobu działania kontroli bezpieczeństwa bash nie ułatwia ich ominięcia — kontrole są deterministyczne, nie oparte na ukryciu.

Czy powinienem zmienić sposób korzystania z Claude Code na podstawie tych odkryć?

Najbardziej praktycznym odkryciem jest kruchość pamięci podręcznej promptów. Modyfikacja CLAUDE.md, plików reguł lub konfiguracji MCP w trakcie sesji przerywa pamięć podręczną. Warto ustawić konfigurację przed rozpoczęciem sesji.

Czym jest KAIROS?

To niewydana funkcja autonomicznego agenta znaleziona w kodzie źródłowym. Obejmuje trwałą pamięć, nocną destylację i przetwarzanie w tle. Jest zablokowana bramkami funkcji i niedostępna dla użytkowników.