Anthropic запускает экспериментальную функцию Cross-session messaging для Claude Code, позволяющую прямую отправку сообщений между различными сессиями. Эта функция не передает полный контекст, а только результаты задач и информацию о зависимостях, используя два внутренних инструмента: ListAgents и SendMessage. Каждая локальная сессия регистрируется на диске и привязывается к Inbox Socket; локальные сообщения передаются напрямую через Socket, а межмашинные — через сервер Anthropic. Сообщения инициируют новый Turn при бездействии сессии и читаются между вызовами инструментов в активном Turn. Получатель различает межсессионные сообщения и пользовательские сообщения; они не могут заменить пользовательское разрешение и поддерживают три режима управления входящими сообщениями: accept/hold/refuse. Функция интегрируется с существующими возможностями, такими как Resume Session, Agent Teams и Worktree, обеспечивая для Claude Code уровень координации между сессиями.

Автор статьи, источник: LeFeng.com

В последние дни Anthropic добавила Claude Code новую экспериментальную функцию: Cross-session messaging, то есть межсессионную передачу сообщений.

Проще говоря, он позволяет нескольким сеансам Claude Code, запущенным одновременно, напрямую обмениваться сообщениями друг с другом.

Например, вы открыли 3 сессии Claude Code: одну для базы данных, одну для бэкенд-API и одну для тестирования. Раньше эти 3 сессии могли работать параллельно, но не знали, на каком этапе находится каждая из них. После изменения схемы в сессии базы данных разработчику обычно приходилось переключаться в другой терминал и вручную сообщать об изменениях сессии бэкенда.

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

Чтобы понять, что именно он делает, можно проследить полный путь сообщения: что оно передает, как находит цель, когда сообщение попадает в Claude и почему получатель не может просто выполнить это напрямую.

01 Не Context, а сообщение

Cross-session messaging не изменил исходную изоляцию сессий Claude Code.

При отправке сообщения из сеанса A в сеанс B не отправляются история беседы, прочитанные файлы или весь контекстный окно. Согласно официальным правилам, при передаче между сеансами передается только текст. Если необходимо перенести полную беседу и контекст на другой терминал, следует возобновить исходный сеанс, а не использовать межсеансовую передачу сообщений.

Это определяет способ взаимодействия нескольких Claude.

Предположим, сессия базы данных для завершения миграции прочитала десятки файлов и попробовала несколько подходов, в итоге прийдя к выводу, что необходимо изменить определённое поле. Сессии бэкенда не нужно знать все предыдущие этапы анализа — ей достаточно получить финальные изменения и понять, как они повлияют на её API.

Таким образом, Cross-session messaging передает результаты задач и информацию о зависимостях, а не полную рабочую память.

Преимущество такого подхода в том, что локальная информация, генерируемая различными задачами, не будет постоянно переполнять другие сессии. Детали, связанные с базой данных, остаются в сессии базы данных, тестовые процессы — в тестовой сессии, и только когда какое-либо изменение начинает влиять на другие задачи, соответствующая информация пересекает границу сессий.

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

Поскольку передается четкое сообщение, следующий вопрос заключается в том: как Session A найдет Session B?

02 Сначала нужно найти другую сессию

Claude Code добавил собственный канал связи для сессий, поддерживающих межсессионное общение.

Каждая локальная сессия регистрирует соответствующую информацию на диске и связывает её с Inbox Socket. Claude может найти текущие доступные сессии с помощью ListAgents, а затем отправить сообщение указанному получателю с помощью SendMessage.

Пользователю не нужно самостоятельно управлять этими внутренними инструментами — достаточно сообщить Claude, с каким сеансом нужно связаться, или позволить ему автоматически уведомлять другого при возникновении зависимостей в задачах.

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

После нахождения цели сообщения на этом устройстве передаются напрямую через сокет соответствующего сеанса, без прохождения через сервер Anthropic. Сеансы на другом устройстве или на веб-интерфейсе Claude Code взаимодействуют с сервером Anthropic и соединениями, связанными с удаленным управлением.

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

Claude Code должен считывать регистрационные данные, записанные другим сеансом на диск, поэтому два Claude, даже если физически работают на одном компьютере, могут не обнаруживать друг друга, если их файловые системы изолированы. Типичный пример — хост и отдельный контейнер; если оба сеанса работают в одном и том же контейнере, они могут нормально взаимодействовать.

Inbox Socket также ограничен правами пользователя операционной системы; другие пользователи ОС на общем сервере не могут напрямую получить доступ к вашей сессии.

Таким образом, так называемая «локальная связь» на самом деле зависит от того, видна ли регистрационная информация, доступен ли сокет и разрешает ли операционная система доступ.

Сообщение теперь может быть найдено и доставлено в Inbox; теперь решение о том, когда передать это сообщение модели, принимает Runtime Claude Code.

03 После получения сообщения

Предположим, что фоновая сессия в настоящее время изменяет файл, и в этот момент тестовая сессия отправляет сообщение, сообщая о том, что была обнаружена проблема регрессии интерфейса.

Claude Code не будет немедленно прерывать выполняемый инструмент.

Если целевая сессия находится в состоянии Idle, сообщение может инициировать новый Turn; если Claude уже находится в активном Turn, сообщение будет ждать и будет прочитано между двумя вызовами инструментов.

Это связано с причиной обработки и способом выполнения Coding Agent. Claude может в данный момент записывать файл, запускать тесты, выполнять миграцию или обрабатывать другие длительные задачи. Если внешние сообщения могут в любое время принудительно изменить текущее действие, существует высокий риск того, что инструмент выполнит только часть задачи, а агент уже начнёт перепланировывать действия на основе новой информации.

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

Это также означает, что Cross-session messaging уже интегрирован в Agentic Loop Claude Code и стал асинхронным источником ввода. И этот входной канал доступен не только для других сессий Claude.

Claude Code экспонирует Messaging Socket текущей сессии для дочерних процессов, запущенных через Hook и Bash. После завершения длительной фоновой задачи можно отправить результат обратно в текущую сессию, не требуя постоянного опроса Claude о её завершении.

Сам по себе этот канал не является надежной очередью сообщений. Повторяющиеся сообщения ограничиваются по скорости, и одинаковое содержимое может быть отброшено в течение короткого промежутка времени; сообщения, уже принятые, но еще не прочитанные Claude, сохраняются в количестве не более 50 на сессию, а сообщения, перешедшие в состояние Hold, хранятся в отдельном буфере, максимум 100.

Поэтому он лучше подходит для отправки изменений состояния, результатов задач и координационных уведомлений. Факты, которые необходимо сохранять длительное время, все еще следует записывать в Git, файлы, базы данных или другие долгосрочные системы.

После попадания сообщения в среду выполнения его нельзя сразу превратить в исполняемое действие, поскольку получатель должен сначала определить: какой уровень прав имеет содержимое, отправленное другим Claude.

04 Как наследуются права

Claude Code четко различает сообщения пользователя и сообщения сеанса собеседника.

Другой сеанс не будет считаться авторизацией пользователя, поэтому не может утверждать запрос разрешения от имени пользователя или требовать через сообщение изменить настройки разрешений,CLAUDE.md или другие конфигурации. Даже если сообщение содержит команду Claude Code, оно будет обрабатываться как обычный текст.

Если сессия A запрашивает сессию B удалить файл, и для этой операции в сессии B требуется авторизация пользователя, то исходное запрос разрешения все еще появится.

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

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

Помимо прав доступа, само сообщение имеет дополнительный уровень Inbound Control. Получатель может установить для сообщений между сессиями параметры accept、hold или refuse: передать напрямую Claude, временно сохранить для дальнейшего подтверждения или сразу отбросить.

Если пользователь не настроил правила явно, Claude Code также учитывает текущий режим разрешений отправителя и получателя. Сессия, способная обойти обычный запрос разрешений, не рассматривается как источник сообщений, идентичный обычной сессии; когда права получателя выше, внешние сообщения также могут попадать в очередь ожидания.

Здесь фактически два проверки: сначала определяется, может ли сообщение попасть в Claude, затем — имеет ли Claude право выполнять действие, подготовленное на основе этого сообщения.

На этом этапе полный путь Cross-session message завершен: от создания сообщения, обнаружения получателя, доставки до чтения сообщения Runtime и прохождения через контроль доступа на стороне получателя.

Слой координации между сессиями 05

Верните эту цепочку в текущие возможности Claude Code, и позиция Cross-session messaging станет более ясной.

Resume Session используется для продолжения предыдущего разговора и контекста, Agent Teams — для создания и управления группой взаимодействующих агентов, Worktree отвечает за изоляцию изменений кода между различными сессиями, а Remote Control решает проблему продолжения управления сессией с другого устройства.

Cross-session messaging обрабатывает другой сценарий: несколько изначально независимо работающих сессий, которые после выполнения задач становятся зависимыми друг от друга, и необходимо передать необходимую информацию друг другу.

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

Cross-session messaging не объединяет несколько Claude в один агент, а добавляет уровень коммуникации за пределами существующего контекста, рабочей директории и границ прав доступа.

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

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

Cross-session messaging, хотя и решает лишь один из этапов, уже придает многосессионному подходу Claude Code более целостную инженерную структуру. Возможно, в будущем этот механизм межсессионного взаимодействия в локальной сети эволюционирует в протокол обмена сообщениями между агентами через машины и экосистемы, и сегодняшний короткий диалог между двумя экземплярами Claude станет ключевым шагом на пути к формированию высоконавязанной программной фабрики.