Обмен сообщениями между сессиями Claude Code

Что означает обмен сообщениями между сессиями Claude Code

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

Эта функция называется межсессионным обменом сообщениями (cross-session messaging). По состоянию на август 2026 года для её работы требуется Claude Code версии v2.1.224 или новее; она поддерживается в macOS и Linux, включая Linux внутри WSL 2. Нативная поддержка Windows отсутствует, также функция недоступна в Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform или Microsoft Foundry. Если сессия соответствует этим требованиям, обмен сообщениями включен по умолчанию, и дополнительная настройка не требуется. Описанное ниже поведение соответствует документации Anthropic по межсессионному обмену сообщениями.

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

Когда вторая сессия оправдывает затраты токенов

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

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

• Одна сессия обнаруживает критическое изменение, в то время как другая работает с кодом, который это изменение затронуло. Claude суммирует изменения и отправляет их, избавляя вас от необходимости перепечатывать их в другом терминале.
• Две сессии работают с одним репозиторием в разных git worktrees, и одной из них нужно знать, какие изменения были приняты.
• Длительная миграция или запуск тестов отправляют результат обратно в сессию, за которой вы наблюдаете.
• Сессия разработчика и сессия рецензента, где рецензент читает созданный разработчиком код и отправляет обратно свои замечания.

Если работа последовательна или если обе сессии должны редактировать одни и те же файлы, используйте одну сессию. Если вам нужна скоординированная группа, которую Claude создает и контролирует в рамках одной задачи, используйте агентские команды (agent teams) — это отдельная и пока экспериментальная функция. Если вы просто хотите продолжить тот же диалог в другом терминале, возобновите сессию. Обмен сообщениями между сессиями предназначен для независимых сессий, которые вы запускаете и направляете самостоятельно.

Проверьте наличие функции перед планированием работы с ней

Сначала проверьте версию:

claude --version

Сравните полученное число с 2.1.224. Затем в рамках сессии введите /list-agents, которая также откликается на /peers. Команда выводит список всех агентов, доступных из данной сессии, с именами, под которыми они зарегистрированы. Если команда не распознается, значит, в этой сессии отсутствует обмен сообщениями между сессиями, и никакой файл настроек это не исправит. Введите /status и найдите строку Peer address: в ней указан адрес входящих сообщений для текущей сессии с префиксом uds:.

Одна ловушка особенно актуальна для пользователей VPS. Обмен сообщениями между сессиями зависит от оценки флагов функций, а ряд переменных конфиденциальности отключают эту оценку, оставляя функцию в состоянии «выключено» по умолчанию. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC и DISABLE_GROWTHBOOK приводят именно к этому. Пользователи защищают новый сервер, добавляя эти переменные в ~/.bashrc, а затем удивляются, почему /list-agents отсутствует. Те же значения могут поступать из карты env в файле настроек или из управляемых настроек, поэтому сначала проверьте переменные окружения оболочки.

env | grep -E 'DO_NOT_TRACK|DISABLE_TELEMETRY|DISABLE_GROWTHBOOK|NONESSENTIAL'

Удалите значение той переменной, которая выводит результат. Для DISABLE_TELEMETRY и CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC любое непустое значение включает поведение, включая строку 0, поэтому DISABLE_TELEMETRY=0 работает не так, как кажется. Чтобы отключить функцию, нужно удалить переменную или присвоить ей пустую строку.

Присваивайте имена сессиям, иначе Claude не сможет к ним обращаться

Claude обращается к сессии по её имени. Указывайте имя при запуске сессии:

claude --name builder-api

Вы также можете задать его с помощью /rename во время работы сессии. Если имя не задано, Claude Code формирует его на основе названия текущей рабочей директории, например myapp-3f. Это удобно для одной сессии, но запутывает, когда их четыре, к тому же две сессии могут получить одинаковые имена. Вывод /list-agents показывает рабочую директорию каждой локальной сессии, что позволяет различать сессии с одинаковыми именами, а встроенный список Claude добавляет короткий идентификатор к адресу при возникновении конфликтов имён. Самостоятельное именование сессий экономит время, затрачиваемое на чтение идентификаторов.

Макет tmux с двумя сессиями для воспроизведения

Это сессия сборки и сессия проверки для одного репозитория. Проверяющий работает в отдельном git worktree, поэтому они никогда не записывают данные в один и тот же файл. git worktree add вместе с HEAD создают отсоединенный (detached) checkout, что необходимо для сессии, которая предназначена для чтения, а не для фиксации изменений.

cd ~/src/api
git worktree add ../api-review HEAD
tmux new-session -d -s agents -n builder -c ~/src/api
tmux new-window -t agents -n reviewer -c ~/src/api-review
tmux send-keys -t agents:builder 'claude --name builder-api' C-m
tmux send-keys -t agents:reviewer 'claude --name reviewer-api' C-m
tmux attach -t agents

Ctrl+b, а затем w выводит список окон по именам, чтобы вы могли выбрать нужное. В окне сборщика выполните /list-agents. Вы должны увидеть reviewer-api с рабочей директорией ~/src/api-review. Если её нет, значит сессия проверяющего еще не закончила запуск, либо возникла одна из двух проблем, описанных в следующем разделе. Затем передайте что-либо на обычном языке:

Tell reviewer-api which files I changed for the rate limiter and what to look at first.

Claude пишет сводку и отправляет её. Вы не пишете текст сообщения, и то, что отправляет Claude, может варьироваться. В окне проверяющего сообщение появляется в диалоге с именем отправителя. Если эта сессия простаивает, Claude сразу начинает новый цикл общения. Если сессия занята, сообщение ожидает завершения вызовов инструментов, поэтому выполнение команды не прерывается. Как только Claude прочитает сообщение, оно сворачивается в одну строку Message from, которую можно развернуть с помощью Ctrl+O. Эта пара работает эффективнее, когда сборщик вносит небольшие изменения, так как узкий diff позволяет сделать передачу короче, а проверку — завершаемой за один цикл, что является привычкой, которую закрепляет навык ленивого старшего разработчика.

Кто кого видит на одном VPS

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

Сокет ограничен вашим пользователем операционной системы. Сессия, запущенная вами от имени root, и сессия, запущенная от имени deploy, не могут «видеть» друг друга, даже если они запущены рядом в одном и том же tmux-сервере, так как сессии одного пользователя не имеют доступа к сокету другого. Запускайте обе сессии от одного и того же пользователя.

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

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

Почему ваше сообщение не было доставлено

Обычно причина не связана с сетью. Принимающая сессия сама определяет судьбу сообщения, и в данном случае решение было принято не в пользу доставки. Каждое входящее сообщение ожидает один из трех исходов: доставлено, удержано (отложено без доставки до вашего подтверждения) или отклонено (удалено без доставки).

Если значение crossSessionInbound не задано, Claude Code принимает решение для каждого сообщения, сравнивая режимы разрешений обеих сессий. Он объединяет сессии, которые обходят запросы разрешений, в один класс, а все остальные — в другой. auto, acceptEdits и dontAsk считаются режимами с запросами. Режим Plan считается режимом обхода, если в сессии доступны соответствующие права. Правило симметрично:

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

Поэтому первый рабочий процесс, который обычно создают пользователи, — именно тот, который не работает. Вы запускаете сборщик с --permission-mode bypassPermissions, так как хотите, чтобы он работал без присмотра, оставляете настройки рецензента по умолчанию, и каждое сообщение от сборщика попадает в диалоговое окно подтверждения, которое никто не видит. Это окно закрывается по истечении срока dialogExpiry, который по умолчанию равен 5m, и сообщение удаляется. На той же машине отправляющая сессия получает уведомление, когда сообщение удерживается, а затем последующее уведомление, когда получатель доставляет, отклоняет или аннулирует его по истечении времени. Поэтому сначала изучите экран отправителя, прежде чем винить сетевой сокет.

Чтобы сессия принимала сообщения без участия пользователя, установите crossSessionInbound в значение accept. Место установки определяет, будет ли применено это значение. Claude Code сначала считывает управляемые настройки, затем флаг --settings, затем пользовательские настройки и применяет первое найденное значение. Значение в настройках проекта или локальных настройках применяется только в том случае, если оно более строгое, согласно иерархии accept < hold < refuse. Значение accept в .claude/settings.json является наименее строгим, поэтому оно игнорируется, если значение уже задано доверенным источником. Укажите его в ~/.claude/settings.json или передайте для одной сессии:

claude --name runner --settings '{"crossSessionInbound":"accept"}'

Автономный рабочий процесс claude -p привязывает сокет входящих сообщений так же, как интерактивная сессия, и отображается в списке, но он не может показать диалоговое окно подтверждения. Удержанное сообщение остается в таком состоянии до тех пор, пока последующее изменение режима или настроек не разрешит его обработку. Строка --settings выше — это способ разрешить такому рабочему процессу принимать сообщения. Сессия, запущенная в режиме bare, не привязывает сокет вовсе, поэтому она не может ни принимать сообщения, ни отображаться в списке.

Где возникают взаимные блокировки при передаче задач

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

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

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

Обработка входящих сообщений как недоверенных данных

Claude Code сообщает принимающему экземпляру Claude, что сообщение поступило из другого сеанса, а не от вас, и ограничивает возможности этого сообщения. Сообщение не может ответить на ожидающий запрос разрешения от вашего имени, так как согласие, полученное в другом сеансе, не является вашим согласием. Оно не может изменять настройки разрешений, CLAUDE.md или другие параметры конфигурации по запросу из другого сеанса. Команда с косой чертой внутри текста, например /compact, поступает как обычный текст и никогда не выполняется. Если для выполнения действий по сообщению требуется разрешение, которого нет у принимающего сеанса, вы увидите тот же запрос, что и при любой другой работе. В автоматическом режиме классификатор также проверяет каждое сообщение перед доставкой, и заблокированное им сообщение никогда не доходит до получателя. Эти ограничения действуют даже в режимах с пониженными требованиями безопасности, поэтому сеанс, работающий в обход ограничений, по умолчанию удерживает входящие сообщения, вместо того чтобы доверять им.

Это касается разрешений, но не содержания. Отправляющий сеанс мог прочитать описание pull request, веб-страницу, README-файл зависимости или комментарий к задаче, написанный посторонним лицом, и всё прочитанное может повлиять на текст, который он пишет в ваш другой сеанс. Сообщение — это данные. Оно заслуживает такого же подозрения, как и любой другой текст, попавший в сеанс извне. Это дисциплина, описанная в защите секретов от ваших ИИ-агентов: исходите из того, что всё, что пересекло границу доверия, может быть ошибочным, и никогда не позволяйте этому авторизовать себя.

Существует два элемента управления, если вы хотите ограничить этот процесс. Установка crossSessionInbound в значение refuse отбрасывает входящие сообщения от других сеансов без их доставки; это значение, заданное в настройках проекта или локальных настройках, имеет приоритет над любыми другими источниками, так как является самым строгим в иерархии. Чтобы запретить этому сеансу отправку или отображение списка, добавьте правила запрета разрешений, указав SendMessage и ListAgents — оба записываются как имена инструментов без дополнительных спецификаторов. Установка isolatePeerMachines в значение true требует вашего явного одобрения перед тем, как любое сообщение попадет в сеанс за пределами этой машины, и это одобрение требуется даже в режиме bypassPermissions.

{
  "crossSessionInbound": "refuse",
  "isolatePeerMachines": true
}

Запрет SendMessage также отключает обмен сообщениями с субагентами, так как для обеих задач используется один и тот же инструмент. Сеанс, отклоняющий сообщения, не показывает видимых изменений в собственном /status или в списках других сеансов, поэтому проверяйте настройки в конфигурации сеанса, а не на экране.

Мосты и MCP-серверы с общей памятью

В этот же период появилось несколько сторонних проектов, решающих смежные задачи: локальные мосты между агентами, передающие текст между запущенными процессами, и MCP-серверы (model context protocol), предоставляющие нескольким агентам общее хранилище для чтения и записи. Рассматривайте их как альтернативную архитектуру, а не как конкурентов. Перед выполнением любой команды установки обязательно сверяйтесь с README соответствующего проекта. Обмен сообщениями здесь работает по принципу push: отправитель помещает текст в очередь получателя. Общее хранилище работает по принципу pull: процесс не прерывается, а видит запись при следующем обращении. Модель pull лучше подходит для статусов, которые меняются медленно, так как обновление происходит только в момент проверки.

Если вы выбрали этот путь, важнее задаться вопросами о процессах, а не о списке функций. От имени какого пользователя запускается сервер и к каким файлам на хосте у него есть доступ? В статье Запуск MCP-серверов на VPS описана соответствующая настройка. В статье Общий доступ к навыкам агентов между репозиториями рассматривается более простой случай, когда между сессиями нужно передавать инструкции, а не текущее состояние; это позволяет избавиться от большого количества лишних сообщений. Для получения общего представления начните с руководства запуск агента для программирования на VPS.

FAQ

Почему команда /list-agents не распознается в моем сеансе?

В сеансе отсутствует обмен сообщениями между сеансами. Сначала сверьте claude --version с версией 2.1.224, так как эта функция требует указанную версию или более позднюю. Затем проверьте платформу: она работает в macOS и Linux, но не в нативной Windows, и недоступна в Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform и Microsoft Foundry. Если с этим всё в порядке, проверьте оболочку на наличие DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC или DISABLE_GROWTHBOOK, так как каждый из этих параметров блокирует оценку флага функции, от которой зависит работа, и оставляет её выключенной.

Почему мое сообщение для другого сеанса не дошло?

Если /list-agents работает, значит, обмен сообщениями включен и что-то более узкое заблокировало это сообщение. Частая причина — права доступа. Сеанс, который обходит запросы разрешений, удерживает каждое входящее сообщение до вашего подтверждения, если отправитель также не использует обход, а диалоговое окно подтверждения закрывается по истечении срока dialogExpiry (по умолчанию пять минут). Проверьте сеанс-отправитель на наличие уведомления об удержании. Чтобы исправить это, установите crossSessionInbound в значение accept в файле ~/.claude/settings.json или передайте его с помощью --settings, так как accept в настройках проекта или локальных настройках игнорируется как менее строгое значение.

Может ли сеанс Claude Code в Docker отправлять сообщения сеансу на хосте?

Нет. Сеансы находят друг друга через файлы регистрации на диске и сокет входящих сообщений для каждого сеанса, а у контейнера своя файловая система, поэтому они не видят одни и те же файлы. Два сеанса внутри одного контейнера могут обмениваться сообщениями в обычном режиме. Это же правило объясняет, почему сеанс, запущенный от имени root, и сеанс, запущенный от имени вашего обычного пользователя, не могут связаться друг с другом: сокет ограничен пользователем операционной системы, который им владеет.

Безопасно ли выполнять действия по сообщению из другого сеанса Claude Code?

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

Отправляет ли обмен сообщениями между сеансами мой код в Anthropic?

Между двумя сеансами на одной машине — нет. Сообщение передается через сокет для конкретного сеанса на этой машине и не проходит через серверы Anthropic; передается только текст, написанный Claude, история переписки или файлы не отправляются. Сообщения сеансу на другой вашей машине или сеансу в веб-интерфейсе действительно проходят через серверы Anthropic по соединению Remote Control, и в этом случае Claude может только ответить на полученное сообщение, но не инициировать его. Установите isolatePeerMachines в значение true, чтобы требовать вашего подтверждения перед тем, как любые данные покинут машину.