Съобщения между сесии
Съобщения между собствените ти Claude Code сесии — ListAgents и SendMessage, @-споменавания, доставка между машини, inbound контроли, inbox socket-ът и как да ограничиш или изключиш всичко.
Cross-session messaging позволява на Claude да достави съобщение от една твоя Claude Code сесия до друга. Когато промяна в едната сесия чупи нещо, върху което другата гради, Claude може да я предупреди, преди ти да забележиш. Когато едната сесия реши въпрос, на който другата е закъсала, Claude праща отговора отсреща, вместо ти да копираш между терминалите.
Съобщението е парче текст, което един Claude пише на друг — никога история на разговора или файлове. За да пренесеш цял разговор, вместо това възобнови сесията с resume.
Задвижват го два tool-а: ListAgents открива кои агенти Claude може да достигне, а SendMessage
доставя съобщение до един от тях по име. Ти никога не викаш тези tools сам — просто казваш на Claude
какво трябва да знае другата сесия.
Срещу другите multi-session функции
Съобщенията са за независими сесии, които ти пускаш и управляваш сам. Claude Code има отделна функция за всеки друг начин да въртиш няколко сесии:
| Искаш | Използвай вместо това |
|---|---|
| Да продължиш един разговор в друг терминал | Resume на сесията (claude --resume) |
| Координиран екип, който Claude пуска и надзирава | Agent teams |
| Да гледаш и управляваш много сесии от едно място | Agent view |
| Да управляваш сесия от телефона или друго устройство | Remote Control |
| Да вкараш външни събития (CI резултати, чат) в сесия | Channels |
Случаите, в които съобщенията са правилният инструмент: предаване на находка или решение към сесията, работеща по засегнатата област; координиране на паралелни worktrees по едно и също repo; статус от дълга миграция или тестов run; и достигане на твоите сесии на други машини или в уеб.
Пращане на съобщение
Кажи на Claude какво искаш другата сесия да знае или да направи — Claude намира целта с ListAgents
и сам пише самото съобщение:
Ask the session running in my other terminal whether the migration finished
Explain what we just did to the session working on the payments API
Claude може и сам да реши да прати съобщение, без да го молиш — например след промяна, която засяга работата на друга сесия.
Назоваване на целта с @
Напиши @ плюс първите букви от името на сесията и я избери от typeahead-а (v2.1.232+), по същия
начин, по който @-споменаваш субагент:
Let @api-worker know the schema migration finished
Предложенията показват другите ти живи сесии на тази машина, щом напишеш поне една буква след @.
Cloud или Remote Control сесия се появява само след като Claude вече е листвал или писал на сесиите
ти отвъд тази машина. Когато няколко живи сесии отговарят на споменатото име, Claude пита коя имаш
предвид, преди да прати.
Имена на сесиите
Сесията отговаря на името, което задаваш с /rename или флага --name. Без такова Claude Code го
извежда от името на работната директория — например my-app-3f в директория my-app. Съвпадения на
имена на една машина се разрешават автоматично — сесията, която вече има името, го запазва, а твоята
получава вариант. Когато няколко сесии все пак делят име, Claude добавя кратък идентификатор.
Пусни /list-agents (също /peers), за да видиш сам какво може да достигне Claude: субагенти в
текущата сесия, другите ти локални сесии, cloud сесиите ти и Remote Control сесиите ти на други
машини (последните две — само докато тази сесия е свързана с Remote Control).
Как пътуват съобщенията
| Къде върви другата сесия | Как пътува съобщението |
|---|---|
| На тази машина | През socket на сесията, никога през сървъри на Anthropic |
| На друга твоя машина | През сървъри на Anthropic, по Remote Control връзката на онази машина |
| В Claude Code on the web | През сървъри на Anthropic, директно до cloud сесията |
Откриването на една машина работи през файлове на диска — двете сесии трябва да виждат една и съща файлова система, така че сесия в контейнер и сесия на хоста не могат да се достигнат, докато две сесии в един и същ контейнер могат.
Започването на разговор със сесия на друга машина иска v2.1.225+ и цел, която се вижда в листинга. Ако тази сесия не е свързана с Remote Control, когато праща отвъд машината, съобщението пак минава, но без адрес за отговор — приемащият Claude не може да отвърне.
Доставка и inbound контроли
Приемащият Claude чете съобщение между tool извиквания по време на активен ход — работещ tool никога не се прекъсва. Свободна сесия започва нов ход с него. Веднъж доставено, съобщението се брои към usage като промпт, който ти пишеш.
Всяко пристигащо съобщение минава през inbound контролите на приемащата сесия, с три изхода:
доставено, задържано (оставено настрана, докато го одобриш или настройка се промени) или
отказано (изхвърлено). Задай crossSessionInbound, за да избереш поведение, или го избери от
реда Messages from your other sessions в /config (v2.1.232+):
| Стойност | Поведение |
|---|---|
accept |
Всяко съобщение се доставя на Claude |
hold |
За всяко съобщение се показва известие; нищо не се доставя, докато по-късно не важи accept |
refuse |
Всяко съобщение се изхвърля без доставка |
Когато няма зададена стойност, Claude Code решава за всяко съобщение от permission режимите на двете сесии, групирани в два класа — сесии, които заобикалят permission промптите, и всички останали:
- Приемащата пита за permissions → съобщенията се доставят; задържа се само такова, чийто подател заобикаля permission промптите.
- Приемащата заобикаля permission промптите → съобщенията се задържат за твое одобрение; доставя се само такова, чийто подател също заобикаля.
Задържано съобщение отваря диалог с подателя и preview. Approve го доставя, deny или затваряне го
изхвърля, а неотговорен диалог изтича след срока dialogExpiry (по подразбиране пет минути).
Задържат се най-много 100 съобщения; над това най-старите отпадат. Когато подателят е на същата
машина, той получава известия за задържането и изхода му.
Какво не може входящо съобщение
Claude Code казва на приемащия Claude, че съобщението идва от друга сесия, не от теб, и го ограничава съответно:
| Ограничение | Значение |
|---|---|
| Не може да одобрява нищо | Съобщение никога не се брои за твое съгласие на висящ permission промпт |
| Не може да сменя конфигурация | Приемащият Claude не пипа permission настройки или CLAUDE.md, защото друга сесия е помолила |
| Командите не се изпълняват | /compact в текста пристига като чист текст и никога не се изпълнява |
| Permission промптите пак се показват | Работата, която съобщението иска, минава през собствените permission правила на приемащата сесия |
Permission границите остават per-session и в обратната посока: Claude е инструктиран никога да не моли друга сесия за действие, което е било отказано или блокирано в собствената му сесия.
Headless сесии
Дълго работещ claude -p worker връзва inbox socket като интерактивна сесия — може да получава
съобщения и се вижда в листинга, но не може да покаже диалога за одобрение. Задържано по
подразбиране съобщение изчаква същия срок dialogExpiry, после отпада и се докладва на подателя
като изтекло. За да приема worker-ът съобщения без надзор, пусни го с crossSessionInbound: "accept" в неговата --settings стойност. Bare режимът не връзва socket изобщо — такава сесия не
може да получава съобщения.
Inbox socket-ът
Всяка сесия с включени съобщения връзва inbox socket, ограничен до твоя OS потребител. Пътят се
вижда в /status на реда Peer address (с префикс uds:) или като
CLAUDE_CODE_MESSAGING_SOCKET в hooks и Bash команди. Редом с него се експортира per-session токен
като CLAUDE_CODE_MESSAGING_TOKEN.
Това е входът за hooks и скриптове: hook или Bash команда може да пише в собствената си сесия, и
проверено съобщение от собствено дете се доставя дори когато подразбирането би го задържало. Където
липсват процесни доказателства (macOS след изход на пишещия процес, контейнери, в които Claude Code
е PID 1), прати {"type":"auth","token":"<token>"} като първи ред на връзката. Отвътре на sandbox-а
достъпът до socket-а се управлява от sandbox.network.allowUnixSockets.
Ограничаване
| Цел | Как |
|---|---|
| Одобрение за всяко съобщение, напускащо машината | "isolatePeerMachines": true — пита дори в bypassPermissions режим; true от кой да е settings scope печели |
| Спиране на получаването | "crossSessionInbound": "refuse" |
| Спиране на пращането и листването | Permission deny правила с SendMessage и ListAgents (голи имена на tools) |
| Изключване за цялата организация | Двете по-горе в managed settings |
Лимити
- Само чист текст — никакви структурирани payload-и между сесии; протоколните съобщения на agent teams остават в екипа.
- Loop-овете сами се задушават — повтарящи се съобщения се rate-limit-ват per подател, еднакви повторения в кратък прозорец отпадат, а най-много 50 приети съобщения чакат да бъдат прочетени per сесия.