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

Но меня в этой истории интересует не столько сам факт утечки, сколько более приземлённый вопрос: что там внутри и как это сделано.

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

не моё, но прекрасно

https://www.markdown.engineering/learn-claude-code/

Сразу неприятная правда: это не аккуратный 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 — один из главных механизмов всей системы. Агент можно:

• запустить синхронно;

• отправить в background;

• изолировать в отдельный worktree;

• в некоторых сборках увести в remote;

• сделать teammate внутри команды;

• ограничить набором доступных агентов;

• посадить на другой permission mode.

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

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

• для async‑агентов есть отдельная регистрация, прогресс и уведомления;

• worker получает собственный tool pool, а не копирует его механически у родителя;

• worktree изоляция создаётся прямо как часть маршрута исполнения;

• fork‑path отдельно заботится о кэш‑идентичности system prompt и набора tools.

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

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

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

Показательный пример — встроенный Explore‑агент.

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

• только чтение;

• никаких write/edit/delete;

• никаких redirect и heredoc;

• максимум поиска и анализа;

• по возможности распараллеливать grep/read‑вызовы.

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

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

1. Мы очень хотим дать модели больше самостоятельности.

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

Для современных агентных систем это, пожалуй, один из самых здравых подходов.

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

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

В слое оркестрации инструментов вызовы делятся на concurrency‑safe и всё остальное. Система не ограничивается запуском нескольких инструментов подряд: она осознанно группирует read‑only и безопасные вызовы в параллельные пачки, а рискованные гоняет сериализованно.

Дальше идёт потоковый исполнитель инструментов, и там видно, что люди уже натерпелись реальных проблем:

• есть отдельная логика для отмены соседних tool call, если один из параллельных упал;

• есть различие между user_interrupted, sibling_error и streaming_fallback;

• есть аккуратная буферизация результатов, чтобы отдавать их в правильном порядке;

• отдельно учитывается поведение инструментов при interrupt.

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

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

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

Файлы bashPermissions и bashSecurity выглядят как коллективный дневник команды, которую уже один раз очень больно укусил 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

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

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

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

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

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

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

Dream

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

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

• прошли часы с последней консолидации;

• накопилось достаточно новых сессий;

• удалось взять lock.

В промпте для консолидации это оформлено как четырёхфазный ритуал:

1. Осмотреться.

2. Собрать свежий сигнал.

3. Сконсолидировать память.

4. Подчистить индекс и противоречия.

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

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

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

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

Там живёт режим, который нужен для работы сотрудников 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/ в этой копии почти пуст: фактически там лежит только модуль истории сессий. То же самое относится к ряду ожидаемых соседних кусков вроде proactive/index.js и инструментов отправки файлов или нотификаций пользователю: код явно знает о них, но в слепке, восстановленном из sourcemap, эти модули отсутствуют.

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

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

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

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

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

• слой управления плагинами грузит plugin commands, agents, hooks, MCP и LSP;

• менеджер установки умеет фоновые установки маркетплейсов и auto‑refresh;

• MCP connection layer собран как отдельная подсистема;

• bundled skills умеют лениво распаковывать reference‑файлы для встроенных навыков.

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

• в plugins/ лежат буквально две заготовки;

• встроенные плагины в этой копии по сути не зарегистрированы;

• реальная «начинка» во многом живёт не в 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.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 — один из самых красивых артефактов именно как продуктовая идея. Там есть 30-минутный таймаут, работа с удалённой CCR‑сессией, браузерный approval loop, polling статуса и развилка «выполнять дальше удалённо или телепортировать план обратно локально».

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

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

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

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

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

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

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

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

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 выглядят как уже не базовая функциональность, а постепенное превращение терминального клиента в полноценную оболочку со своим UX‑слоем.

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

BG_SESSIONS, DAEMON, SELF_HOSTED_RUNNER, BYOC_ENVIRONMENT_RUNNER

Вот где особенно хорошо ломается наивная картинка «CLI = один процесс, один запрос, один ответ». Отдельно живут 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. Это тяжёлый, амбициозный и временами перегруженный, но вполне серьёзный программный продукт. По нему видно и шрамы, и компромиссы, и типично корпоративное желание совместить удобство, безопасность, расширяемость и немного «характера».

Короткий вердикт по качеству кода такой:

• как красивый код это не образец;

• как продуктовый код под живую нагрузку и постоянное расширение уровень высокий;

• подход с ленивыми импортами, облегчёнными ветками запуска и жёсткими ограничениями инструментов выглядит осмысленно, а не декоративно;

• главная проблема здесь не в слабой инженерии, а в том, что система уже распухла и местами тянет на несколько продуктов, сросшихся в один.

Если смотреть на всё вместе — Buddy, сны, Undercover, агентные команды, remote‑сеансы, MCP, плагины, огромный REPL на React, — то перед глазами оказывается уже не «клиент для Claude», а ранняя, неровная, но рабочая попытка собрать персональную операционную систему для AI‑помощника.

Именно это и делает всю историю интересной.