Обмін повідомленнями між сеансами Claude Code

Що означає обмін повідомленнями між сеансами Claude Code

Два сеанси Claude Code можуть обмінюватися повідомленнями, якщо вони працюють на одному комп’ютері під одним користувачем операційної системи. Повідомлення — це один фрагмент звичайного тексту, який один сеанс Claude пише для іншого. Воно не містить історії розмови чи файлів. Claude знаходить інший сеанс за допомогою інструмента ListAgents і передає текст через SendMessage, тому вручну викликати жоден із цих інструментів не потрібно. Ви вказуєте, що має знати інший сеанс, а Claude сам формує повідомлення.

Ця функція називається обміном повідомленнями між сеансами. Станом на August 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 із власним контекстним вікном, тому дві сесії за однаковий період коштують приблизно вдвічі дорожче, ніж одна. Повідомлення, доставлене в сесію, враховується у використанні так само, як і prompt, який ви вводите. Координація не є безкоштовною, а робота, що фактично складається з однієї послідовності кроків, після розподілу між сесіями стає повільнішою та дорожчою.

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

• Одна сесія виявляє несумісну зміну, а інша працює з кодом, який ця зміна порушила. Claude узагальнює зміну та надсилає її замість того, щоб ви повторно вводили її в іншому терміналі.
• Дві сесії працюють з одним репозиторієм в окремих git worktree, і одна з них має знати, які зміни було внесено.
• Тривала міграція або тестовий запуск передає результат у сесію, за якою ви стежите.
• Є сесія для розробки та сесія для перевірки: reviewer читає результат роботи builder і надсилає виявлені проблеми.

Якщо робота послідовна або обидві сесії мають редагувати одні й ті самі файли, використовуйте одну сесію. Якщо вам потрібна узгоджена група, яку Claude створює та контролює в межах одного завдання, це agent teams — окрема й досі експериментальна функція. Якщо потрібно лише відкрити ту саму розмову в іншому терміналі, натомість відновіть сесію. Обмін повідомленнями між сесіями призначений для незалежних сесій, які ви запускаєте та спрямовуєте самостійно.

Перевірте наявність функції, перш ніж покладатися на неї

Спочатку перевірте версію:

claude --version

Порівняйте номер із 2.1.224. Потім у сеансі введіть /list-agents. Ця команда також доступна як /peers. Вона виводить усі агенти, до яких цей сеанс може звертатися, а також ім’я, на яке відповідає кожен агент. Якщо команда взагалі не розпізнається, цей сеанс не підтримує обмін повідомленнями між сеансами. Жоден файл налаштувань цього не змінить. Введіть /status і знайдіть рядок Peer address. У ньому вказано адресу вхідної скриньки цього сеансу з префіксом uds:.

Користувачів VPS особливо часто вводить в оману одна обставина. Обмін повідомленнями між сеансами залежить від обчислення feature flags. Деякі змінні конфіденційності вимикають це обчислення, тому функція залишається вимкненою за замовчуванням. Змінні DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC і DISABLE_GROWTHBOOK роблять саме це. Під час посилення захисту нового сервера ці змінні часто додають у ~/.bashrc. Після цього користувачі дивуються, чому /list-agents не існує. Ті самі значення можуть надходити з мапи env у файлі налаштувань або з керованих налаштувань, тому спочатку перевірте shell.

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 створює від’єднану копію робочого дерева, що потрібно для сесії, яка читає код, але не створює комітів.

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 дає змогу створити коротше передавання, а рецензент може завершити перевірку в іншому сеансі за один хід. Саме цю звичку покликаний формувати навик лінивого senior-розробника.

Хто кого бачить на одному VPS

Взаємодія між сесіями на одному сервері ніколи не проходить через сервери Anthropic. Кожна сесія записує реєстраційні файли на диск і прив’язує власний сокет вхідних повідомлень, а Claude Code читає ці файли, щоб знаходити інші сесії. Це має два наслідки, і на сервері вони обидва можуть спричинити проблеми.

Доступ до сокета обмежено вашим користувачем операційної системи. Сесія, яку ви запустили від імені root, і сесія, яку ви запустили від імені deploy, не бачать одна одну навіть поруч в одному сервері tmux, оскільки сесії одного користувача не можуть звертатися до сокета іншого користувача. Запускайте обидві сесії від імені одного користувача.

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

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

Чому ваше повідомлення так і не надійшло

Зазвичай причина не пов’язана з мережею. Сесія-одержувач вирішила, що робити з повідомленням, і вирішила його не доставляти. Кожне отримане повідомлення має один із трьох результатів: доставлено, утримується (відкладено без доставки, доки ви його не схвалите) або відхилено (видалено без доставки).

Коли значення crossSessionInbound не застосовується, Claude Code визначає результат для кожного повідомлення, порівнюючи режими дозволів двох сесій. Сесії, які обходять запити дозволів, належать до одного класу, а всі інші — до іншого. auto, acceptEdits і dontAsk вважаються такими, що запитують дозволи. Режим планування вважається обходом запитів у сесії, де доступні дозволи для обходу. Отже, правило є симетричним:

• Сесія-одержувач, яка запитує дозволи, отримує кожне повідомлення. Вона утримує повідомлення лише тоді, коли сесія-відправник визначає себе як таку, що обходить запити.
• Сесія-одержувач, яка обходить запити, утримує кожне повідомлення для вашого схвалення. Вона доставляє повідомлення лише тоді, коли відправник також обходить запити.

Тому перший робочий процес, який створює більшість користувачів, не працює саме з цієї причини. Ви запускаєте builder із --permission-mode bypassPermissions, щоб він працював без нагляду, залишаєте reviewer зі стандартними налаштуваннями, і кожне повідомлення builder чекає у діалоговому вікні схвалення, за яким ніхто не стежить. Це вікно закривається після завершення терміну dialogExpiry, який за замовчуванням дорівнює 5m, і повідомлення видаляється. На тій самій машині сесія-відправник отримує сповіщення, коли її повідомлення утримується, а потім — додаткове сповіщення, коли одержувач доставляє, відхиляє або протерміновує його. Тому перш ніж звинувачувати socket, перевірте екран відправника.

Щоб сесія приймала повідомлення без нагляду, установіть crossSessionInbound у значення accept. Місце встановлення визначає область застосування. Claude Code спочатку читає керовані налаштування, потім прапорець --settings, а потім налаштування користувача та застосовує перше знайдене значення. Значення в налаштуваннях project або local застосовується лише тоді, коли воно суворіше, відповідно до шкали accept < hold < refuse. Значення accept у .claude/settings.json є менш суворим за будь-яке інше, тому його ігнорують, якщо довірене джерело вже встановило значення. Додайте його до ~/.claude/settings.json або передайте для однієї сесії:

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

Безголовий worker claude -p прив’язує inbox socket так само, як інтерактивна сесія, і відображається у списку, але не може показати діалогове вікно схвалення. Утримуване повідомлення в такій сесії залишається утримуваним, доки зміна режиму або налаштувань не дозволить його прийняти. Рядок --settings вище дає змогу такому worker приймати повідомлення. Сесія, запущена в bare mode, взагалі не прив’язує socket, тому не може ні отримувати повідомлення, ні відображатися у списку.

Де передавання завдань блокується

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

Проблема виникає інакше: непомітніше, і це не цикл, а передавання завдання. Сеанс A ставить сеансу B запитання, відповідь на яке потрібна для продовження роботи, а потім переходить у режим очікування. Сеанс B утримує повідомлення, виконує тривалу операцію або відповідає на запитання, якого сеанс A насправді не ставив. Сеанс A чекає. Через годину ви повертаєтеся до двох сеансів у режимі очікування, але роботу не виконано.

Формулюйте передавання завдань так, щоб відповідь не була потрібна. Добре повідомлення містить факт або рішення: що змінилося і яким був результат. Погане повідомлення просить інший сеанс надати дозвіл або відповідь, без якої відправник не може продовжити роботу. Claude уже отримав вказівку ніколи не просити інший сеанс виконати дію, яку блокують його власні налаштування дозволів, а натомість повертати це завдання вам. Застосовуйте це правило ширше. Якщо сеанс не може продовжити роботу без відповіді, відповісти маєте ви. Дисципліна роботи з контекстом також допомагає: сеанс, який утратив нитку, формулює нечіткі повідомлення; у матеріалі керування контекстом у Claude Code описано цей аспект.

Вважайте вхідне повідомлення ненадійними даними

Claude Code повідомляє сесію-отримувач, що повідомлення надійшло з іншої сесії, а не від вас, і обмежує дії, які це повідомлення може виконувати. Повідомлення не може від вашого імені відповісти на незавершений запит дозволу, оскільки згода іншої сесії не є вашою згодою. Воно не може змінити налаштування дозволів, CLAUDE.md або іншу конфігурацію лише тому, що цього попросила інша сесія. Slash-команда в тексті, наприклад /compact, надходить як звичайний текст і ніколи не виконується. Якщо для обробки повідомлення потрібен дозвіл, якого немає в сесії-отримувача, ви побачите такий самий запит, як і для будь-якої іншої операції. В автоматичному режимі класифікатор також перевіряє кожне повідомлення перед доставленням. Повідомлення, яке він блокує, не доходить до отримувача. Ці обмеження діють і в режимах із розширеними дозволами. Саме тому сесія, що обходить обмеження, типово утримує вхідні повідомлення, а не довіряє їм.

Це стосується дозволів, але не вмісту. Сесія-відправник могла прочитати опис pull request, вебсторінку, README залежності або коментар до issue, написаний сторонньою особою. Будь-який прочитаний текст може вплинути на повідомлення, яке вона надсилає до іншої вашої сесії. Повідомлення є даними. Ставтеся до нього з такою самою підозрою, як і до будь-якого іншого тексту, що надійшов до сесії ззовні. Саме таку дисципліну описано в не розкривайте секрети своїм AI-агентам: вважайте ненадійними всі дані, що перетнули межу довіри, і ніколи не дозволяйте їм самостійно надавати собі дозвіл.

Якщо ви хочете зменшити кількість таких повідомлень, доступні два елементи керування. Якщо встановити crossSessionInbound у значення refuse, вхідні повідомлення від колег відкидатимуться без доставлення. У project або local settings це значення має пріоритет над усіма іншими джерелами, оскільки воно є найсуворішим у цій ієрархії. Щоб заборонити цій сесії надсилати повідомлення або показувати їх у списку, додайте правила заборони дозволів із назвами SendMessage і ListAgents. Обидві назви потрібно вказати як окремі назви інструментів без specifier. Якщо встановити isolatePeerMachines у значення true, перед доставленням будь-якого повідомлення до сесії за межами цього комп’ютера буде потрібне ваше явне підтвердження. Це підтвердження потрібне навіть у режимі bypassPermissions.

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

Заборона SendMessage також вимикає обмін повідомленнями із subagents, оскільки для обох операцій використовується той самий інструмент. У сесії, яка відхиляє повідомлення, не відображаються видимі зміни у власному /status або у списках інших сесій. Тому перевіряйте це налаштування в конфігурації сесії, а не за даними на екрані.

Мости та MCP-сервери зі спільною пам’яттю

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

Якщо ви оберете цей підхід, запитання мають стосуватися процесу, а не списку функцій. Від імені якого користувача працює сервер і до яких даних на сервері він має доступ для читання. У матеріалі Запуск MCP-серверів на VPS описано це налаштування. Матеріал Спільне використання навичок агентів між репозиторіями охоплює простіший випадок, коли між сесіями потрібно передавати інструкції, а не поточний стан. Це дає змогу уникнути багатьох повідомлень, які інакше довелося б надсилати. Для загального огляду почніть із матеріалу запуск coding agent на VPS.

FAQ

Чому в моєму сеансі не розпізнається /list-agents?

У сеансі не ввімкнено обмін повідомленнями між сеансами. Спочатку перевірте claude --version на відповідність версії 2.1.224, оскільки для цієї функції потрібна саме ця або новіша версія. Потім перевірте платформу: функція працює в macOS і Linux, але не в native 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, оскільки кожен із них блокує оцінювання feature flag, від якого залежить ця функція, і залишає її вимкненою.

Чому моє повідомлення до іншого сеансу так і не надійшло?

Якщо /list-agents працює, обмін повідомленнями ввімкнено, і це повідомлення було заблоковано іншою, специфічнішою умовою. Найчастіша причина — режими дозволів. Сеанс, у якому обходяться запити на підтвердження дозволів, затримує кожне вхідне повідомлення для вашого підтвердження, якщо сеанс-відправник також не обходить ці запити. Діалог підтвердження видаляється після завершення терміну dialogExpiry, який за замовчуванням становить п’ять хвилин. Перевірте сеанс-відправник на наявність повідомлення про затримане повідомлення. Щоб виправити це, установіть crossSessionInbound у значення accept у ~/.claude/settings.json або передайте це значення через --settings, оскільки accept у налаштуваннях проєкту або локальних налаштуваннях ігнорується як менш обмежувальне значення.

Чи може сеанс Claude Code у Docker надсилати повідомлення сеансу на хості?

Ні. Сеанси знаходять один одного через реєстраційні файли на диску та socket вхідних повідомлень окремого сеансу. Контейнер має власну файлову систему, тому ці два сеанси не можуть бачити одні й ті самі файли. Два сеанси всередині одного контейнера можуть обмінюватися повідомленнями без обмежень. Це саме правило пояснює, чому сеанс, запущений від імені root, і сеанс, запущений від імені вашого звичайного користувача, не можуть зв’язатися один з одним: доступ до socket обмежено користувачем операційної системи, якому він належить.

Чи безпечно виконувати дії за повідомленням з іншого сеансу Claude Code?

Вважайте такий текст ненадійним вхідними даними, оскільки сеанс-відправник міг прочитати вебсторінку, README або коментар до issue, написаний іншою особою. Claude Code уже запобігає самостійному виконанню дій за повідомленням: він не може схвалити очікуваний запит на дозвіл, не може на вимогу змінити налаштування дозволів або CLAUDE.md, а slash command у тексті надходить як звичайний текст і ніколи не виконується. Ці засоби захисту стосуються дозволів, але не оцінки змісту, тому прочитайте отриманий текст, перш ніж доручати сеансу-одержувачу виконати дію.

Чи надсилає обмін повідомленнями між сеансами мій код до Anthropic?

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