Я работаю с Claude Code параллельно на трёх подписках Pro. Коллеги — на своих. Часто работаем в одних и тех же файлах, в один день. Чтобы избежать потерь контекста, конфликтов и дублирования работы, я построила систему координации, вдохновлённую распределёнными системами 1980-х. Три слоя: handoffs, locks и почта. Ниже — как это работает.

Слой 1: Handoffs — «я закончил, подхватывай»

Когда новые сессии Claude приходилось каждый раз заново вводить в курс дела, я внедрила handoffs — короткие сводки в конце сессии, которые читает следующая.

Сначала писала всё в один файл HANDOFF.md. Но при нескольких чатах он быстро сломался: последняя запись перезаписывала остальные. Перешла на append-only модель: каждая сессия создаёт свой файл с уникальным именем.

Имя включает дату, время, первые 8 символов session-id и slug задачи. Два чата не могут создать файл с одинаковым именем — даже в одну секунду, потому что session-id разные. Гонка состояний невозможна без блокировок и брокеров.

Файл INDEX.md тоже append-only: новые записи добавляются в конец, старые не редактируются. Это аналог write-ahead log в базах данных: если сессия умрёт посреди записи, состояние останется согласованным.

Handoff — не дневник, а контракт со следующей сессией. Состоит из пяти секций:

• Цель — зачем сессия проводилась.
• Сделано — конкретные артефакты с путями.
• НЕ сработало — проваленные подходы с причинами.
• Текущее состояние — что работает, что сломано, что заблокировано.
• Следующий шаг — одно конкретное действие.

Пример handoff’а по проекту color-checker:

• Цель: «Color checker: CNN sweep + diffusion, первые результаты»
• Сделано: «CNN baseline median 1.99 deg, 11M params, 21 MB»
• НЕ сработало: «lr=3e-4 — NaN после epoch 10–13, нет gradient clipping»
• Сломано: «Diffusion training OOM на bs=16»
• Следующий шаг: «Inference скрипт для diffusion + visual sheets»

Самая ценная часть — «НЕ сработало». Она экономит часы на повторении ошибок. За четыре дня накопилось 27 handoff’ов — и ни одна ошибка не повторилась.

Handoff укладывается в 1500 токенов. Исходный контекст — около 100K. Компрессия — ~67×, без потерь ключевой информации.

Хуки вместо напоминаний

Писать handoff вручную неудобно. Решение — Stop-hook в Claude Code. Перед закрытием сессии он спрашивает: «Хочешь сохранить handoff?» если работа была содержательной.

На старте новой сессии я пишу: «подхвати handoff по color-checker» — и Claude читает нужный файл.

Иногда модель сама предлагает записать handoff — особенно после завершения крупной задачи или при заполнении контекста на 70–80%. Это её инициатива, а не мой запрос.

Запись — автоматическая (хук или модель). Чтение — одна фраза в начале сессии.

Rollups — когда handoff’ов становится слишком много

На долгих проектах накапливается по 80 handoff’ов. Новая сессия читает последние, а старые — игнорирует. В итоге повторяются уже опровергнутые гипотезы.

Решение — rollup’ы: один файл сворачивает 20 предыдущих handoff’ов. В нём — итог и граница: «свёрнуто до этой даты». Каждому исходному handoff’у добавляется строка rolled_up_into с именем rollup-файла.

Новая сессия читает только rollup и handoff’ы после его границы. Остальное — в архиве.

Имя rollup’а начинается с rollup_ — чтобы было видно в INDEX.md. Frontmatter содержит:

• type: rollup
• covers — список подчинённых файлов
• through — дата-граница

Текст rollup’а — обычный handoff, но за 20 сессий. Паттерн не мой: аналог есть у PavelMuntyan/MF0-1984 в SQLite-схеме. Я адаптировала его под markdown-frontmatter.

Слой 2: Locks — «этот ресурс сейчас мой»

Handoff’ы не решают конфликты за ресурсы: модули кода, GPU, деплой-слоты. Две сессии не могут одновременно рефакторить один модуль — будет конфликт слияния. Или тренировать модель на одной GPU — вторая получит OOM.

Нужны блокировки. Для каждого ресурса — отдельный файл: auth-middleware.lock, gpu-host-a_gpu2.lock. В нём — кто взял, когда, для чего.

Создание файла — атомарное: os.open(path, O_CREAT | O_EXCL). Если файл уже есть — вызов падает. Это гарантирует ядро ОС. Тот же механизм, что у /var/lock и .pid-файлов с 1980-х.

Но lock без heartbeat бесполезен: если сессия упадёт, файл останется. Поэтому активная сессия обновляет timestamp раз в 30–60 минут. Если lock старше четырёх часов — возможно, сессия мертва.

«Возможно» — не «точно». Перед перехватом проверяю ресурс: SSH, nvidia-smi, git-статус. Только если ресурс свободен — перехватываю. Это принцип «доверяй, но проверяй» из Chubby и ZooKeeper.

Рядом с lock-файлом — JSON с метаданными: slug задачи, session-id, время захвата, описание, список файлов. Новая сессия за секунду видит: «auth-middleware занят под рефакторинг», «GPU 2 занята под тренировку».

Я пробовала автоматизировать lock’и через хук PreToolUse, но отказалась: команды слишком разнообразны, парсер дал бы ложные срабатывания. Правильный порядок — сначала соглашение и файлы, автоматизация — только для устойчивых паттернов.

Слой 3: Почта — «Артём, посмотри мой код»

Handoffs — для передачи контекста во времени. Locks — для ресурсов. Но не хватало синхронизации между живыми сессиями.

Раньше я спрашивала у коллеги: «Ты ещё делаешь middleware?» — он смотрел в свой чат, копировал ответ. Три перекладки. Каждый день.

Нужна прямая коммуникация между сессиями. Чтобы я написала — он ответил, я получила. Без одновременности. С гарантиями доставки.

Я поняла: это email.

Структура:

• Папка на каждого пользователя: inbox, sent, archive
• Папка all/ — для рассылок
• Каждое письмо — markdown-файл с YAML frontmatter: from, to, type, subject, message_id, in_reply_to, status

Пример: сессия ani пишет Артёму:

Ты менял линковку libsodium в CMakeLists? У меня build падает на target_link_libraries.

Через час Артём открывает свой чат. Хук проверяет inbox, видит письмо, подсовывает в контекст. Он отвечает — и ответ попадает в мой inbox.

Цепочки — через in_reply_to, как в RFC 822. Подтверждения — отдельные файлы-квитанции. Рассылка: to: * → папка all/. Дедупликация — через .watcher_state.json. Никакого брокера: всё на хуках.

Каждая фича — копия классического email:

• Mailbox агентов — Inbox per user
• Адресация — From / Reply-To
• Цепочки — In-Reply-To
• Статус — Read/Unread
• Аудит — Sent folder
• Подтверждение — Delivery receipt

Email решает ту же задачу: асинхронная доставка между процессами. Claude Code — новая упаковка старой проблемы.

mclaude: всё вместе

Я собрала три слоя в open-source инструмент — mclaude. Python, без зависимостей в ядре, 193 теста, v0.6.0.

Шесть слоёв:

• Locks — атомарный захват ресурсов + heartbeat
• Handoffs — per-session сводки, append-only INDEX
• Memory Graph — иерархическое хранилище решений и gotchas
• Identity Registry — имена сессий (ani, artem, nastya)
• Messages + Active Mail — межсессионная коммуникация с threading
• Code Indexer — AST-сканер → code-map.md + llms.txt

Code Indexer — новинка v0.6.0. Сканирует проект, создаёт:

• code-map.md — карта модулей, классов, функций
• llms.txt — компактный индекс для быстрой загрузки

code-map.md читаем и человеком — формат взят из нашей базы знаний. Новая сессия не тратит время на перечитывание кода.

Ещё 5 хуков: на события Claude Code (SessionStart, PreToolUse, UserPromptSubmit, Stop) и git pre-commit guard, который блокирует коммит в заблокированный файл. MCP-сервер с 20+ инструментами отдаёт структурированный JSON — без парсинга CLI-вывода.

Принцип: hub — ускоритель, не зависимость. Всё работает на файлах. Hub поднят — сообщения через WebSocket. Упал — bridge пишет в .claude/messages/inbox/. Удалил mclaude — файлы остаются читаемыми. Markdown для нарратива, JSON для метаданных.

Чтобы увидеть паттерн за 30 секунд: pip install mclaude && mclaude demo --no-pause. Скрипт запускает две симулированные сессии (ani и vasya), проходит все слои и выводит Mermaid-диаграмму — её можно вставить в PR.

Дыра в экосистеме

Изоляция — решений много: Git worktrees, песочницы, отдельные порты, Anthropic Agent Teams. Всё это избегает общего состояния.

Координация общего состояния — почти пусто. Только claude_code_agent_farm от Dicklesworthstone делает file-based locks. Но это оркестрация 20+ агентов в tmux, а не сценарий многих чатов над одним проектом.

GitHub issue #19364 — запрос на «session lock file». Не реализован. Issue #29217 — .claude.json повреждается при параллельных записях. У одного пользователя — 315 битых бэкапов за 7 дней.

Экосистема зрелая в избегании общего состояния. Пустая в его координации.

Распределённые системы, вид сбоку

Всё это — паттерны из 1980-х:

• Heartbeat-таймауты для обнаружения мёртвых процессов
• Lock-файлы с именами по ресурсу
• Append-only журналы
• Внешняя проверка перед перехватом устаревшего замка
• Отдельный файл на ресурс — маленькое окно конфликта

Chubby, ZooKeeper, любая координационная система — всё это использует. AI-агенты — просто новый вид процессов в старой распределённой системе.

Email (RFC 822, 1982) оказался готовым решением для межагентной коммуникации. Не потому что «мы знаем email», а потому что он решает ту же абстрактную задачу: асинхронная доставка между процессами с цепочками и подтверждением.

Каждое поколение переоткрывает: email был прав. В 2010-х — это были очереди (RabbitMQ, Kafka). В 2026-м — AI-агенты.

Реальное использование

Три человека, один C++ проект, 6 параллельных сессий. Каждый работает над своей частью: архитектура, inference, UI.

Один агент решил изменить key derivation в scramble-модуле. Отправил рассылку через mailbox/all/. Другой увидел сообщение — и учёл изменение до начала кода. Без почты — был бы конфликт слияния или повреждение данных.

27 handoffs за 4 дня. 0 повторённых тупиков. Handoff между подписками сэкономил ~4 часа восстановления контекста.

Где сломается и чего не знаю

Масштаб. Тестировалось на 3–6 сессий, 2–3 человека, 1 C++ проект. Что будет при 20+ сессий от 10 агентов — неизвестно. Подозреваю, что .claude/messages/inbox/{user}/ станет узким местом: дедупликация через .watcher_state.json линейна, на сотнях писем будет медленно.

Между машинами без hub. Файловое ядро работает через общий репозиторий: закоммитил — другой увидел при git pull. Задержка — минуты, а не секунды. Hub даёт WebSocket, но требует отдельного процесса. В продакшне не испытан.

Race при взятии lock. O_CREAT | O_EXCL атомарен на локальной ФС. На сетевой (NFS, SMB) — зависит от реализации. При использовании .claude/locks/ на NFS возможна гонка.

Проверка устаревшего lock — полуавтоматическая. Перед перехватом я вручную проверяю nvidia-smi, ps, git-статус. Для полной автоматизации нужен обработчик, знающий типы ресурсов. Пока — человек решает.

Почта без push-доставки. Сейчас письма показываются на UserPromptSubmit — только когда сессия что-то пишет. Настоящая push-доставка (сессия просыпается при письме) — в планах.

Human-in-the-loop нужен. Система не заменяет координатора. Если 6 агентов решат переделать auth-middleware — они договорятся, но кто именно возьмёт задачу, решает человек. Mclaude даёт инструменты, не автономность.

Что дальше

mclaude — open source, MIT. 193 теста, Python 3.9+.

Репозиторий: github.com/AnastasiyaW/mclaude. Принципы: claude-code-config/principles/18.

Что доделываю:

• Автопробуждение сессии при новом письме. Сейчас хук срабатывает на UserPromptSubmit. Правильно — будить сессию при приходе письма. Будет в ближайшем обновлении.
• Наблюдение за перепиской команды. Дашборд, который читает .claude/messages/ и показывает ленту: кто кого спрашивает, где затыки. Мониторинг без открытия чатов.
• Трекер задач для агентской команды. Хаб, где задача ставится конкретному Claude’у коллеги. Видно состояние, можно переключить исполнителя. Почему это не Jira — отдельный разговор.

Я работаю с Claude Code параллельно на трёх подписках Pro. Плюс коллеги на своих мульти-аккаунтах, часто в тех же файлах, часто в один и тот же день.

Когда мне надоело каждый новый чат заново пересказывать Claude’у курс дел - я придумалаhandoff’ы: короткую сводку, которую сессия пишет в конце и которую следующая читает при старте.

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

Когда мне надоело смотреть, что делают Claude’ы коллег, и вручную перекладывать их статусы через мессенджер - я придумалапочту, работающую между нашими клодами.

Три шага, три слоя, и каждый повторяет паттерн из распределённых систем, которому сорок лет. Ниже - что именно и как.

Слой 1: Handoffs - “я закончил, подхватывай”

Первая попытка: писать всё в одинHANDOFF.mdпри закрытии сессии. Ломается мгновенно, как только чатов становится больше одного - последняя запись побеждает, остальные перезаписаны.

Я перешла на append-only модель: каждая сессия пишет свой файл с уникальным именем.

Имя файла кодирует дату, время, первые 8 символов session-id и slug задачи. Два чата не могут создать файл с одинаковым именем физически - даже если попадут в одну секунду, session-id разные. Гонка состояний невозможна в принципе, без блокировок, без брокера - значения не имеет.

INDEX.md тоже append-only: новая строка внизу, старые не правим. Нужно обновить статус с ACTIVE на CLOSED - дописываем новую запись, не редактируем предыдущую. Ровно так работает write-ahead log (журнал упреждающей записи) в базах данных, и по той же причине: если процесс умер посреди записи, журнал остаётся согласованным.

Handoff - это не дневник, а контракт со следующей сессией. Пять секций, каждая отвечает на один вопрос.Цель- зачем сессия вообще была.Сделано- конкретные артефакты с путями, чтобы не пересобирать.НЕ сработало- подходы которые провалились, с причинами.Текущее состояние- что работает, что сломано, что заблокировано.Следующий шаг- одно конкретное действие для продолжения.

Для примера - реальный handoff с одной из сессий по color-checker проекту, по строчке из каждой секции:

• Цель: “Color checker: CNN sweep + diffusion, первые результаты”
• Сделано: “CNN baseline median 1.99 deg, 11M params, 21 MB”
• НЕ сработало: “lr=3e-4 - NaN после epoch 10-13, нет gradient clipping”
• Сломано: “Diffusion training OOM на bs=16”
• Следующий шаг: “Inference скрипт для diffusion + visual sheets”

Самая ценная секция - “НЕ сработало”. Именно она спасает следующую сессию от часа в тупике. За четыре дня накопилось 27 handoff’ов - и ни один тупик не повторился, потому что каждая новая сессия видела предупреждение.

Handoff помещается в 1500 токенов. Сырой контекст сессии - около 100K. Компрессия примерно 67-кратная, без потерь того, что важно для продолжения.

И ещё: хуки вместо напоминаний

Писать handoff руками в конце каждой сессии неудобно. Решение - Stop-hook Claude Code. Когда сессия собирается закрыться, хук проверяет длину работы и, если сессия была содержательная, печатает в контекст: «ты ничего не записала, хочешь сохранить handoff?» На старте новой сессии я сама пишу «подхвати handoff по color-checker» или кидаю ссылку на файл - Claude читает его и продолжает с того места.

Поверх хуков работает сама модель. В длинных сессиях Claude сам предлагает «давай запишем handoff перед продолжением» - не дожидаясь ни моего запроса, ни Stop-события. Замечаю это регулярно после завершения крупной задачи или когда контекст заполнен процентов на 70-80. Программной проверки длины у меня в хуках нет - это решение самой модели.

Запись - автоматическая: хук и сама модель напоминают. Чтение - одна фраза в начале новой сессии.

Rollups - когда handoff’ов становится больше

Пока проект короткий и укладывается в несколько чатов - проблемы нет. Но когда работаешь над чем-то месяц или два, накапливаются десятки handoff’ов с пройденными тупиками и опровергнутыми гипотезами. Новая сессия прочитывает последние, глубже не заглядывает - и спокойно предлагает подход, который я уже опровергла две недели назад. Возвращается тот же цикл перепроверки гипотез, от которого я уходила с самого начала.

Решение - сворачивать старое. Один rollup-handoff суммирует двадцать предыдущих, ставит точку «свёрнуто до вот этой даты» и проставляет каждому подчинённому handoff’у строкуrolled_up_into:с именем rollup-файла. Новая сессия читает один rollup плюс только те handoff’ы, что датированы позже его границы. Остальное лежит для истории, но в контекст не затягивается.

Файлу-rollup-у в имени дают сегментrollup_, чтобы он был виден вINDEX.mdодним взглядом. Frontmatter содержитtype: rollup, списокcovers:со всеми подчинёнными файлами иthrough:с датой-границей. Больше ничего не нужно: текст rollup’а - просто обычный handoff, только описывает не одну сессию, а два десятка.

Паттерн разработан не мной. УPavelMuntyan/MF0-1984ровно то же самое решено в SQLite-схеме через колонкуcovered_until_message_id. Я скопировала идею, заменив таблицу на markdown-frontmatter. Не фокус - привычная бюрократия, «страница с кратким содержанием предыдущих глав».

Слой 2: Locks - «этот ресурс сейчас мой»

Следующий затык выяснился при работе с распределёнными тренировками на серверах. Handoff’ы тут не помогают: когда два чата хотят работать с одним и тем же ресурсом - модулем кода, виртуалкой для тестов, деплой-слотом, GPU на тренировочном сервере, - кто-то должен получить его в эксклюзивное владение. Иначе в лучшем случае конфликт слияния, в худшем - снесённый стенд или сломанная тренировка.

Handoff’ы только дописываются, каждый пишет своё - никто никого не затирает. Но реальные ресурсы изменяемы. Две сессии не могут одновременно рефакторить один модуль (получится конфликт слияния), не могут одновременно катить деплой на стейдж (вторая перезапишет первую), не могут одновременно тренировать модель на одной GPU (вторая получит OOM).

Нужны замки. Один файл на ресурс, внутри - кто взял, когда, для чего. Имя файла кодирует имя ресурса:auth-middleware.lock,staging-deploy.lock,gpu-host-a_gpu2.lock. Новая сессия видит по списку файлов, что занято, выбирает свободное - без моего вмешательства.

Фокус - в том, как файл создаётся. Python-вызовos.open(path, O_CREAT | O_EXCL)атомарный: если файл уже есть, вызов падает с ошибкой. Два процесса физически не могут создать один файл одновременно, эту гарантию даёт ядро. Это тот же примитив, на котором стоят/var/lock/на Unix и.pid-файлы процессов ещё с 80-х.

Но lock без heartbeat работает только до первого сбоя сессии. Сессия упала, lock остался, следующая сессия ждёт вечность. Поэтому активная сессия обновляет отметку времени раз в 30-60 минут. Если lock старше четырёх часов - возможно, сессия мертва. Но «возможно» - это еще не «точно». Перед тем как забрать lock, я проверяю сам ресурс: SSH на сервер сps,nvidia-smiна GPU, статус очереди деплоев, git-статус нужного модуля - что угодно, всё что он скажет: реально ли ресурс занят или просто не освободили за собой. Только после подтверждения - перехватываю. Внешняя проверка перед перехватом - тот же приём из Chubby и ZooKeeper: доверяй, но проверяй.

Рядом с lock-файлом лежит JSON с метаданными: slug задачи, session-id, время захвата, описание, список задействованных файлов. Новая сессия читает папку.claude/locks/и за секунду видит: «auth-middleware занят ani под рефакторинг, второй час», «GPU 2 занята под тренировку эмбеддингов». Вопрос «что тут происходит?» больше не встаёт.

Первым моим инстинктом было написать хук наPreToolUse, который парсит команды и автоматически обновляет таблицу занятости: «пользователь запустил команду, касающуюся ресурса X, - пометить X занятым». Увы, тупик: команды слишком разнообразные. Regex-парсер превратился бы в машину ложноположительх срабатываний. Правильный порядок оказался обратным: сначала соглашение и файлы, автоматизация - потом, и только для паттернов, которые активно повторяются.

Слой 3: Почта - “Артём, посмотри мой код”

Handoffs и rollups решают передачу контекста во времени - одна сессия закрылась, следующая подхватила. Locks решают ресурсы - один процесс работает, остальные ждут. Но осталась третья задача, которая ни там, ни тут:синхронизация между живыми сессиями.

Типичный день: я поставила Claude’у коллеги задачу рефакторить auth-middleware, перешла на свой чат писать плагин. Через час хочу проверить: где он сейчас, упёрся во что-то? Раньше это решалось так: я открываю мессенджер, пишу коллеге - коллега смотрит в свой чат - копирует мне текст. Три перекладки текста через человека. Каждый вечер. В куче проектов проектах.

Нужна адресная коммуникация между сессиями напрямую. Чтобы я написала ему: «ты ещё делаешь middleware или переключился?», он ответил из своего чата, я получила ответ в своём. Между процессами, которые могут никогда не быть онлайн одновременно. С гарантиями доставки - если не дочитал сейчас, дочитает в следующей сессии.

Я задумалась - и поняла что описываю email.

Структура сразу собралась. Папка на каждого пользователя, внутри - inbox, sent, archive. Отдельная папкаall/для broadcast-сообщений.

Каждое сообщение - отдельный markdown-файл с YAML frontmatter:from,to,type,subject,message_id,in_reply_to,status. Сам текст письма - ниже, в markdown.

Простой пример: сессия ani пишет артёмуquestionс темой “Re: cmake libsodium”, тело - “Ты менял линковку libsodium в CMakeLists? У меня build падает на target_link_libraries”. Через час Артём открывает Claude Code на своей машине, хук наUserPromptSubmitпроверяет его inbox перед первым промптом, видит непрочитанное сообщение и подсовывает его в контекст. Артём отвечает тут же, reply попадает мне в inbox.

Цепочки черезin_reply_to- как в RFC 822. Подтверждения доставки - отдельные файлы-квитанции. Рассылка: адресto: *кладёт сообщение в папкуall/, её проверяют все. Дедупликация: хук помнит в.watcher_state.json, какие письма уже показывал, одно и то же в контекст второй раз не попадёт. Ни опроса, ни брокера, ни отдельного фонового процесса - всё стоит на хуке, который срабатывает в нужный момент.

Каждая фича маппится 1:1 на классический email:

Email (RFC 822, 1982)

Mailbox агентов

Адресация конкретной сессии

From / Reply-To

Обратный адрес для ответа

Triage без чтения тела

In-Reply-To

Цепочки сообщений

Свежесть запроса

Read/Unread

Видел или ещё нет

Inbox per user

Per-recipient очередь

Sent folder

Аудит отправителя

Delivery receipt

Подтверждение без “ты видел?”

Email решает ровно ту же задачу: асинхронная доставка с гарантиями между процессами которые могут быть неактивны. Claude Code параллельные сессии - та же задача в новой упаковке.

mclaude: всё вместе

Я оформила три слоя в open-source инструмент -mclaude. Python, без зависимостей в ядре, 193 теста, v0.6.0.

Шесть слоёв (три базовых + три дополнительных):

Что делает

Строк кода

Атомарный захват ресурсов + heartbeat

Per-session сводки, append-only INDEX

Memory Graph

Иерархическое хранилище решений и gotchas

Identity Registry

Имена для сессий (ani, artem, nastya)

Messages + Active Mail

Межсессионная коммуникация с threading

Code Indexer

AST-сканер → code-map.md + llms.txt

Шестой слой - индексатор кода - появился в v0.6.0. AST-сканер пробегает проект и собирает два артефакта, оба - для агента.code-map.md- карта модулей, классов и функций.llms.txt- компактный индекс для быстрой подгрузки. То, чтоcode-map.mdчитается ещё и человеком как обычный документ, - побочный эффект: его формат взят из нашей общей базы знаний, которая изначально сделана человекочитаемой. Новая сессия не тратит первые минуты на перечитывание кода - карта уже лежит в репо, рядышком с handoff’ами.

Плюс 5 хуков - четыре на события Claude Code (SessionStart, PreToolUse, UserPromptSubmit, Stop) и git pre-commit guard, который блокирует коммит в заблокированный файл. MCP-сервер с 20+ инструментами отдаёт структурированный JSON прямо в Claude Code, без парсинга CLI-вывода.

Принцип:hub - ускоритель, не зависимость. Всё работает на файлах. Hub поднят - сообщения летают через WebSocket в реальном времени; hub упал - bridge пишет в тот же.claude/messages/inbox/в том же формате, и получатель через git pull увидит ровно то же самое. Удали mclaude package - файлы в.claude/останутся читаемыми. Markdown для нарратива, JSON для метаданных.

Чтобы увидеть паттерн глазами за 30 секунд:pip install mclaude && mclaude demo --no-pause. Скрипт прогоняет две симулированные сессии (ani и vasya) через все шесть слоёв и выдаёт Mermaid-диаграмму того, что случилось - её можно вставить в любой PR или пост.

Дыра в экосистеме

Тогда я пошла смотреть, кто ещё решает эту задачу.

Изоляция - много решений.Git worktrees (parallel-cc). Песочницы (Kmux). Отдельные порты на каждого агента с прокидыванием env. Anthropic Agent Teams через очередь задач с claim’ом. Всё решает “сессии не мешают друг другу” через то, что у них нет общего состояния.

Координация общего состояния - почти пусто.Толькоclaude_code_agent_farmу Dicklesworthstone делает file-based locks. Но это оркестрация для 20+ агентов в tmux, не сценарий многих чатов над одним проектом.

GitHub issue #19364 “Add session lock file” - открытый feature request от сообщества. Не реализован. Issue #29217 -.claude.jsonполучает повреждённое состояние при параллельных записях. У одного пользователя - 315 битых бэкапов за 7 дней.

Экосистема зрелая визбеганииобщего состояния. Пустая в егокоординации.

Распределённые системы, вид сбоку

Всё это - паттерны из 80-х. Heartbeat-таймауты для обнаружения мёртвых процессов. Lock-файлы с именами по ресурсу. Журнал, в который только дописывают. Внешняя проверка перед перехватом устаревшего замка. Отдельный файл на ресурс вместо одной общей таблицы (маленькое окно конфликта).

Chubby от Google, ZooKeeper, любая координационная система последних 40 лет использует именно это. AI-агенты - просто новый вид процессов в уже понятной распределённой системе.

И email-протокол (RFC 822, 1982) оказался готовым решением для межагентной коммуникации. Не потому что “ну, мы знаем email”. А потому что email решает ровно ту же абстрактную задачу: асинхронная доставка между процессами с ограниченным хранилищем, цепочками сообщений и подтверждением доставки.

Каждое поколение распределённых систем переоткрывает что email был прав. В 2010-х это были очереди сообщений (RabbitMQ, Kafka). В 2026-м - AI-агенты.

Реальное использование

Три человека, один C++ проект плагина, 6 параллельных сессий Claude Code. Каждый работает над своей частью: архитектура, inference pipeline, UI.

Один агент решил поменять key derivation в scramble-модуле. Отправил рассылку черезmailbox/all/. Другой агент на следующей сессии увидел сообщениедотого как начал писать код, и учёл изменение. Без mailbox - он бы написал код с несовместимым форматом. Конфликт слияния в лучшем случае, повреждение данных в худшем.

27 handoffs за 4 дня. 0 повторённых тупиков. Handoff между подписками (закончил в одной, продолжил в другой) сэкономил ~4 часа восстановления контекста.

Где сломается и чего не знаю

Масштаб.Всё тестировалось на 3-6 параллельных сессий, 2-3 людей, 1 C++ проект и бесчисленное множество сессий работы над сайтом. Что будет при 20+ сессий от 10 агентов - не проверяла. Подозреваю что.claude/messages/inbox/{user}/станет узким местом: дедупликация через.watcher_state.jsonлинейная по числу писем, на сотнях сообщений будет медленно. До этого ещё не добралась.

Между несколькими машинами без hub.Файловое ядро работает через общий репозиторий: закомиттил - другой увидел при git pull. Это добавляет задержку минутами вместо секунд. Hub поднят - секунды, WebSocket. Но hub - отдельный процесс который тоже надо поднимать и поддерживать. Пока использую локально и через общий репозиторий, hub в продакшне не испытывала.

Race при одновременном взятии одного lock.O_CREAT | O_EXCLатомарен на локальной файловой системе. На сетевой (NFS, SMB) гарантия теряется - зависит от реализации. Для моего случая (git repo + локальная ФС) проблемы нет. Кто положит.claude/locks/на NFS - может словить race.

Проверка устаревшего lock - полуавтоматическая.Перед перехватом старого lock я описала проверку черезnvidia-smi,ps, git-статус. Это ручные проверки для человека. Для полностью автоматического обнаружения нужен обработчик который знает типы ресурсов и умеет проверять каждый. Пока - человек читает метаданные lock и решает.

Почта без автоматического пробуждения.Сейчас письма показываются наUserPromptSubmit- то есть только когда активная сессия что-то пишет. Настоящая push-доставка (сессия получила письмо → сессия проснулась) пока не реализована. Описана в планах ниже.

Human-in-the-loop нужен.Система не заменяет человека-координатора полностью. Если 6 агентов одновременно решили что auth-middleware требует переделки - они договорятся через почту, но кто именно возьмёт в работу всё равно решает человек. Mclaude даёт инструменты для переговоров, не автономную оркестрацию.

Что дальше

mclaude - open source, MIT. 193 теста, Python 3.9+.

Репозиторий:github.com/AnastasiyaW/mclaude. Принципы отдельно от кода:claude-code-config/principles/18.

Чего системе сейчас не хватает и что я доделываю:

Автопробуждение сессии при новом письме.Про это уже говорила в секции про почту. Сейчас хук срабатывает наUserPromptSubmit- письма лежат в инбоксе, пока я что-то не напишу в свой чат. Правильная доставка должна будить сессию сама, в момент прихода письма. Собираю в ближайшем обновлении.

Наблюдение за перепиской команды.Небольшая программа-дашборд, которая смотрит на живой поток писем между моими Claude’ами и Claude’ами коллег: кто кого о чём спрашивает, где затыки, что уже ответили. Тот же файловый протокол, только с другой стороны - читает папку.claude/messages/и показывает ленту. Использую как мониторинг того, что происходит в разработке, без открывания каждого чата по одному.

Трекер задач для агентской команды.Небольшой хаб поверх mclaude, где задача ставится не «в Jira на человека», а «конкретному Claude’у коллеги». Видно статус, можно переключить исполнителя, закрыть по handoff’у. Почему эта система должна быть отдельной от Jira или Linear, а не надстройкой над ними, - разговор отдельный, расскажу в другой статье.

Если работаете с параллельными AI-сессиями и сталкивались с гонками за ресурсы - как решали? Worktrees + изоляция, или тоже пришли к координации через общее состояние?