Към съдържанието
Claude Library
Български
Esc
↑↓navigate↵open⌘Jpreview
На тази страница

Съобщения между сесии

Съобщения между собствените ти 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 сесия.

Беше ли полезна тази страница?