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

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

• Одна сесія виявляє breaking change, поки інша будує роботу на коді, який ця зміна порушила. Claude узагальнює зміну та передає її, тому вам не потрібно повторно вводити інформацію в іншому терміналі.
• Дві сесії працюють з одним repository в окремих git worktree, і одній потрібно знати, які зміни вже додано.
• Тривала міграція або тестовий запуск надсилає результат сесії, за якою ви спостерігаєте.
• Сесія builder і сесія reviewer: 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 не існує. Ті самі значення можуть надходити з map 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 із двома сесіями, який можна відтворити

Це сесія builder і сесія reviewer для одного репозиторію. reviewer працює в окремому git worktree, тому ці дві сесії ніколи не записують в один і той самий файл. git worktree add разом із HEAD створює відокремлену копію checkout. Це потрібно для сесії, яка читає код, але не виконує commit. Оскільки ці дві сесії виконують різні завдання, для reviewer варто задати власний стиль виводу. Він змінює system prompt цієї сесії та діє протягом кожного turn, а не зникає, як інструкція, введена один раз.

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 показує список вікон за іменами, щоб можна було вибрати потрібне. У вікні builder виконайте /list-agents. Ви маєте побачити reviewer-api із робочим каталогом ~/src/api-review. Якщо його немає, сесія reviewer ще не завершила запуск або застосовується одна з двох проблем, описаних у наступному розділі. Потім передайте інформацію звичайною мовою:

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

Claude створює підсумок і надсилає його. Вам не потрібно писати текст повідомлення, і вміст повідомлення, яке надсилає Claude, може відрізнятися. У вікні reviewer повідомлення з’являється в діалозі з іменем відправника. Якщо ця сесія простоює, Claude одразу починає в ній новий turn. Якщо turn уже виконується, повідомлення очікує завершення поточного виклику інструмента, тому запущена команда ніколи не переривається. Після того як Claude прочитає повідомлення, воно згортається в однорядок Message from, який розгортає Ctrl+O. Ці дві сесії працюють краще, якщо builder вносить невеликі зміни: вузький diff дає коротший hand-off, а reviewer може завершити review за один turn. Саме цю звичку допомагає сформувати навичка lazy senior dev.

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

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

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

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

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

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

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

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

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

Тому перший workflow, який створює більшість користувачів, працює саме не так, як очікується. Ви запускаєте 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, що повідомлення надійшло з іншої сесії, а не від вас, і обмежує дії, які це повідомлення може виконати. Це забезпечення реалізоване в програмі, що обгортає модель, а не залежить від готовності моделі виконати запит. У цьому полягає практична відмінність, яку дає оболонка агента. Повідомлення не може від вашого імені відповісти на незавершений запит дозволу, оскільки згода іншої сесії не є вашою згодою. Воно не може змінити налаштування дозволів, CLAUDE.md або іншу конфігурацію лише тому, що цього попросила інша сесія. Slash-команда всередині тексту, наприклад /compact, надходить як звичайний текст і ніколи не виконується. Якщо для виконання дії з повідомлення потрібен дозвіл, якого немає в сесії-отримувачі, ви побачите той самий запит, що й для будь-якої іншої роботи. В automatic mode класифікатор також перевіряє кожне повідомлення перед доставленням, а заблоковане повідомлення не доходить до отримувача. Ці обмеження діють і в режимах із послабленими перевірками. Тому сесія, що обходить обмеження, за замовчуванням утримує вхідні повідомлення, а не довіряє їм.

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

Якщо ви хочете зменшити кількість таких повідомлень, доступні два засоби керування. Значення crossSessionInbound, встановлене в refuse, відкидає вхідні повідомлення від колег без доставлення. У project settings або local settings це значення має пріоритет над усіма іншими джерелами, оскільки є найсуворішим на відповідному рівні. Щоб заборонити цій сесії надсилати повідомлення або показувати їх у списку, додайте правила заборони дозволів для SendMessage і ListAgents. Обидва значення потрібно вказати як прості імена інструментів без specifer. Значення 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, щоб вимагати вашого схвалення перед передаванням будь-яких даних за межі комп’ютера.