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

Автор статті, джерело: Leiphone

Протягом цих днів Anthropic додала до Claude Code нову експериментальну функцію: Cross-session messaging, тобто міжсесійна обмін повідомленнями.

Просто кажучи, він дозволяє кільком сеансам Claude Code, що працюють одночасно, безпосередньо надсилати повідомлення один одному.

Наприклад, ви відкрили 3 сеанси Claude Code: один відповідає за базу даних, інший — за бекенд API, а третій — за тестування. Раніше ці 3 сеанси, хоча й могли працювати паралельно, не знали, на якому етапі перебувають інші. Після зміни схеми в сеансі бази даних розробник зазвичай мусив сам переключитися на інший термінал і вручну повідомити про зміни сеансу бекенду.

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

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

01 Не Context, а повідомлення

Повідомлення між сесіями не змінили початкову ізоляцію сесій Claude Code.

Під час відправлення повідомлення з сеансу A сеансу B не відправляються історія розмови, прочитані файли чи весь вікно контексту. За офіційними правилами, між сеансами передається лише текст. Якщо потрібно перенести повну розмову та контекст на інший пристрій, слід відновити попередній сеанс, а не використовувати повідомлення між сеансами.

Це визначає спосіб взаємодії між кількома Claude.

Припустимо, що сесія бази даних для завершення міграції прочитала десятки файлів і спробувала кілька варіантів, і нарешті вирішила, що потрібно змінити певне поле. Задній кінець сесії не має потреби знати всі попередні аналітичні процеси — йому достатньо отримати фінальні зміни та те, як вони вплинуть на його API.

Тому повідомлення між сесіями передають результати завдань та інформацію про залежності, а не повну робочу пам'ять.

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

Це інша підхід, ніж «всі агенти діляться загальним контекстом». Cross-session messaging вибирає зберігати сесії незалежними, а потім явно синхронізувати необхідний стан, коли завдання стають залежними.

Оскільки передається чітке повідомлення, наступне питання полягає в тому: як Session A знайде Session B?

02 Спочатку потрібно знайти інший сеанс

Claude Code додав власний канал зв’язку для сеансів із підтримкою повідомлень між сеансами.

Кожна локальна сесія реєструє відповідну інформацію на диску та зв’язується з Inbox Socket. Claude може знайти поточні доступні сесії за допомогою SendMessage та надіслати повідомлення вказаній цілі.

Користувачеві не потрібно самостійно керувати цими внутрішніми інструментами — достатньо повідомити Claude, який сеанс потрібно зв’язати, або дозволити йому автоматично повідомляти іншого, коли завдання залежить від іншого.

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

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

Цей механізм виявлення також визначає межі локального зв’язку.

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

Inbox Socket також обмежений правами користувача операційної системи, і інші користувачі ОС на спільному сервері не можуть безпосередньо отримати доступ до вашої сесії.

Отже, те, що тут називається «локальним зв’язком», насправді залежить від того, чи видима реєстраційна інформація, чи доступний Socket, та чи дозволяє операційна система доступ.

Повідомлення тепер може знайти ціль і надійти до Inbox, далі наступає черга Runtime Claude Code вирішити: коли передати це повідомлення моделі.

03 Після отримання повідомлення

Припустимо, що бекенд-сесія вдосконалює файл, і в цей момент тестова сесія надсилає повідомлення, що виявила проблему з регресією інтерфейсу.

Claude Code не зупинить інструмент, який вже виконується.

Якщо цільова сесія перебуває у стані Idle, повідомлення може спровокувати новий Turn; якщо Claude вже перебуває у активному Turn, повідомлення буде очікувати і прочитане між двома Tool Call.

Це пов’язано зі способом виконання Coding Agent. Claude може зараз записувати файл, запускати тести, виконувати міграцію або вирішувати інші тривалі завдання. Якщо зовнішні повідомлення можуть у будь-який момент примусово змінити поточну дію, легко виникне ситуація, коли інструмент виконає лише частину завдання, а Agent вже почне переплановувати дії згідно з новою інформацією.

Отже, це повідомлення впливає на майбутні рішення Claude, але не перериває поточні операції.

Це також означає, що Cross-session messaging було інтегровано в Agentic Loop Claude Code як асинхронне джерело вводу. І цей вхід не обмежений лише іншими сесіями Claude.

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

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

Тому він краще підходить для надсилання змін стану, результатів завдань та спільних сповіщень. Факти, які повинні зберігатися довготривало, все ще слід реєструвати в Git, файлах, базах даних або інших стійких системах.

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

04 Як наслідується доступ

Claude Code чітко розрізняє повідомлення користувача та повідомлення сесії з колегою.

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

Якщо сесія A запитує сесію B видалити файл, і ця операція в сесії B вимагає авторизації користувача, то звичайне запитання дозволу все ще з’явиться.

Claude Code також обмежує інший спосіб обходу дозволів: якщо якась операція вже була відхилена Permission System у поточному сеансі, Claude не повинен запитувати інший сеанс, щоб виконати її замість себе.

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

Крім прав доступу, саме повідомлення має додатковий рівень Inbound Control. Отримувач може встановити для міжсесійних повідомлень значення accept,hold або refuse: безпосередньо передати Claude, тимчасово зберегти для подальшого підтвердження або відкинути.

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

Тут фактично дві перевірки: спочатку вирішується, чи може повідомлення потрапити до Claude, а потім — чи має Claude дозвіл на виконання дії, яку вона підготувала на основі цього повідомлення.

На цьому етапі повний шлях повідомлення Cross-session уже завершено: від генерації повідомлення, виявлення цілі, доставки до читання повідомлення Runtime та подальшого проходження через контроль доступу отримувача.

Шар координації між сесіями 05

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

Продовжити сесію використовується для продовження попередньої розмови та контексту, Команди агентів — для створення та управління групою співпрацюючих агентів, Worktree — для ізоляції змін коду різних сесій, а Віддалений контроль — для вирішення проблеми продовження керування сесією з інших пристроїв.

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

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

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

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

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

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