Сессии Claude Code теперь пишут друг другу напрямую - вот что это меняет

Карты на стол. С версии 2.1.224 одна сессия Claude Code может написать сообщение другой сессии Claude Code - без меня как передаточного звена. Раньше я держал два терминала рядом и вручную копировал вывод из одного в промпт другого: «вот что сделала первая сессия, учти это». Теперь агент сам находит соседнюю сессию и сам решает, что ей сказать.

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

Что это за фича и какие два инструмента за ней стоят

Коротко: ListAgents находит, какие сессии сейчас доступны, SendMessage доставляет текст одной из них по имени. Оба инструмента дёргает сам Claude, ты их руками не вызываешь.

Работает это так: агент видит, что другой сессии пригодится какой-то факт - например, он только что сломал совместимость, а соседняя сессия строит поверх этого места код - и сам решает написать. Или ты просишь явно: «спроси у сессии в соседнем терминале, закончилась ли миграция», и Claude сам формулирует сообщение, ты содержание не диктуешь. Посмотреть, кого вообще видно, можно командой /list-agents (короткий алиас - /peers).

Сообщение - это именно кусок текста, который одна сессия написала другой. Не вся история диалога и не файлы проекта. Если нужно перенести целиком контекст разговора - для этого в Claude Code есть отдельный механизм, resume сессии, а не messaging.

Как сообщение реально доставляется

Если обе сессии на одной машине - сообщение идёт через локальный сокет, до серверов Anthropic вообще не долетает. Если сессия на другой твоей машине или в облаке (Claude Code on the web) - тогда через серверы Anthropic, по установленному Remote Control-соединению.

Принимающая сессия получает: имя отправителя, обратный адрес для ответа (если он есть) и сам текст. Контекст отправителя - файлы, история его диалога - не передаётся вообще, физически недоступен принимающей стороне.

Что через это нельзя сделать - и это специально

Самое важное в архитектуре фичи - не то, что она разрешает, а то, что она демонстративно запрещает.

Сообщение от другой сессии никогда не считается твоим согласием. Оно не может подтвердить permission-запрос за тебя, даже если один из агентов работает в режиме без подтверждений (bypass permissions), а второй - в обычном. Оно не может поменять настройки, CLAUDE.md или любой другой конфиг - Claude Code прямо инструктирует принимающую сторону не делать этого по запросу другой сессии. Команда вроде /compact, если она оказалась внутри текста сообщения, придёт как обычный текст и не выполнится - это не канал для инъекции команд. А если выполнение того, о чём просит сообщение, требует пермишена - сработает тот же запрос на подтверждение, что и для любой другой задачи.

Границы permissions остаются per-session и в другую сторону тоже: Claude прямо не должен просить у соседней сессии сделать то, что запрещено или заблокировано в его собственной сессии - вместо этого он обязан вернуться с вопросом ко мне.

Отдельная настройка - crossSessionInbound - решает, что сессия делает со входящими: принимать все (accept), придерживать до моего явного одобрения (hold) или дропать без доставки (refuse). По умолчанию логика завязана на режим permissions обеих сторон: если принимающая сессия работает в bypass-режиме, входящее сообщение придержится, пока я не подтвержу руками. Администраторы организации могут выключить обе стороны фичи целиком через managed settings - для команд, где это не нужно вовсе.

Как я это уже использую в своём цифровом офисе

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

Я держу основной оркестратор в отдельной сессии и параллельно несколько сессий-топиков в супергруппе Telegram, каждая ведёт свой участок работы. Сегодня одна из моих сессий готовила материал для блога, а параллельно другая сессия работала над дизайном того же самого репозитория. Классическая ситуация «два процесса лезут в один и тот же git-репозиторий» - раньше это заканчивалось либо конфликтом, либо мной, бегающим между терминалами с вопросом «вы там ничего не сломали друг другу?».

В этот раз сессия сама нашла соседнюю через ListAgents и списалась с ней напрямую через SendMessage, чтобы свериться по дизайн-решению для блога и не наступить на изменения друг друга в общем репозитории. Я в этом разговоре не участвовал - просто увидел результат: обе сессии двигались дальше согласованно, без моего копипаста между вкладками терминала.

Это ровно то, для чего в моей архитектуре и был нужен «общий мозг» между агентами - только раньше единственным надёжным каналом координации была моя память и файлы состояния (core/hot/, core/warm/), которые агенты читают и пишут. Cross-session messaging - это не замена этой памяти, а дополнение: быстрый синхронный канал для «сейчас и здесь», а не для того, что должно пережить рестарт сессии.

Где это реально пригождается, а где не стоит и пытаться

Передача находки - одна сессия наткнулась на breaking change или приняла решение, вторая работает в зоне, которую это затрагивает. Раньше - я пересказываю вручную, теперь агент делает это сам.

Параллельные worktree одного репозитория - сессии сообщают друг другу, что уже влито в основную ветку, до того как это всплывёт конфликтом.

Статус от долгой задачи - миграция или прогон тестов идёт в фоновой сессии, а я слежу из другой; она может сама отчитаться, когда закончит, или ответить на прямой вопрос из соседней сессии.

Не стоит пытаться превратить это в замену полноценной командной оркестрации. Для случая, когда одна сессия сама порождает и супервайзит команду других сессий под конкретную задачу, в Claude Code есть отдельный, более тяжёлый механизм - agent teams, он всё ещё экспериментальный и включается отдельным флагом. Messaging - это канал между независимыми сессиями, которые я запустил и веду сам, а не оркестрация, которую Claude строит за меня.

Ограничения, о которых стоит знать заранее

Платформенно фича доступна на macOS и Linux, включая Linux внутри WSL 2. На нативном Windows её нет вообще. Из облачных провайдеров она не работает через Amazon Bedrock, Claude Platform на AWS, Google Cloud Agent Platform и Microsoft Foundry - только через прямой доступ к Claude Code.

Через канал ходит только простой текст - ни файлы, ни структурированные протокольные сообщения agent teams туда не попадают, у той механики свой отдельный канал. И у сообщений есть встроенная защита от зацикливания: Claude Code ограничивает частоту повторов от одного отправителя, дропает дубли, пришедшие в короткое окно, и держит не больше 50 непрочитанных сообщений на сессию одновременно - если два агента вдруг начнут переписываться по кругу, система сама это остановит.

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