31 марта 2026 года наружу вывалились исходники Claude Code — через sourcemap в npm-пакете. История сама по себе комичная: продукт, призванный помогать писать код, случайно опубликовал не просто дебажные данные, а почти анатомический атлас самого себя.

Но меня интересует не сам факт утечки, а более приземлённый вопрос: что там внутри? Если убрать обычное «вау, утекло», остаётся другая интонация — ну-ка, посмотрим, что тут у нас (или «там у них»?), и нормально ли написан код.

Да, написано с головой. Даже с душой. Но и с очень характерными симптомами продукта, который из «удобного CLI для общения с моделью» давно превратился в маленькую операционную систему для одного терминала.

Сразу неприятная правда: это не аккуратный git checkout

Первое, что бросается в глаза: перед нами не идеальный репозиторий разработчика. Нет привычных package.json, tsconfig.json и прочей обвязки. Вместо этого — смесь TypeScript-кода, следов сборки и трансформаций.

Часть импортов ведёт на файлы, которых в этой копии нет: assistant/index.ts, assistant/gate.ts, proactive/index.js, daemon/main.js, environment-runner/main.js и KAIROS-специфичные инструменты. Это важно: наружу попал не git-репозиторий, а огромный snapshot, восстановленный из sourcemap. Перед нами — крупный, но местами неполный слепок клиентского кода.

Например, screens/REPL.tsx начинается с react/compiler-runtime — это уже не чистый TSX, а результат трансформаций React Compiler. А main.tsx выглядит ближе к исходнику: там ранние profileCheckpoint, префетч keychain, параллельный MDM-read и другие оптимизации старта.

Это ключевая оговорка: мы смотрим не на музейный экспонат, а на крупную, но рваную выгрузку внутренностей. Выводы лучше делать осторожно: не «вот весь секретный продукт», а «вот очень говорящий срез того, как клиент реально устроен».

Первое впечатление: это не «маленький CLI»

Снаружи Claude Code позиционируется как CLI для разработчика. Внутри — это скорее фреймворк для терминальной среды, к которому приделали команду claude.

entrypoints/cli.tsx — настоящий вокзал маршрутов:

• лёгкая ветка для --version;
• отдельный путь для вывода system prompt;
• режимы для MCP-серверов;
• daemon;
• remote-control и bridge-режим;
• фоновые сессии ps/logs/attach/kill;
• environment-runner;
• self-hosted-runner;
• работа через tmux и worktree.

Это не «запуск чата в терминале». Это многорежимный рантайм, у которого CLI — всего лишь фасад.

Здесь появляется раздвоение между симпатией и скепсисом.

Симпатия: команда понимает цену быстрого старта. В cli.tsx почти всё тяжёлое подгружается динамически. Комментарии прямолинейны: All imports are dynamic to minimize module evaluation for fast paths, Fast-path for --version has zero imports beyond this file, workers are lean.

Пользовательская польза проста: если вы просите что-то элементарное, система не должна разворачивать полмира. Это не косметика — это нормальная инженерия для большого CLI.

Скепсис: когда продукт знает про daemon, bridge, remote, self-hosted runner, tmux, worktree, MCP и UI одновременно, он перестаёт быть CLI. Он становится похож на аэропорт, где на схеме уже страшно, а жить можно только потому, что повсюду указатели.

Главный герой этой пьесы: огромный main.tsx

Любая система рано или поздно выдаёт точку гравитационного коллапса. У Claude Code это — main.tsx.

Большой entrypoint — не преступление. Но когда через один файл проходят:

• инициализация;
• выбор режима;
• system prompt;
• tool pool;
• feature flags;
• remote-сессии;
• KAIROS/Proactive;
• structured output;
• запуск UI;
• восстановление сессий;

— это уже не «точка входа», а центральная нервная система.

Плюс: все ключевые развилки в одном месте — архитектуру удобно читать. Минус: файл превращается в склад компромиссов. В коде мелькают конструкции вроде «сначала включим proactive mode до getTools(), иначе SleepTool.isEnabled() не сработает». Это не баг, а следствие масштаба.

Хороший инженерный запах смешан со следами долгой эволюции. В начале кто-то хотел написать аккуратный CLI. Потом он обрастал режимами, те начали конфликтовать, и их повесили на feature-флаги. Результат — перед нами.

Технически это React-приложение, которое притворяется терминалом

Ещё один важный момент: Claude Code — это не «суровый консольный бинарник». Это React-приложение на Ink, живущее в терминале.

Из-за этого screens/REPL.tsx — не просто экран чата, а полноценный фронтенд-комбайн:

• уведомления;
• модалки;
• IDE-интеграция;
• MCP-соединения;
• плагины;
• загрузка навыков;
• teammate-режим;
• remote-callout;
• dialog priority;
• transcript mode;
• floating UI;
• и, конечно, Buddy.

Это объясняет характер продукта. Claude Code не просто «посылает промпт и печатает ответ». Он постоянно синхронизирует состояние, фильтрует инструменты, подмешивает плагины, решает, какой режим активен, и рендерит всё это в терминал.

Иными словами: это фронтенд. Просто фронтенд, которому тесно в браузере, и он переехал в терминал — со всеми травмами.

Перед нами не один агент, а диспетчерская

Самый важный архитектурный вывод: Claude Code построен не вокруг «главной модели», а вокруг оркестрации.

AgentTool в tools/AgentTool/AgentTool.tsx — не декоративная добавка, а один из главных механизмов системы. Агента можно:

• запустить синхронно;
• отправить в background;
• изолировать в отдельный worktree;
• в некоторых сборках — увести в remote;
• сделать teammate в команде;
• ограничить набором доступных агентов;
• посадить на другой permission mode.

Это уже не «у нас есть субагенты». Это уровень «у нас есть инфраструктура жизненного цикла субагентов».

Особенно впечатляют детали:

• для async-агентов — отдельная регистрация, прогресс и уведомления;
• worker получает собственный tool pool, а не просто наследует от родителя;
• worktree-изоляция создаётся как часть маршрута исполнения;
• fork-path заботится о кэш-идентичности system prompt и набора tools.

Здесь видно взрослую инженерную мысль: не просто «давайте позовём вторую модель», а «давайте сделаем так, чтобы она не сломала контекст, права, cwd и жизненный цикл».

Это одна из сильнейших частей системы. Многие AI-инструменты красиво показывают слово «agents», а внутри — один Promise.all и молитва. Здесь не так. Здесь агентность доведена до состояния инфраструктуры.

При этом они понимают: агентность легко превращается в балаган

Показательный пример — встроенный Explore-агент в tools/AgentTool/built-in/exploreAgent.ts.

Это не просто роль, а почти педагогически выписанный характер:

• только чтение;
• никаких write/edit/delete;
• никаких redirect и heredoc;
• максимум поиска и анализа;
• по возможности — параллельные grep/read-вызовы.

Это хороший момент для понимания философии Claude Code. Команда не доверяет даже своим агентам настолько, чтобы оставлять поведение «ну он сам разберётся». Каждый режим стараются ограничить не только технически, но и риторически — через системную инструкцию.

Продукт строится на двух тезисах:

1. Мы хотим дать модели больше самостоятельности.
2. Мы понимаем, что без намордника она поведёт себя как стажёр на третий день после дедлайна.

Это разумный взгляд на современные агентные системы.

Инструменты здесь оркестрируются всерьёз, а не для демо

Отдельно впечатлил слой исполнения инструментов.

В services/tools/toolOrchestration.ts вызовы делятся на concurrency-safe и всё остальное. Система не просто запускает инструменты подряд — она группирует read-only и безопасные вызовы в параллельные пачки, а рискованные гоняет сериализованно.

Дальше — services/tools/StreamingToolExecutor.ts. Здесь видно, что люди уже натерпелись реальных проблем:

• отдельная логика отмены соседних tool call, если один из параллельных упал;
• различие между user_interrupted, sibling_error и streaming_fallback;
• аккуратная буферизация результатов для правильного порядка вывода;
• учёт поведения инструментов при interrupt.

Здесь заканчивается «прототип для AI» и начинается продукт. Прототип умеет делать tool call. Продукт — переживать, что он застрянет, будет прерван, конфликтнет с соседним и сломает UI.

Паранойя в Bash-слое заслуживает отдельной премии

Маркетингово: Claude Code — «попроси модель выполнить команду». В коде: «мы потратили чудовищное количество сил на то, чтобы команда не стала способом самоубийства».

Файлы tools/BashTool/bashPermissions.ts и tools/BashTool/bashSecurity.ts выглядят как коллективный дневник команды, которую уже укусил shell.

Там блокируются вещи, о которых многие вспоминают раз в год:

• command substitution;
• process substitution;
• heredoc-краевые случаи;
• zsh equals expansion;
• zmodload, ztcp, zpty и другие радости;
• обфусцированные флаги;
• опасные префиксы через env, sudo, nice, timeout;
• странные формы whitespace и экранирования.

Это выглядит почти маниакально, но в хорошем смысле. Потому что видно: Claude Code писали не те, кто обсуждает «агентов будущего» на слайдах, а те, кто уже видел, как LLM ломает shell.

С инженерной точки зрения — один из самых зрелых слоёв. С эстетической — напоминание, что вся AI-магия быстро упирается в банальное: «а теперь не дай модели пробить дыру через bash».

Дальше начинается самое человеческое: Buddy, Dream и прочая психотерапия для CLI

Самые обсуждаемые фрагменты утечки — не orchestration и не permissions, а вещи, которые делают продукт неожиданно человечным.

Каталог buddy/ выглядит так, будто дизайнер и геймдизайнер внезапно получили свободу в корпоративном CLI.

Buddy — терминальный компаньон с ASCII-спрайтами, пузырями речи, анимацией, сердечками после «погладить» и тизером на 1–7 апреля 2026 года. В buddy/useBuddyNotification.tsx это оформлено с расчётом на пояса времени и «растянутый» вирусный эффект. А buddy/CompanionSprite.tsx содержит систему рендеринга: тайминги, fade, narrow-mode, reserved columns, idle sequence.

Смешно, что вокруг Buddy уже выросла мифология. README рисует одних существ, а реальный buddy/types.ts — гораздо прозаичнее: duck, goose, blob, cat, capybara, robot, mushroom, chonk. Утёкший код моментально оброс фанфиком — ещё один повод читать файлы, а не пересказы.

Самая забавная деталь — в промпте buddy/prompt.ts: модели прямо говорят, что рядом сидит существо, которое отвечает в отдельном пузыре, и ей лучше не лезть с болтовнёй.

Это иллюстрация того, во что превращаются современные AI-продукты. С одной стороны — серьёзный инструмент. С другой — терминальный питомец, которому нужно место в layout, реплики и режим «не мешайся, когда говорит зверёк».

Это не нелепо. Это закономерная стадия эволюции продукта, который хочет жить рядом с человеком дольше пяти минут.

Если Buddy — маркетинговая человечность, то autoDream — архитектурная поэзия.

В services/autoDream/autoDream.ts живёт механизм фоновой консолидации памяти. Не «сохранить заметку», а именно dream: отдельный forked subagent, который запускается при:

• прошедших часах с последней консолидации;
• накоплении новых сессий;
• удачном взятии lock.

А в services/autoDream/consolidationPrompt.ts это оформлено как ритуал:

1. Осмотреться.
2. Собрать свежий сигнал.
3. Сконсолидировать память.
4. Подчистить индекс и противоречия.

Самое прекрасное — не название, а дисциплина. «Сон» не дают запускать слишком часто. Ему ограничивают инструменты. Ему объясняют, что транскрипты большие — читать целиком не надо. Ему велят переводить относительные даты в абсолютные. Это хороший инженерный дизайн, замаскированный под художественный термин.

То есть да, Claude Code буквально «видит сны». Но с lock-файлом, дедупликацией и read-only Bash. Это важное уточнение.

Undercover Mode: самая смешная и самая показательная часть

Если выбрать один фрагмент, передающий дух всей утечки, — это utils/undercover.ts.

Там живёт режим для работы сотрудников Anthropic в публичных репозиториях. И написан он серьёзно:

• не палить внутренние имена моделей;
• не светить внутренние project names;
• не писать «Generated with Claude Code»;
• не добавлять AI-attribution;
• если не уверены, что репозиторий внутренний — работаем undercover.

Продукт умеет делать вид, что он не продукт.

Можно спорить о корпоративной этике, но как инженерный артефакт это бесценно. Он показывает два факта:

1. Claude Code используется в реальной работе с публичными репозиториями.
2. Команда осознаёт репутационные и информационные риски.

Это холодный душ для тех, кто думает про AI-кодинг как про «просто интерфейс к модели». Это ещё и контроль утечек, атрибуции, prompt-режимов, привилегий и даже риторики commit message.

KAIROS, PROACTIVE и привкус отсутствующего куска пазла

По коду видно: в продукте есть или планировался слой «постоянно живущего» ассистента: KAIROS, PROACTIVE, Brief-режим, push-нотификации.

Но есть оговорка: в этой выгрузке это читается неравномерно.

main.tsx и screens/REPL.tsx ссылаются на assistant/index.js, assistant/gate.js и другие KAIROS-сущности. При этом каталог assistant/ почти пуст — там только assistant/sessionHistory.ts. То же с proactive/index.js и инструментами отправки файлов/нотификаций: код знает о них, но модули отсутствуют.

Это антидот против конспирологии. Исходников много, но не всё дошло одинаково. Где-то — полный слой. Где-то — только интерфейсы, флаги, вызовы и контуры.

Поэтому про KAIROS правильнее говорить так: код подтверждает существование этой линии развития, но не даёт весь внутренний модуль целиком.

Плагины: да, система есть; нет, в этом репо она не раскрыта полностью

У пользователя может возникнуть вопрос: «А где, собственно, все плагины?»

С одной стороны, плагинная инфраструктура серьёзная:

• hooks/useManagePlugins.ts загружает plugin commands, agents, hooks, MCP и LSP;
• services/plugins/PluginInstallationManager.ts — фоновые установки и авто-refresh;
• services/mcp/MCPConnectionManager.tsx — нормальный connection layer;
• skills/bundledSkills.ts — ленивая распаковка встроенных навыков.

С другой — в этой копии картина скромная:

• в plugins/ — две заготовки;
• plugins/bundled/index.ts говорит, что встроенные плагины не зарегистрированы;
• реальная «начинка» живёт в bundled skills, MCP-интеграциях и внешних маркетплейсах.

Формально архитектура огромная. Практически — в этой выгрузке она видна как каркас и загрузчик, а не как коллекция готовых расширений. Это ещё одна причина не повторять «утёк весь Claude Code»: утёк большой пласт клиентского кода, но из-за способа утечки не все слои представлены одинаково.

Это типично: самое сложное — не написать плагин, а построить систему загрузки, доверия, политик, hot-reload, MCP-подключения и обновления маркетплейса. Именно это и видно в коде.

Самая «вкусная» археология: hidden modes и фичефлаги

Если убрать эмоции и посчитать feature(...), выясняется: самый частый персонаж в коде — не Claude, не Tool, не Agent, а флаг.

Часто всплывают: KAIROS, TRANSCRIPT_CLASSIFIER, TEAMMEM, VOICE_MODE, BASH_CLASSIFIER, KAIROS_BRIEF, PROACTIVE, COORDINATOR_MODE, BRIDGE_MODE, BUDDY, CHICAGO_MCP, ULTRAPLAN, BG_SESSIONS, AGENT_TRIGGERS, WEB_BROWSER_TOOL, TERMINAL_PANEL, REVIEW_ARTIFACT, CCR_MIRROR и другие.

Это ключевой момент: Claude Code живёт не как монолит, а как набор режимов, собираемых и вырезаемых рантаймом через GrowthBook-конфиги вроде tengu_ultraplan_model, tengu_remote_backend, tengu_onyx_plover, tengu_ccr_bridge.

Нужна дисциплина формулировки. Наличие флага не означает shipped-функцию. Корректнее: код подтверждает существование реализованной или частично реализованной линии продукта, скрытой за compile-time и runtime gates.

KAIROS и PROACTIVE: Claude, который не ждёт, пока его позовут

Это самый жирный скрытый пласт. В main.tsx KAIROS и PROACTIVE встречаются постоянно: ранние require('./assistant/index.js'), ветки brief mode, отдельная активация assistant mode, каналы, UX-поток, подготовка под teammate context.

Снаружи это читается так: внутри давно есть или серьёзно прорабатывался режим «постоянно живущего» помощника, который существует рядом с пользователем. В этом направлении — KAIROS_BRIEF, KAIROS_CHANNELS, KAIROS_PUSH_NOTIFICATION, KAIROS_GITHUB_WEBHOOKS.

Оговорка: в этой выгрузке KAIROS виден по каркасу, вызовам и гейтам, а не по полному модулю. Линия продукта есть, но внутренний assistant-слой не раскрыт целиком.

ULTRAPLAN: режим, в котором Claude уходит думать отдельно от вас

ULTRAPLAN — один из самых красивых артефактов как продуктовая идея. В commands/ultraplan.tsx — 30-минутный таймаут, работа с удалённой CCR-сессией, браузерный approval loop, polling статуса и развилка «выполнять дальше удалённо или телепортировать план обратно локально».

Это не «покажи chain-of-thought», а отдельный планировочный ритуал с удалённой инфраструктурой. И смешно, что рядом есть keyword trigger для ultraplan в utils/processUserInput/processUserInput.ts.

В коде просматривается режим «дай мне полчаса отдельно подумать и потом вернись с планом». Для статьи — подарок.

BUDDY: скрытый тамагочи, которого никто не просил, но все бы обсуждали

BUDDY встречается реже, но как культурный артефакт он мощнее половины enterprise-фич. В buddy/CompanionSprite.tsx — полноценный UI-движок для терминального зверька: idle sequence, fade-out пузыря, narrow-mode, резервация колонок, сердечки после pet interaction. В buddy/prompt.ts модели объясняют, что рядом сидит существо, и лучше ему не мешать.

Это напоминание: серьёзные AI-продукты неизбежно обрастают не только precision/recall, но и характером. А потом кто-то пишет в production-коде систему показа пузыря речи для ASCII-питомца.

BRIDGE_MODE, CCR_MIRROR и remote-control: терминал как тонкий клиент к удалённой среде

По entrypoints/cli.tsx, bridge/ и remote/ видно: у Claude Code есть не один «локальный» режим. BRIDGE_MODE открывает remote-control/bridge path, CCR_AUTO_CONNECT и CCR_MIRROR намекают на связь с Claude Code on the web и удалёнными контейнерами, а tengu_remote_backend в main.tsx подчёркивает, что remote backend — отдельная ось продукта.

Флаги рассказывают о стратегии лучше презентации. Строят не просто CLI, а связку «локальный интерфейс + удалённая среда + мост между ними».

TEAMMEM, autoDream и память как отдельный продукт внутри продукта

Обычный AI-клиент хранит историю. Claude Code строит мемориальную бюрократию.

TEAMMEM размазан по claudemd, teamMemorySync и memory-компонентам; autoDream живёт через tengu_onyx_plover; EXTRACT_MEMORIES и session memory накладываются сверху. В сумме: память — не «удобная опция», а отдельный продуктовый слой со своей синхронизацией, лимитами, watch-логикой, защитой от секретов и фоновым уходом за собой.

Это один из лучших сюжетов: AI-индустрия много говорит о «долговременной памяти», но редко показывает, сколько скучной инженерии стоит за этим.

CHICAGO_MCP, WEB_BROWSER_TOOL и прочие боковые ходы

Есть и менее громкие, но характерные режимы.

CHICAGO_MCP включает отдельный computer-use MCP path. WEB_BROWSER_TOOL влияет на Claude-in-Chrome hint. TERMINAL_PANEL, QUICK_SEARCH, HISTORY_PICKER, MESSAGE_ACTIONS, AUTO_THEME, WORKFLOW_SCRIPTS — это уже не базовая функциональность, а превращение терминального клиента в полноценную оболочку.

Это в духе больших продуктов: сначала «ещё одна опция», потом «ещё один режим», потом понимаешь, что строишь собственную настольную среду — только в тексте.

BG_SESSIONS, DAEMON, SELF_HOSTED_RUNNER, BYOC_ENVIRONMENT_RUNNER

Здесь особенно ломается наивная картина «CLI = один процесс, один запрос, один ответ». В entrypoints/cli.tsx отдельно живут BG_SESSIONS, DAEMON, SELF_HOSTED_RUNNER, BYOC_ENVIRONMENT_RUNNER. Система строится под длинноживущие процессы, фоновую жизнь, внешние окружения и сценарии, где локальная консоль — не главный актор.

Это делает код тяжелее, но честнее. Команда не притворяется, что продукт останется «маленьким terminal helper». Они уже пишут платформу.

И всё это вместе выглядит не как беспорядок, а как метод выживания

Из хорошего:

• можно держать внутренние и внешние сборки рядом;
• можно dogfood-ить фичи на сотрудниках;
• можно жёстко выкидывать код через dead code elimination;
• можно быстро катать эксперименты без ломания продукта;
• можно вести параллельно несколько линий развития: CLI, remote, assistant, memory, plugins, MCP.

Из плохого:

• архитектура читается как слоёный пирог решений;
• некоторые инварианты хрупки — порядок инициализации зависит от флагов;
• постороннему код напоминает археологию внутренних экспериментов и A/B-тестов;
• отдельные подсистемы — скорее контур, чем раскрытый модуль.

У такого продукта почти нет другого пути. Когда одновременно строишь CLI, агентную платформу, терминальный UI, память, remote-контур и полигон для новых режимов, feature-флаг перестаёт быть слабостью. Он становится способом не развалиться по дороге.

Так нормально ли это написано?

Мой ответ: да, в целом — сильно. Но сильно как большой живой продукт, а не как изящная учебная архитектура.

Что здесь хорошо:

• внимание к startup performance;
• оркестрация субагентов сделана серьёзно;
• permission и Bash-безопасность проработаны болезненно тщательно;
• terminal UI не выглядит игрушкой;
• memory, MCP, plugins и remote-режимы связаны в одну систему, а не в россыпь демо-модулей.

Что болит:

• слишком много центростремительности вокруг main.tsx;
• фичефлагов столько, что код напоминает карту политических союзов в поздней античности;
• некоторые подсистемы — почти отдельные продукты внутри продукта;
• сама выгрузка показывает, насколько много важного вынесено в недостающие куски, маркетплейсы и внутренние сборки.

Главный вывод — не язвительный, а уважительный.

Claude Code в этой утечке не выглядит «обёрткой над API». Он выглядит как тяжёлый, амбициозный, иногда перегруженный, но вполне серьёзный программный продукт. Со своими шрамами. Со своими перегибами. Со своим корпоративным желанием быть и удобным, и безопасным, и расширяемым, и чуть-чуть живым.

А ещё он выглядит как продукт, который хочет стать не просто CLI, а средой обитания для модели.

Buddy внизу экрана. Сны по ночам. Undercover в публичных репозиториях. Агентные команды. Remote-сеансы. MCP. Плагины. Огромный REPL на React.

В какой-то момент понимаешь: смотришь не на «клиент для Claude», а на первую неловкую, но вполне рабочую попытку собрать персональную операционную систему для AI-помощника.

Это и есть самая интересная часть всей истории.

31 марта 2026 года наружу буквальновывалилисьисходники Claude Code (через sourcemap в npm‑пакете). История уже сама по себе комичная: продукт, который помогает писать код и в теории должен быть особенно аккуратен с публикацией артефактов, случайно публикует не просто кусок дебажной информации, а почти анатомический атлас самого себя.

Но меня в этой истории интересует не столько сам факт утечки, сколько более приземлённый вопрос:что там внутри?Если убрать обычное для таких случаев «вау, утекло», остаётся более интересная интонация: ну‑ка, посмотрим, что тут у нас (или «там у них»?) и нормально ли там написан код.

Да, написано с головой. Даже с душой. Но и с очень характерными симптомами продукта, который из «удобного CLI для общения с моделью» давно мутировал в маленькую операционную систему для одного терминала.

Сразу неприятная правда: это не аккуратный git checkout

Первое, что бросается в глаза при прогулке по дереву без романтики: перед нами не идеальный репозиторий разработчика. Тут нет привычныхpackage.json,tsconfig.jsonи прочей обвязки, зато есть характерная смесь живого TypeScript‑кода, следов сборки и трансформаций.

Более того, часть импортов в коде указывает на файлы, которых в этой копии просто нет:assistant/index.ts,assistant/gate.ts,proactive/index.js,daemon/main.js,environment-runner/main.js, а также несколько KAIROS‑специфичных инструментов. Это важно проговорить именно в контексте способа утечки: наружу вышел не git‑репозиторий, а огромный source snapshot, восстановленный из sourcemap и связанных артефактов. Поэтому перед нами не стерильный внутренний checkout «как у разработчика на ноутбуке», а очень крупный, но местами неполный слепок клиентского кода.

Например,screens/REPL.tsxначинается сreact/compiler-runtime: это уже не «чистый авторский TSX», а результат React Compiler‑трансформаций. При этомmain.tsxвыглядит гораздо ближе к исходному коду и начинается с ручных оптимизаций старта: ранниеprofileCheckpoint, префетч keychain, параллельный MDM‑read и так далее.

Это важная оговорка для всей статьи. Мы смотрим не на музейный экспонат «исходники как они лежали у команды», а на очень крупную и местами рваную выгрузку внутренностей клиента. Поэтому самые громкие выводы лучше делать осторожно: не «вот весь секретный продукт», а «вот очень большой и очень говорящий срез того, как этот клиент реально устроен».

Первое впечатление: это не «маленький CLI»

Снаружи Claude Code продаётся как CLI для разработчика. Внутри это ощущается скорее как фреймворк для терминальной среды, к которому случайно приделали командуclaude.

entrypoints/cli.tsxсразу даёт понять, что здесь не один сценарий запуска, а целый вокзал маршрутов:

• облегчённая ветка запуска для--version;
• отдельный путь для вывода system prompt;
• отдельные режимы для MCP‑серверов;
• daemon;
• remote-controlи bridge‑режим;
• фоновые сессииps/logs/attach/kill;
• environment-runner;
• self-hosted-runner;
• работа черезtmuxиworktree.

То есть это не «запускаем чат в терминале». Это многорежимный рантайм, у которого CLI всего лишь фасад.

Здесь появляется первая развилка между симпатией и скепсисом.

Симпатия: команда явно понимает цену старта и ленивой загрузки. Вentrypoints/cli.tsxпочти всё тяжёлое тянется динамическими импортами. Комментарии там вполне прямолинейные:All imports are dynamic to minimize module evaluation for fast paths(«все импорты динамические, чтобы минимизировать загрузку модулей на коротких и простых сценариях запуска»),Fast-path for --version has zero imports beyond this file(«ветка для--versionвообще не тянет ничего за пределами этого файла»),workers are lean(«воркеры должны оставаться лёгкими»).

Пользовательская польза от такого подхода очень простая: если вы попросили программу сделать что‑то элементарное, она не должна ради этого разворачивать полсистемы.--version, служебные команды, фоновые воркеры и похожие режимы должны запускаться быстро, потреблять меньше памяти и реже ломаться из‑за побочных зависимостей. Это не косметика, а нормальная инженерия для большого CLI.

Скепсис: когда продукту приходится знать про daemon, bridge, remote, self‑hosted runner, tmux, worktree, MCP и UI одновременно, он начинает быть похожим не на CLI, а на аэропорт, где на схеме уже страшно, а жить ещё можно только потому, что везде развешаны указатели.

Главный герой этой пьесы: огромный main.tsx

Любая такая система рано или поздно выдаёт свою точку гравитационного коллапса. У Claude Code этоmain.tsx.

Сам по себе большой entrypoint не преступление. Но когда файл становится центром, через который проходят:

• инициализация;
• выбор режима;
• system prompt;
• tool pool;
• feature flags;
• remote‑сессии;
• KAIROS/Proactive;
• structured output;
• UI‑пуск;
• восстановление сессий;

это уже не «точка входа», а центральная нервная система.

У такого подхода есть плюс: все ключевые продуктовые развилки лежат в одном месте, архитектуру удобно читать. Но есть и минус: файл превращается в склад компромиссов. Поэтому в коде повсюду мелькают конструкции в стиле «сначала включим proactive mode доgetTools(), потому что иначеSleepTool.isEnabled()не сработает». Это не баг, а следствие масштаба.

Хороший инженерный запах здесь смешан со следами очень долгой эволюции. В начале проекта кто‑то явно хотел написать аккуратный CLI. Потом CLI начал обрастать режимами, потом режимы начали конфликтовать, потом их стали развешивать на feature‑флаги и ранние проверки. Результат лежит перед нами.

Технически это React‑приложение, которое притворяется терминалом

Ещё одна вещь, которую полезно проговорить прямо: Claude Code внутри не «суровый консольный бинарник из мира curses». Это React‑приложение на Ink и сопутствующей инфраструктуре, только живёт оно не в браузере, а в терминале.

Из‑за этогоscreens/REPL.tsxвыглядит не как «экран чата», а как полноценный фронтенд‑комбайн:

• уведомления;
• модалки;
• IDE‑интеграция;
• MCP‑соединения;
• плагины;
• загрузка навыков;
• teammate‑режим;
• remote‑callout;
• dialog priority;
• transcript mode;
• floating UI;
• и, конечно, Buddy.

Это одновременно впечатляет и отлично объясняет, почему у продукта такой характер. Claude Code не просто «посылает промпт и печатает ответ». Он постоянно синхронизирует состояние, фильтрует набор инструментов, подмешивает плагины и MCP‑клиенты, решает, какой режим сейчас активен, и рендерит всё это в один терминальный интерфейс.

Иными словами: это фронтенд. Просто фронтенд, которому тесно в браузере, и он переехал в терминал вместе со своими травмами.

Перед нами не один агент, а диспетчерская

Самый важный архитектурный вывод после прогулки по коду такой: Claude Code построен не вокруг «главной модели», а вокруг оркестрации.

AgentToolвtools/AgentTool/AgentTool.tsx— не декоративная добавка, а один из главных механизмов всей системы. Агент можно:

• запустить синхронно;
• отправить в background;
• изолировать в отдельныйworktree;
• в некоторых сборках увести в remote;
• сделать teammate внутри команды;
• ограничить набором доступных агентов;
• посадить на другой permission mode.

И это уже не уровень «у нас есть субагенты». Это уровень «у нас есть инфраструктура жизненного цикла субагентов».

Особенно хороши детали:

• для async‑агентов есть отдельная регистрация, прогресс и уведомления;
• worker получает собственный tool pool, а не просто наследует всё от родителя;
• worktreeизоляция создаётся прямо как часть маршрута исполнения;
• fork‑path отдельно заботится о кэш‑идентичности system prompt и набора tools.

То есть здесь видно взрослую инженерную мысль: не просто «давайте позовём вторую модель», а «давайте сделаем так, чтобы эта вторая сущность не сломала контекст, права, cwd и жизненный цикл».

Это одна из самых сильных частей всей системы.

Потому что очень многие AI‑инструменты красиво показывают слово «agents», а внутри там одинPromise.allи молитва. Здесь не так. Здесь агентность довели до состояния инфраструктуры.

При этом они прекрасно понимают, что агентность легко превращается в балаган

Показательный пример — встроенный Explore‑агент вtools/AgentTool/built-in/exploreAgent.ts.

Это не просто роль, а почти педагогически выписанный характер:

• только чтение;
• никаких write/edit/delete;
• никаких redirect и heredoc;
• максимум поиска и анализа;
• по возможности распараллеливать grep/read‑вызовы.

Это хороший момент для понимания всей философии Claude Code. Команда явно не доверяет даже собственным же агентам настолько, чтобы оставлять поведение «ну он сам разберётся». Каждый специализированный режим стараются ограничить не только технически, но и риторически, прямо через системную инструкцию.

То есть продукт строится на любопытной паре тезисов:

1. Мы очень хотим дать модели больше самостоятельности.
2. Мы прекрасно понимаем, что без намордника она моментально начнёт вести себя как стажёр на третий день после дедлайна.

Это, кстати, разумный взгляд на современные агентные системы.

Инструменты здесь оркестрируются всерьёз, а не для демо

Отдельно мне понравился слой исполнения инструментов.

Вservices/tools/toolOrchestration.tsвызовы делятся на concurrency‑safe и всё остальное. То есть система не просто умеет запускать несколько инструментов подряд, она осознанно группирует read‑only и безопасные вызовы в параллельные пачки, а рискованные гоняет сериализованно.

Дальше идётservices/tools/StreamingToolExecutor.ts, и там видно, что люди уже натерпелись реальных проблем:

• есть отдельная логика для отмены соседних tool call, если один из параллельных упал;
• есть различие междуuser_interrupted,sibling_errorиstreaming_fallback;
• есть аккуратная буферизация результатов, чтобы отдавать их в правильном порядке;
• отдельно учитывается поведение инструментов при interrupt.

Это то место, где «прототип для AI» заканчивается и начинается продукт. Потому что прототип умеет делать tool call. Продукт умеет переживать, что tool call застрянет, будет прерван, конфликтнёт с соседним и сломает UI.

Паранойя в Bash‑слое заслуживает отдельной премии

Если смотреть только маркетингово, Claude Code — это «попроси модель выполнить команду». Если смотреть в код, это «мы потратили чудовищное количество сил на то, чтобы команда не стала способом самоубийства».

Файлыtools/BashTool/bashPermissions.tsиtools/BashTool/bashSecurity.tsвыглядят как коллективный дневник команды, которую уже один раз очень больно укусил shell.

Там блокируются и учитываются вещи, о которых половина разработчиков вспоминает раз в год:

• command substitution;
• process substitution;
• heredoc‑краевые случаи;
• zsh equals expansion;
• zmodload,ztcp,zptyи прочие радости;
• обфусцированные флаги;
• опасные префиксы черезenv,sudo,nice,timeout;
• странные формы whitespace и экранирования.

Это выглядит почти маниакально, но в хорошем смысле. Потому что именно здесь особенно хорошо видно: Claude Code писали не люди, которые обсуждают «агентов будущего» на слайдах, а люди, которые уже насмотрелись на реальное поведение LLM в shell и решили больше не удивляться.

С инженерной точки зрения это один из самых зрелых слоёв проекта.

С эстетической точки зрения — это напоминание, что вся современная AI‑магия очень быстро упирается в банальное: «а теперь не дай модели случайно или не случайно пробить себе дыру черезbash».

Дальше начинается самое человеческое: Buddy, Dream и прочая психотерапия для CLI

Самые обсуждаемые фрагменты этой утечки — не orchestration и не permissions, а вещи, которые делают продукт неожиданно человечным.

Каталогbuddy/выглядит так, будто кто‑то в середине корпоративного CLI внезапно разрешил дизайнеру и геймдизайнеру провести свой праздник жизни.

Buddy — это терминальный компаньон с ASCII‑спрайтами, пузырями речи, анимацией, сердечками после «погладить» и отдельным тизерным окном на 1–7 апреля 2026 года. Вbuddy/useBuddyNotification.tsxэто всё ещё и оформлено с явным расчётом на пояса времени и «растянутый» вирусный эффект. Аbuddy/CompanionSprite.tsxсодержит нормальную маленькую систему рендеринга персонажа: тайминги, fade, narrow‑mode, reserved columns, idle sequence.

Отдельно смешно, что вокруг Buddy уже успела вырасти собственная мифология. README в зеркале рисует один набор существ, а реальныйbuddy/types.tsгораздо прозаичнее и веселее:duck,goose,blob,cat,capybara,robot,mushroom,chonk. То есть даже утёкший код моментально оброс вторичным фанфиком, и это хороший повод читать именно файлы, а не только их пересказы.

Самая смешная деталь не в спрайте, а в промптеbuddy/prompt.ts: модели прямо объясняют, что рядом сидит маленькое существо, которое иногда отвечает в отдельном пузыре, и самой модели в этот момент лучше не лезть с лишней болтовнёй.

Это поразительно точная иллюстрация того, во что превращаются современные AI‑продукты. С одной стороны, перед нами серьёзный инструмент разработки. С другой — терминальный питомец, которому нужно место в layout, реплики и режим «не мешайся, когда говорит зверёк».

Это не выглядит нелепо. Это выглядит как закономерная стадия эволюции продукта, который хочет жить рядом с человеком дольше пяти минут.

Если Buddy — это маркетинговая человечность, тоautoDream— уже архитектурная поэзия.

Вservices/autoDream/autoDream.tsживёт механизм фоновой консолидации памяти. Не «сохранить заметку», а именно dream: отдельный forked subagent, который запускается по трём воротам:

• прошли часы с последней консолидации;
• накопилось достаточно новых сессий;
• удалось взять lock.

А вservices/autoDream/consolidationPrompt.tsэто всё оформлено как ритуал на раз-два-три-четыре:

1. Осмотреться.
2. Собрать свежий сигнал.
3. Сконсолидировать память.
4. Подчистить индекс и противоречия.

Самое прекрасное здесь даже не название, а дисциплина. «Сон» не дают запускать слишком часто. Ему ограничивают инструменты. Ему отдельно объясняют, что транскрипты большие и читать их целиком не надо. Ему велят переводить относительные даты в абсолютные. Это очень хороший инженерный дизайн, замаскированный под художественный термин.

То есть да, Claude Code буквально «видит сны». Но с хорошим lock‑файлом, дедупликацией и read‑only Bash. Это важное уточнение.

Undercover Mode: самая смешная и самая показательная часть

Если бы нужно было выбрать один фрагмент кода, который лучше всего передаёт дух всей утечки, я бы выбралutils/undercover.ts.

Там живёт режим, который нужен для работы сотрудников Anthropic в публичных репозиториях. И написан он не как шутка, а как очень серьёзная инструкция:

• не палить внутренние кодовые имена моделей;
• не светить внутренние project names;
• не писать «Generated with Claude Code»;
• не добавлять никакое AI‑attribution;
• если не уверены, что репозиторий внутренний, работаем undercover.

То есть продукт буквально умеет делать вид, что он не продукт.

Можно сколько угодно спорить о корпоративной этике, но как инженерный артефакт это бесценно. Потому что мгновенно показывает два факта:

1. Claude Code используется в реальной работе с публичными репозиториями.
2. Команда прекрасно осознаёт репутационные и информационные риски того, что модель скажет лишнее.

Вся эта система — отличный холодный душ для тех, кто думает про AI‑кодинг как про «просто интерфейс к модели». Это ещё и контроль утечек, атрибуции, prompt‑режимов, привилегий и даже риторики commit message.

KAIROS, PROACTIVE и привкус отсутствующего куска пазла

По коду отлично видно, что в продукте есть или планировался слой «постоянно живущего» ассистента:KAIROS,PROACTIVE, Brief‑режим, отдельные инструменты вроде отправки файлов пользователю и push‑нотификаций.

Но здесь есть важная трезвая оговорка: в этой выгрузке это читается неравномерно.

main.tsxиscreens/REPL.tsxпостоянно ссылаются наassistant/index.js,assistant/gate.jsи другие KAIROS‑сущности. При этом сам каталогassistant/в этой копии почти пуст: фактически там лежит толькоassistant/sessionHistory.ts. То же самое относится к ряду ожидаемых соседних кусков вродеproactive/index.jsи инструментов отправки файлов/нотификаций пользователю: код явно знает о них, но в слепке, восстановленном из sourcemap, эти модули отсутствуют.

Это очень хороший антидот против конспирологии. Исходников много, очень много, но не всё дошло одинаково полно. Где‑то мы видим полноценный слой. Где‑то только интерфейсы, флаги, вызовы и контуры.

Именно поэтому про KAIROS правильнее говорить так: код уверенно подтверждает существование этой линии развития продукта, но не даёт нам весь внутренний модуль целиком.

Плагины: да, система есть; нет, в этом репо она не раскрыта полностью

У пользователя, который посмотрит на это дерево впервые, может возникнуть естественная реакция: «Подождите, а где, собственно, все плагины?»

С одной стороны, плагинная инфраструктура в коде очень серьёзная:

• hooks/useManagePlugins.tsгрузит plugin commands, agents, hooks, MCP и LSP;
• services/plugins/PluginInstallationManager.tsумеет фоновые установки маркетплейсов и авто‑refresh;
• services/mcp/MCPConnectionManager.tsxживёт как нормальный connection layer;
• skills/bundledSkills.tsумеет лениво распаковывать reference‑файлы для встроенных навыков.

С другой стороны, конкретно в этой копии репозитория картина очень скромная:

• вplugins/лежат буквально две заготовки;
• plugins/bundled/index.tsпрямо говорит, что встроенные плагины пока не зарегистрированы;
• реальная «начинка» во многом живёт не вplugins/, а в bundled skills, MCP‑интеграциях и внешних маркетплейсах.

Формально плагинная архитектура огромная. Практически же в этой выгрузке она видна скорее как каркас и загрузчик, а не как коллекция готовых расширений. Это ещё одна причина не повторять без оговорок формулу «утёк весь Claude Code»: утёк очень большой пласт клиентского кода, но из‑за способа утечки через sourcemap не все прикладные слои представлены одинаково плотно.

Это типично для современных платформ. Самое сложное там давно не «написать ещё один плагин», а построить систему загрузки, доверия, политики, hot‑reload, ошибок, MCP‑подключения и обновления маркетплейса. Именно это в коде и видно.

Самая «вкусная» археология: hidden modes и фичефлаги

Если убрать эмоции и просто посчитатьfeature(...), выясняется забавное: самый частый персонаж в коде — не Claude, не Tool и даже не Agent, а флаг.

В репозитории особенно часто всплываютKAIROS,TRANSCRIPT_CLASSIFIER,TEAMMEM,VOICE_MODE,BASH_CLASSIFIER,KAIROS_BRIEF,PROACTIVE,COORDINATOR_MODE,BRIDGE_MODE,BUDDY,CHICAGO_MCP,ULTRAPLAN,BG_SESSIONS,AGENT_TRIGGERS,WEB_BROWSER_TOOL,TERMINAL_PANEL,REVIEW_ARTIFACT,CCR_MIRRORи ещё длинный хвост более редких сущностей.

Это очень важный момент для чтения всего дерева. Claude Code живёт не как единый монолит, а как набор режимов, которые то собираются, то вырезаются, то догейтваются рантаймом через GrowthBook‑конфиги вродеtengu_ultraplan_model,tengu_remote_backend,tengu_onyx_plover,tengu_ccr_bridgeи десятков других.

Здесь нужна дисциплина формулировки. Наличие флага не означает, что перед нами shipped‑функция для всех пользователей. Корректнее говорить так: код подтверждает существование реализованной или частично реализованной линии продукта, скрытой за compile‑time и runtime gates.

Вот какие «тайники» здесь особенно хороши.

KAIROS и PROACTIVE: Claude, который не ждёт, пока его позовут

Это самый жирный скрытый пласт. Вmain.tsxKAIROSиPROACTIVEвстречаются постоянно: ранниеrequire('./assistant/index.js'), специальные ветки brief mode, отдельная активация assistant mode, отдельные каналы, особый UX‑поток и даже подготовка под teammate context.

Снаружи это читается так: внутри продукта давно есть или очень серьёзно прорабатывался режим «постоянно живущего» помощника, который не просто отвечает на реплики, а существует рядом с пользователем. В этом же направлении лежатKAIROS_BRIEF,KAIROS_CHANNELS,KAIROS_PUSH_NOTIFICATION,KAIROS_GITHUB_WEBHOOKS.

Правильная оговорка здесь одна: в этой выгрузке KAIROS виден скорее по каркасу, вызовам и гейтам, чем по полному модулю. То есть линия продукта бесспорно есть, но целиком внутренний assistant‑слой перед нами не раскрыт.

ULTRAPLAN: режим, в котором Claude уходит думать отдельно от вас

ULTRAPLAN— один из самых красивых артефактов именно как продуктовая идея. Вcommands/ultraplan.tsxесть 30-минутный таймаут, работа с удалённой CCR‑сессией, браузерный approval loop, polling статуса и развилка «выполнять дальше удалённо или телепортировать план обратно локально».

Это уже не «покажи пользователю chain‑of‑thought», а отдельный планировочный ритуал с удалённой инфраструктурой. И очень смешно, что рядом с этим есть ещё keyword trigger дляultraplanпрямо в пользовательском вводе вutils/processUserInput/processUserInput.ts.

В коде реально просматривается режим «дай мне полчаса отдельно подумать и потом вернись с планом». Для статьи это подарок.

BUDDY: скрытый тамагочи, которого никто не просил, но все бы обсуждали

BUDDYвстречается реже, чем KAIROS, но как культурный артефакт он мощнее половины enterprise‑фич. Вbuddy/CompanionSprite.tsxспрятан полноценный маленький UI‑движок для терминального зверька: idle sequence, fade‑out пузыря, narrow‑mode, резервация колонок в layout, сердечки после pet interaction. Вbuddy/prompt.tsмодели отдельно объясняют, что рядом сидит существо со своей репликой и лучше ему не мешать.

Это хорошее напоминание, что серьёзные AI‑продукты неизбежно начинают обрастать не только «precision/recall», но и характером. А потом кто‑то пишет в production‑коде систему показа пузыря речи для ASCII‑питомца.

BRIDGE_MODE, CCR_MIRROR и remote‑control: терминал как тонкий клиент к удалённой среде

Если смотреть поentrypoints/cli.tsx,bridge/иremote/, то становится видно, что у Claude Code есть не один «локальный» режим жизни.BRIDGE_MODEоткрывает remote‑control/bridge path,CCR_AUTO_CONNECTиCCR_MIRRORнамекают на более тесную связь с Claude Code on the web и удалёнными контейнерами, аtengu_remote_backendвmain.tsxдополнительно подсвечивает, что remote backend мыслится как отдельная операционная ось продукта.

Это тот случай, когда флаги рассказывают о стратегии продукта лучше презентации. Тут явно строится не просто CLI, а связка «локальный интерфейс + удалённая среда + мост между ними».

TEAMMEM, autoDream и память как отдельный продукт внутри продукта

Обычный AI‑клиент хранит историю. Claude Code на этом месте уже строит мемориальную бюрократию.

TEAMMEMразмазан поclaudemd,teamMemorySyncи memory‑компонентам;autoDreamживёт своей жизнью черезtengu_onyx_plover;EXTRACT_MEMORIESи session memory накладываются сверху. В сумме это даёт удивительное ощущение: память здесь не «удобная опция», а отдельный продуктовый слой со своей синхронизацией, лимитами, watch‑логикой, защитой от секретов и фоновым уходом за собой.

Это один из лучших сюжетов для статьи: AI‑индустрия много говорит о «долговременной памяти», но редко показывает, сколько скучной инженерии стоит за этим в реальности.

CHICAGO_MCP, WEB_BROWSER_TOOL и прочие боковые ходы

Есть и менее громкие, но очень характерные режимы.

CHICAGO_MCPвключает отдельный computer‑use MCP path вentrypoints/cli.tsx.WEB_BROWSER_TOOLвлияет на то, как показывается Claude‑in‑Chrome hint вmain.tsx.TERMINAL_PANEL,QUICK_SEARCH,HISTORY_PICKER,MESSAGE_ACTIONS,AUTO_THEMEиWORKFLOW_SCRIPTSвыглядят как уже не базовая функциональность, а постепенное превращение терминального клиента в полноценную оболочку со своим UX‑слоем.

Это очень в духе больших продуктов: сначала у тебя «ещё одна опция», потом «ещё один маленький режим», потом ты внезапно понимаешь, что строишь собственную настольную среду, только в тексте.

BG_SESSIONS, DAEMON, SELF_HOSTED_RUNNER, BYOC_ENVIRONMENT_RUNNER

Вот где особенно хорошо ломается наивная картинка «CLI = один процесс, один запрос, один ответ». Вentrypoints/cli.tsxотдельно живутBG_SESSIONS,DAEMON,SELF_HOSTED_RUNNER,BYOC_ENVIRONMENT_RUNNER. То есть система заранее строится под длинноживущие процессы, фоновую жизнь, внешние окружения и сценарии, где локальная консоль уже не главный актор.

Это делает код тяжелее, но и честнее. Команда не притворяется, что продукт останется «маленьким terminal helper». Они уже пишут платформу.

И всё это вместе выглядит не как беспорядок, а как метод выживания

Из хорошего:

• можно держать внутренние и внешние сборки рядом;
• можно dogfood‑ить фичи на сотрудниках;
• можно жёстко выкидывать куски кода через dead code elimination;
• можно быстро катать экспериментальные режимы без того, чтобы ломать весь продукт;
• можно вести параллельно несколько линий развития: CLI, remote, assistant, memory, plugins, MCP.

Из плохого:

• архитектура начинает читаться не как один продукт, а как слоёный пирог решений;
• некоторые инварианты становятся хрупкими, потому что порядок инициализации зависит ещё и от того, какой флаг сейчас включён;
• постороннему читателю код временами напоминает археологию внутренних экспериментов и A/B‑тестов;
• отдельные подсистемы существуют скорее как контур, чем как полностью раскрытый модуль, и это постоянно нужно оговаривать.

У такого продукта почти нет другого пути. Когда одновременно строишь CLI, агентную платформу, терминальный UI, память, remote‑контур и внутренний полигон для новых режимов, feature‑флаг перестаёт быть слабостью. Он становится способом не развалиться по дороге.

Так нормально ли это написано?

Мой ответ такой: да, в целом это написано сильно. Но сильно именно как большой живой продукт, а не как изящная учебная архитектура.

Что здесь правда хорошо:

• видно реальное внимание к startup performance;
• orchestration субагентов сделана серьёзно;
• permission и Bash‑безопасность проработаны болезненно тщательно;
• terminal UI не выглядит игрушкой;
• memory, MCP, plugins и remote‑режимы связаны в одну систему, а не в россыпь демо‑модулей.

Что здесь явно болит:

• слишком много центростремительности вокругmain.tsx;
• feature‑флагов столько, что код местами начинает походить на карту политических союзов в поздней античности;
• некоторые подсистемы читаются как «это уже почти отдельный продукт внутри продукта»;
• сама выгрузка показывает, насколько много важного было вынесено в частично недостающие куски, маркетплейсы и внутренние сборки.

Главный вывод у меня не язвительный, а скорее уважительный.

Claude Code в этой утечке не выглядит «обёрткой над API». Он выглядит как тяжёлый, амбициозный, иногда перегруженный, но вполне серьёзный программный продукт. Со своими шрамами. Со своими перегибами. Со своим абсолютно корпоративным желанием одновременно быть и удобным, и безопасным, и расширяемым, и чуть‑чуть живым.

А ещё он выглядит как продукт, который очень хочет стать не просто CLI, а средой обитания для модели.

Buddy внизу экрана. Сны по ночам. Undercover в публичных репозиториях. Агентные команды. Remote‑сеансы. MCP. Плагины. Огромный REPL на React.

В какой‑то момент понимаешь, что смотришь уже не на «клиент для Claude», а на первую неловкую, но вполне рабочую попытку собрать персональную операционную систему для AI‑помощника.

Это и есть самая интересная часть всей истории.