Každý větší softwarový projekt skrývá místa, která při prvním přečtení vyvolají údiv, smích nebo otázku „myslí to vážně?“. Claude Code od Anthropicu není výjimkou – ba naopak. Když jsem prošel desítky tisíc řádků jeho TypeScriptového zdrojového kódu, narazil jsem na věci, které bych v produkčním projektu nikdy nečekal.
V tomto článku vám ukazuji deset nejbizarnějších a nejneobvyklejších míst, která jsem v kódu našel. Žádné z nich není chyba – všechna mají dobrý důvod. Ale ten důvod je často fascinující více než samotné řešení.
1. Typ, který se jmenuje jako zaklínadlo
Když vývojáři posílají telemetrická data (např. analytické události), musí si být jisti, že v nich omylem neposílají citlivá data – třeba cesty k souborům, fragmenty zdrojového kódu nebo URL adresy. Anthropic toto řešil způsobem, který jsem nikde jinde neviděl.
Vytvořili TypeScriptový typ pojmenovaný AnalyticsMetadata_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS. Ano, celý název. Každý vývojář, který chce poslat řetězec do analytiky, musí svou hodnotu explicitně přetypovat na tento typ. Je to účelově nepohodlné – název slouží jako psychologická brzda. Než napíšete ten „type cast“, musíte se nad svým kódem na chvíli zastavit a ověřit, že opravdu neposíláte nic citlivého.
Stejný princip používají i u třídy pro výjimky: TelemetrySafeError_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS. Když chcete vytvořit chybu, jejíž zpráva se smí odeslat do telemetrie, musíte použít tuto třídu – a ten absurdně dlouhý název je součástí bezpečnostního designu.
V celém codebase se tento typ používá na více než 1 100 místech. Každé z nich představuje okamžik, kdy si někdo musel položit otázku: „Opravdu to, co odesílám, neobsahuje cestu k souboru?“
2. Anti-debugging – když vás vlastní kód číhá
Hned na 266. řádku vstupního souboru main.tsx se nachází kontrola, která zjišťuje, zda aplikace běží v debugovacím režimu. Pokud ano a nejde o interní (Anthropic) build, proces se okamžitě ukončí.
Detekce je důkladná: kontroluje parametry příkazové řádky (--inspect, --debug), proměnné prostředí (NODE_OPTIONS) a dokonce i to, zda je aktivní Node.js Inspector API. Rozlišuje chování mezi Bun a Node.js runtimy, protože Bun má specifické chování při single-file executable režimech.
Nejvtipnější část je podmínka "external" !== 'ant'. V interním buildu se řetězec "external" nahradí za "ant" a podmínka je vždy nepravdivá – takže interní zaměstnanci mohou debugovat bez omezení. V externím buildu (pro veřejnost) je podmínka pravdivá a debugging je zablokovaný.
3. Komentáře psané jako fantasy román
V souboru query.ts se nachází jeden z nejneobvyklejších komentářů, na jaké jsem kdy narazil v produkčním kódu. Nad kritické části logiky pro zpracování thinking bloků někdo napsal víceřádkový komentář stylem středověké angličtiny.
Autor v něm varuje budoucí vývojáře, že pravidla pro zpracování thinking bloků jsou složitá a vyžadují „hlubokou meditaci“. Následují tři technická pravidla (např. že thinking blok nesmí být poslední zprávou), ale jejich rámování připomíná spíš kouzelné zaklínadlo než technickou dokumentaci. Komentář končí výhružkou: ten, kdo pravidla nedodrží, bude potrestán „celým dnem debugování a trhání vlasů“.
Co ten komentář dělá bizarním, není jeho styl – je to fakt, že je přesný. Ta tři pravidla pro thinking bloky jsou opravdu natolik subtilní, že jejich porušení vede k těžko odhalitelným chybám. Autor prostě našel způsob, jak vývojářům vtisknout do paměti, že tady se nemá experimentovat.
4. 803 KB v jednom souboru
Soubor main.tsx má 4 684 řádků a 803 KB. V moderním TypeScriptovém projektu je to absolutně bezprecedentní. Ale není to náhodné ani důsledek nedbalosti.
V jednom souboru se nachází: parsování 30+ CLI argumentů, 11 verzí migračního systému (přejmenovávání modelů, změny oprávnění, přesun nastavení), detekce SSH, Direct Connect protokol (cc://), assistant mode (KAIROS), Teleport (resume session na jiném počítači), a 200+ importů z celého projektu.
Důvod pravděpodobně souvisí s Bun bundlerem – místo desítky modulů, které by se musely dynamicky načítat, je všechno v jednom souboru, který se načte najednou. A prvních 20 řádků tohoto souboru spouští paralelní subprocesy ještě před načítáním importů, aby se startup zrychlil o desítky milisekund.
5. Monkey-patching, který nemusíte vidět
Soubor lockfile.ts je elegantní příklad defenzivního programování. Knihovna proper-lockfile závisí na graceful-fs, která při prvním načítání monkey-patchuje každou funkci v Node.js modulu fs. To zabere přibližně 8 milisekund – což je na startupu CLI nástroje, který se snaží nastartovat za stovky milisekund, neakceptovatelné.
Řešení? Lazy loading. Soubor exportuje stejné API jako proper-lockfile, ale samotnou knihovnu načte až ve chvíli, kdy někdo skutečně zavolá funkci pro zamykání. Pokud spustíte claude --help, zamykání se nikdy neinicializuje a těch 8 ms ušetříte.
6. Bezpečnostní komentáře jako akademické články
Soubor bashSecurity.ts (102 KB, 2 593 řádků) obsahuje bezpečnostní komentáře, které by se daly publikovat jako akademický článek. Každý regulární výraz v souboru je doprovázen vysvětlením, proč je napsán právě takto a jaký útočný vektor blokuje.
Například u heredoc parseru autoři vysvětlují, že použití standardního regexu pro matchování obsahu heredocu je nebezpečné, protože regex by mohl „přeskočit“ přes delimiter a skrýt injektované příkazy. Proto implementovali vlastní řádkový parser o 200 řádcích, který přesně replikuje chování Bashe.
Kromě Bashe systém hlídá i Zsh-specifické příkazy – například zmodload (brána k nebezpečným modulům), ztcp (TCP spojení pro exfiltraci dat) nebo emulate -c (který funguje jako eval). Celkem je blokováno přes 20 Zsh-specifických příkazů, z nichž každý má v komentáři vysvětlení, proč je nebezpečný.
7. „Band-aid“ na Windows
Když Claude Code potřebuje otevřít soubor v externím editoru na Windows, narazí na nečekaný problém: funkce isCommandAvailable (která používá which pro zjištění, zda je příkaz dostupný) „rozbije stdin procesu“. Místo opravy kořenové příčiny autoři použili jednoduchý workaround – na Windows tuto kontrolu úplně přeskočí a rovnou použijí start /wait notepad.
Komentář v kódu doslova říká: „as a bandaid, we skip it“ (jako náplast to přeskočíme). Je to upřímnost, která je v produkčním kódu osvěžující – a zároveň příklad toho, že i v kvalitním projektu existují místa, kde pragmatismus zvítězí nad elegancí.
8. Unicode útok z HackerOne
Soubor sanitization.ts obsahuje obranu proti jednomu z nejelegantnějších útoků, jaký jsem viděl. Útočníci mohou používat neviditelné Unicode znaky (např. Tag characters nebo format controls) k ukrytí škodlivých instrukcí, které jsou neviditelné pro člověka, ale zpracované AI modelem.
Tato zranitelnost byla demonstrována v HackerOne reportu #3086545 a cílila na MCP (Model Context Protocol) implementaci v Claude Desktop. Útočník mohl vložit skryté instrukce do textu, který vypadal nevinně, ale Claude je přesto následoval.
Obrana je trojvrstvá: nejprve se aplikuje NFKC Unicode normalizace, pak se odstraňují nebezpečné Unicode kategorie přes regex, a nakonec jsou explicitně odstraněny specifické rozsahy znaků (zero-width mezery, directional formátování, byte order marks). Celý proces se opakuje iterativně až do 10 iterací, protože některé znakové „útočné“ sekvence mohou téměř „přeskočit“ normalizaci.
9. Jest neumí mockovat ES moduly :O
V souboru config.ts se na řádku 763 nachází komentář: „We have to put this test code here because Jest doesn’t support mocking ES modules :O“ (včetně emotikonu).
Je to případ, kdy testovací framework (Jest) má omezení, které nutí vývojáře umístit testovací kód přímo do produkčního souboru. V normálním projektu by to vyvolalo code review diskuzi. Tady je to pragmatický přístup s upřímným komentářem – protože alternativa (složitá konfigurace ESM mocků v Jestu) by pravděpodobně zabrala víc času než samotná feature.
10. Model se omlouvá? Zahodit!
V souboru logoV2Utils.ts se na řádku 202 nachází podivná podmínka: pokud souhrn zprávy obsahuje text „I apologize“, celá zpráva se zahodí.
Kontext: tento soubor zpracovává data pro „Year in Review“ – shrnutí uživatelovy práce s Claude Code za rok. Když Claude generuje tato shrnutí, občas se stane, že model začne odpovídat omluvou („I apologize, but I can’t…“). Takový souhrn je pro uživatele bezcenný – nikdo nechce vidět v ročním přehledu omluvu místo statistiky.
Řešení je brutálně jednoduché: pokud se model omlouvá, jeho odpověď se zahodí. Žádné složité parsování, žádná AI analýza sentimentu – prostě hledání řetězce „I apologize“ a hotovo.
Souhrnný postřeh
Co všechna tato bizarní místa spojuje, je napětí mezi ideálním softwarovým inženýrstvím a realitou produkce. Na jedné straně stojí 102KB bezpečnostní modul s komentáři na úrovni akademického článku. Na druhé straně „band-aid“ komentáře a testovací kód v produkčních souborech.
A právě v tom napětí se skrývá ponaučení: světový software není výsledkem dokonalého návrhu. Je to výsledek tisíců pragmatických rozhodnutí, upřímných komentářů a občasného fantasy románu v kódu.