Агенты Claude Code научились писать друг другу: как cross-session messaging меняет мультиагентные пайплайны

У меня в терминалах одновременно живут по три-четыре сессии Claude Code - одна чинит бэкенд, вторая ковыряется во фронте, а третья тем временем гоняет тесты и находит баги, о которых первые две ещё не знают. Раньше находки одной сессии я вручную копипастил в другую: "слушай, тут в миграции колонка переименовалась, у тебя может всё сломаться". С 7 августа 2026 года это делает сам Клод - нейросеть от Anthropic получила фичу cross-session messaging, и агенты пишут друг другу без меня как посредника. Разобрался, как это устроено, что можно доверить агентам, а что нет, и почему мой собственный конвейер статей эту штуку пока не потянет.

Что такое cross-session messaging в Claude Code

Cross-session messaging - это способность одной сессии Claude Code передать текстовое сообщение другой независимой сессии на этой же машине, на другой машине автора или в облаке, без участия человека как передаточного звена. Фича появилась в Claude Code 2.1.224 (7 августа 2026) и работает "из коробки" на macOS и Linux, включая WSL2.

Работает это на двух тулах. ListAgents находит сессии, до которых можно достучаться - субагентов внутри текущей сессии, другие локальные сессии, облачные и сессии на других машинах через Remote Control. SendMessage доставляет текст конкретному адресату по имени. Сам я эти тулы руками не вызываю - Клод решает сам, когда есть чем поделиться, либо я прошу его написать другой сессии в промпте: "скажи сессии в соседнем терминале, что миграция прогнана".

На нативном Windows фичи нет, как и на Bedrock, Vertex AI (Google Cloud's Agent Platform) и Microsoft Foundry - только на macOS, Linux и в проводных провайдерах Anthropic напрямую.

Как агенты Claude Code обмениваются сообщениями между сессиями

Сообщение - это просто текст, который одна сессия написала другой: без файлов, без истории переписки. Если нужно перенести весь контекст целиком, для этого есть resume, а не messaging. Доставка сообщения проходит через три исхода: delivered (Клод получил текст), held (Claude Code отложил его до подтверждения автора) или refused (дропнул молча).

Технически сообщения между сессиями на одной машине идут через unix-сокет процесса, минуя серверы Anthropic. Между разными машинами автора или до облачной сессии - через Remote Control и, соответственно, через серверы Anthropic. Доставленное сообщение считается как обычный промпт и списывается с лимитов подписки - это не бесплатная синхронизация, а такой же токен-расход, как если бы я сам напечатал этот текст в чат.

Получающая сессия не бросает текущую работу ради письма: если Клод в этот момент выполняет тул, сообщение подождёт паузы между вызовами тулов и придёт туда, а не прервёт что-то на середине. Если сессия в этот момент простаивает - сообщение стартует новый ход сразу.

Чтобы петля из двух сессий не зациклила сама себя бесконечной перепиской, Claude Code троттлит повторы: одинаковые сообщения в коротком окне дропаются, а очередь непрочитанных ограничена 50 штуками на сессию. Отложенных на подтверждение сообщений держится не больше 100 - дальше старые вылетают сами. В тот же релиз 2.1.224 заодно убрали лимит в 200 субагентов на сессию, так что теперь можно плодить субагентов и переписываться между параллельными сессиями почти без потолка - разве что в кошелёк это ударит раньше, чем в лимит очереди.

Может ли агент подтвердить опасное действие за другого

Нет - сообщение от другой сессии никогда не считается согласием автора, и получившая его сессия не может закрыть повисший permission-промпт от чужого имени. Это прямо зашито в правила: чужой Клод не может ни одобрить действие за тебя, ни поменять твои настройки, ни выполнить команду из текста сообщения - /compact в чужом сообщении придёт просто буквами, а не сработает как команда.

Разумно, учитывая, что несколькими месяцами раньше я разбирал кейс, где агент решил, что находится в песочнице, и залил малварь в прод по ошибке в оценке контекста. Дай агентам возможность подтверждать риск друг за друга - и один самоуверенный вывод в одной сессии открывал бы дверь во все остальные. Anthropic вместо этого развела ответственность жёстко: разрешения остаются per-сессия, а входящее сообщение обязано пройти те же permission-правила получателя, что и любой другой запрос. И если отправитель сам работает в режиме без подтверждений (bypassPermissions), а получатель просит подтверждения на каждый чих - сообщение сначала повиснёт в очереди на мой approve, а не проскочит по-тихому.

Как поделить фронтенд, бэкенд и тесты между агентами через сообщения

Штатный сценарий из документации - координация параллельных worktree: пока одна сессия работает над бэкендом в своей ветке, а другая над фронтом в своей, первая может сама сообщить второй, что API-контракт поменялся, вместо того чтобы я бегал между терминалами и пересказывал. Адресовать сессию можно явно через @ и первые буквы имени - Claude Code подскажет тайпахедом среди живых локальных сессий (с 2.1.232).

Представим сценарий: бэкенд-сессия домучила миграцию, переименовала колонку - и вместо того, чтобы я шёл пересказывать это фронту, сама пишет "у клиента теперь tenant_id вместо client_id, поправь запросы". Фронт-сессия читает это между своими тулами, правит типы и коммитит - а тестовая сессия в третьем терминале получает от обеих короткий статус, когда можно перезапускать прогон. Раньше это всё стекалось через меня, и я был узким местом ровно там, где мог бы вообще не участвовать.

На практике я такое уже гонял, просто руками: когда собирал пару QA-агентов для тестирования telegram mini-app, один агент водил реальный аккаунт по сценарию, второй проверял результат - и мне приходилось самому таскать выводы между их сессиями. Теперь тестовая сессия сможет сама написать бэкенд-сессии "у тебя 500-ка на эндпоинте оплаты" в момент, когда это случилось, а не когда я в очередной раз зайду проверить логи.

Почему мой конвейер на cron пока не может писать сам себе

Соблазн прикрутить messaging к blog-pipeline был - но не выйдет, и вот почему. Каждая стадия конвейера (генерация черновика, фактчек, публикация) - это отдельный недолгоживущий процесс claude -p, который стартует по cron, хватает свой файловый лок через flock и завершается сразу после работы:

exec 9>data/generate.lock
flock -n 9 || exit 0
...
claude -p "/blog-draft $TOPIC_ID" --permission-mode acceptEdits >"$OUT" 2>&1

На деле таких стадий у меня не три для примера, а двенадцать: генерация черновика, фактчек, правки по комментам автора, публикация, подбор обложек, SEO-подсказки, добор ключей, сбор тем в беклог, health-чек, бэкап базы, зачистка зависших чеков и напоминание об апруве. У каждой свой lock-файл и свой независимый запуск по cron - никакого общего supervisor-процесса, который бы держал их все в поле зрения, нет и не было нужно.

Headless -p сессия тоже открывает inbox-сокет и формально может принять сообщение - но не при bare mode, а моя генерация как раз запускается обычным claude -p без него, так что сокет открывается ровно на время жизни процесса. К моменту, когда соседней стадии было бы что сказать, отправлять уже некому - сессия давно завершилась и стёрла свой сокет.

Вместо живого messaging координация у меня идёт через SQLite: bpdb topic-claim захватывает тему под конкретную стадию, bpdb topic-release возвращает её в очередь при падении. Это по факту та же задача, что решает messaging - сказать "я это уже делаю" или "у меня для тебя новость" другому процессу - только через статусы в базе вместо текста в сокет. Разница между моим парком cron-обёрток и облачными Routines в чём-то похожа: там я тоже выбирал между "жить в облаке, где сессии не гаснут между запусками" и "гонять короткие процессы по расписанию" - и оба раза выбор падал на второе, потому что мне не нужна вечно живая сессия ради пары стадий в сутки.

Что настроить, прежде чем включать messaging

Дефолт зависит от режима разрешений обеих сторон, но его можно закрепить явно через crossSessionInbound в настройках: accept доставляет всё, hold держит каждое сообщение до моего approve, refuse дропает молча. Для сообщений за пределы машины есть отдельный рубильник isolatePeerMachines - с ним любое исходящее сообщение на другую машину или в облако требует моего подтверждения, даже если сессия в режиме без проверок. Таймаут диалога подтверждения (dialogExpiry) по умолчанию пять минут - после этого отложенное сообщение сгорает и отправителю приходит отказ.

Для организации то же самое настраивается на уровне managed settings: deny на тулы SendMessage и ListAgents глушит отправку и листинг сразу для всех, а crossSessionInbound: refuse - приём. Для моих личных проектов дефолтных настроек хватает: сессии без bypass-режима и так спрашивают подтверждение на каждое сообщение, а bypass-сессии придержат чужие сообщения до моего одобрения сами.

Пайплайн статей останется на cron и SQLite - там это работает и чинить нечего. А вот параллельные терминалы по kenku и sunm8.ru, где я развожу фронт, бэк и тесты руками, теперь можно оставить перекрикиваться самим. Заведу - расскажу, что из этого вышло.