Komunikacja między sesjami w Claude Code

Od wersji v2.1.224 każda interaktywna sesja Claude Code na Macu lub maszynie z Linuksem tworzy w chwili uruchomienia gniazdo Unix (u mnie jest to /tmp/cc-socks/38590.sock, z uprawnieniami wyłącznie dla właściciela), a dowolna inna uruchomiona sesja może wrzucić do niego wiadomość tekstową.¹ Funkcję obsługują dwa narzędzia: ListAgents wykrywa, które sesje są osiągalne, a SendMessage dostarcza wiadomość do wybranej z nich po nazwie.² Nic nie trzeba włączać ani konfigurować. Jeśli obie sesje działają w wersji v2.1.224 lub nowszej na tej samej maszynie, mogą już ze sobą rozmawiać.

W skrócie

Sesje Claude Code mogą teraz wymieniać wiadomości: na jednej maszynie przez lokalne gniazda, które nigdy nie trafiają na serwery Anthropic, a między maszynami — poprzez Remote Control, początkowo wyłącznie w trybie odpowiedzi, przy czym v2.1.225 dodaje możliwość rozpoczynania takich rozmów po nazwie.¹⁵ Wiadomość to wyłącznie zwykły tekst — nigdy historia rozmowy, pliki czy uprawnienia — a sesja odbierająca traktuje ją jako dane wejściowe, nie jako źródło władzy: wiadomość nie zatwierdzi zapytania o uprawnienia, nie zmieni konfiguracji ani nie wykona polecenia.¹ Funkcja zamienia flotę niezależnych terminali w coś bliższego zespołowi, a najlepiej sprawdza się w komunikatach koordynacyjnych, które wcześniej przenosiło się ręcznie: „migracja zakończona”, „zmieniłem nazwę tej kolumny”, „można bezpiecznie zrobić rebase na main”. Najgroźniejszą pułapką jest ciche zniknięcie funkcji: są cztery niepowiązane ze sobą zmienne środowiskowe dotyczące prywatności, z których każda potrafi ją po cichu wyłączyć.³

Co trafiło do wydania

Wersja v2.1.224 wprowadziła międzysesyjne SendMessage wraz z wykrywaniem przez ListAgents na macOS i Linuksie; v2.1.225 rozszerzyła to tak, by sesja mogła również rozpocząć rozmowę z sesjami Remote Control na innych maszynach — wcześniej mogła jedynie odpowiadać.⁴⁵

Maszynerię widać w trzech miejscach:

• /list-agents (alias /peers) wypisuje każdą sesję osiągalną dla Claude: subagentów wewnątrz bieżącej sesji, pozostałe sesje lokalne wraz z tymi działającymi w tle, a przy aktywnym Remote Control także sesje na innych maszynach oraz w Claude Code w przeglądarce.¹
• /status pokazuje wiersz Peer address z gniazdem skrzynki odbiorczej samej sesji, poprzedzonym prefiksem uds:.¹
• CLAUDE_CODE_MESSAGING_SOCKET jest eksportowana do każdego punktu zaczepienia i każdego polecenia Bash i zawiera ścieżkę własnego gniazda sesji.⁶ Dlaczego to istotne, wyjaśniam niżej.

Weryfikacja na mojej maszynie: sesja w wersji v2.1.226 wypisuje dwie sesje partnerskie wraz z ich stanem („busy”) i wiekiem, a plik gniazda ma uprawnienia srw-------, czyli do odczytu i zapisu wyłącznie dla mojego użytkownika — i to jest granica na maszynach współdzielonych.¹

Sesje adresuje się po nazwach. Nazwę nadaje się poleceniem /rename lub flagą --name; w przeciwnym razie Claude Code wyprowadza ją z katalogu roboczego, na przykład myapp-3f.¹ Gdy nazwy dwóch sesji się pokrywają, lista rozróżnia je katalogiem roboczym i krótkim identyfikatorem.¹

Najciekawszy jest model zaufania

Projekt Anthropic odpowiada na pytanie, z którym większość systemów wieloagentowych sobie nie radzi: ile warta jest wiadomość od innego agenta? Odpowiedź jest tu precyzyjna: wiadomość to informacja, nigdy władza.¹

Gdy sesja A wysyła wiadomość do sesji B, to, co dociera, podlega czterem regułom:¹

1. Nie może niczego zatwierdzić. Oczekujące w B zapytanie o uprawnienia ignoruje wszystko, co powie A. Na zapytania odpowiada wyłącznie człowiek.
2. Nie może zmienić konfiguracji. Odbierający Claude ma wprost zakazane modyfikowanie ustawień uprawnień, pliku CLAUDE.md czy jakiejkolwiek konfiguracji dlatego, że poprosiła o to inna sesja.
3. Polecenia docierają jako tekst. /compact w treści wiadomości to osiem znaków prozy, nigdy wykonane polecenie.
4. Zapytania o uprawnienia nadal się pojawiają. Jeśli działanie na podstawie wiadomości wymaga uprawnienia, którego B nie ma, pojawi się dokładnie to samo zapytanie co przy każdej innej pracy.

Przychodzące wiadomości mają własną bramkę. Każda z nich kończy się jednym z trzech wyników — dostarczeniem, wstrzymaniem do zatwierdzenia albo odrzuceniem — sterowanym ustawieniem crossSessionInbound (accept, hold, refuse).¹ Gdy nie ustawi się nic, Claude Code decyduje osobno dla każdej wiadomości na podstawie trybów uprawnień obu sesji, a domyślna logika jest elegancka: sesje pomijające zapytania o uprawnienia tworzą jedną klasę, cała reszta — drugą. Sesja pytająca o uprawnienia odbiera wiadomości swobodnie, ale wstrzymuje wszystko, co przychodzi od sesji pomijającej; sesja pomijająca wstrzymuje wszystko poza wiadomościami od sobie podobnych.¹ Ta asymetria jest zamierzona: wiadomość nie może przejąć uprawnień sesji o luźnych zasadach — regułę tę v2.1.224 stosuje do ruchu przychodzącego, po tym jak v2.1.222 zastosowała ją do wychodzącego w trybie auto, gdzie klasyfikator uprawnień sprawdza każdą wiadomość przed wysłaniem.⁷

Wstrzymane wiadomości otwierają okno zatwierdzenia z nadawcą i podglądem treści; okna bez odpowiedzi wygasają po pięciu minutach (czas regulowany ustawieniem dialogExpiry), a wiadomość przepada.¹ Jednocześnie wstrzymanych może być najwyżej 100 wiadomości.¹ Dwa kolejne ustawienia zawężają pole jeszcze bardziej: isolatePeerMachines: true wymaga wyraźnego zatwierdzenia, zanim jakakolwiek wiadomość opuści maszynę — nawet w trybie bypassPermissions — a wartość true z dowolnego zakresu ustawień jest rozstrzygająca, więc plik projektowy w repozytorium może tę regułę zaostrzyć, ale nigdy poluzować.¹ Organizacje mogą wyłączyć funkcję całkowicie regułami deny na SendMessage i ListAgents w połączeniu z crossSessionInbound: "refuse" w ustawieniach zarządzanych.¹

Jak podróżują wiadomości

To, gdzie działa druga sesja, przesądza zarówno o kanale transportu, jak i o tym, co można wysłać:¹

Jedna rozbieżność w dokumentacji warta odnotowania: w chwili pisania tego tekstu strona Anthropic o komunikacji między sesjami wciąż opisuje całą komunikację międzymaszynową jako ograniczoną do odpowiedzi, podczas gdy informacje o wydaniu v2.1.225 mówią, że SendMessage „może teraz rozpocząć rozmowę z sesjami Remote Control na innych maszynach po nazwie”. Informacje o wydaniu są nowsze; strona dokumentacji nie nadąża za wydaniem.¹⁵

Regułą „tej samej maszyny” jest widoczność systemu plików: sesje rejestrują się w plikach na dysku, więc dwie sesje docierają do siebie tylko wtedy, gdy widzą te same pliki. Sesja w kontenerze i sesja na hoście nie porozmawiają; dwie sesje w tym samym kontenerze — owszem.¹

Dostarczanie respektuje rytm sesji odbierającej: podczas trwającej tury wiadomość jest czytana między wywołaniami narzędzi, nigdy nie przerywając działającego narzędzia, a gdy sesja jest bezczynna, wiadomość rozpoczyna nową turę.¹ Dostarczone wiadomości liczą się do zużycia tak samo jak tekst wpisany ręcznie przez użytkownika.¹

Pięć wzorców wartych zbudowania

1. Koordynacja między worktree’ami. Przypadek oczywisty i zilustrowany przykładową wiadomością wprost z dokumentacji: sesje pracujące nad tym samym repozytorium w osobnych worktree’ach informują się nawzajem o tym, co zostało wprowadzone.¹ „Migracja schematu zakończona: nowa kolumna to tenant_id, rebase na main jest teraz bezpieczny.” — to przykład z samej dokumentacji, czyli klasa aktualizacji, która w innym wypadku wymaga, żeby to człowiek zauważył, przełączył terminal i przepisał treść ręcznie. Jeśli kilka sesji dzieli jeden checkout zamiast worktree’ów, wiadomość koordynacyjna zyskuje na wartości jeszcze bardziej: „Zaraz commituję content/guides/, nie dodawaj tego do stage’a” zapobiega klasycznej kolizji na wspólnym drzewie, gdy jedna sesja commituje niedokończoną pracę drugiej.

2. Obserwator i wykonawca. Można prowadzić sesję monitorującą wdrożenie, zestaw testów albo log i kazać jej wysłać wiadomość do sesji odpowiedzialnej za naprawy w chwili, gdy coś się psuje. Sesja odbierająca dostaje ustalenie jako kontekst, nie jako polecenie; nadal sama decyduje — w granicach własnych uprawnień — co z tym zrobić. W połączeniu z sesjami działającymi w tle i punktami zaczepienia dla powiadomień powstaje ścieżka eskalacji, która kończy się na człowieku tylko wtedy, gdy naprawdę powinna.

3. Długi proces, który się melduje. Wystarczy uruchomić migrację albo długi przebieg testów w jednej sesji, a potem kazać jej raportować do tej sesji, którą faktycznie się obserwuje.¹ Status przestaje żyć w terminalu, o którym się zapomniało. Działa to również w drugą stronę — można zapytać od strony obserwującej: „Zapytaj sesję w moim drugim terminalu, czy migracja się zakończyła” — tyle wystarczy wpisać, a Claude sam zajmuje się wykrywaniem, adresowaniem i sformułowaniem treści.¹

4. Floty wykonawców bez nadzoru. Sesje headless claude -p również tworzą gniazda skrzynki odbiorczej, więc długo działający wykonawca -p może odbierać wiadomości i pojawia się na listach.⁸ Haczyk: sesja -p nie jest w stanie wyświetlić okna zatwierdzenia, więc wstrzymana wiadomość pozostaje wstrzymana i nie ma drogi do dostarczenia bez zmiany ustawień lub trybu (v2.1.225 naprawiła przy okazji parkowanie takich wiadomości bez powiadomienia i bez wygasania). Żeby uruchomić wykonawcę odbierającego wiadomości bez nadzoru, należy wystartować go z crossSessionInbound: "accept" w jego wartości --settings — to zgoda przyznana pojedynczemu wykonawcy, a nie accept w ustawieniach użytkownika, które objęłoby każdą uruchamianą sesję.⁸ Sesje w trybie bare pomijają gniazdo całkowicie i pozostają nieosiągalne.⁸

5. Skryptowe skrzynki odbiorcze. Cicha potęga: ponieważ CLAUDE_CODE_MESSAGING_SOCKET jest eksportowana do punktów zaczepienia i poleceń Bash, skrypt może wysłać wiadomość do skrzynki własnej sesji.⁶ Claude Code weryfikuje wiadomości od procesów potomnych: wiadomość z punktu zaczepienia lub z polecenia, odesłana do własnej sesji, dociera bez dodatkowych formalności, o ile nie obowiązuje jawne crossSessionInbound.¹ Nocne zadanie, punkt zaczepienia w gicie, skrypt opakowujący w CI — wszystko, co potrafi zapisać do gniazda Unix, może teraz wstrzyknąć linijkę kontekstu do sesji, która je powołała. Na Linuksie weryfikacja działa nawet po zakończeniu procesu wysyłającego; na macOS wyłącznie dopóki proces żyje; w kontenerze, gdzie Claude Code jest procesem PID 1, weryfikacja zawodzi i wiadomość wraca do zwykłych reguł ruchu przychodzącego.¹ Polecenia w sandboksie wymagają dopuszczenia gniazda przez sandbox.network.allowUnixSockets.¹

Czym ta funkcja świadomie nie jest

Ograniczenia są decyzjami projektowymi, a ich uszanowanie chroni przed zbudowaniem czegoś niewłaściwego.

To nie kanał zatwierdzeń. Cały model zaufania istnieje po to, by jedna sesja nie mogła autoryzować działań drugiej. Każdy przepływ pracy o kształcie „sesja A zatwierdza, sesja B wykonuje” jest wprost wykluczony założeniami projektu. Władza zawsze przechodzi przez człowieka.¹

To nie przenoszenie kontekstu. Wiadomość to tekst, który jeden Claude pisze do drugiego, nigdy historia rozmowy ani pliki. Dokumentacja Anthropic mówi to wprost: żeby przenieść rozmowę, należy zamiast tego wznowić sesję.¹ Trzeba streszczać, nie zrzucać wszystkiego.

To nie zespoły agentów. Niezależne sesje wymieniające wiadomości to przypadek peer-to-peer. Skoordynowany zespół, który Claude powołuje i nadzoruje (ustrukturyzowane wiadomości protokołu, lista członków, wspólny stan zadań), to funkcja zespołów agentów, a ustrukturyzowane wiadomości zespołowe celowo nie wychodzą poza zespół.¹ Jeśli ktoś przyłapie się na projektowaniu protokołu wiadomości nadbudowanego nad tekstem między sesjami, w rzeczywistości potrzebuje zespołów agentów.

To nie pętla czatu. Claude Code ogranicza tempo powtarzanych wiadomości od jednego nadawcy, odrzuca identyczne powtórzenia przychodzące w krótkim oknie czasu i ogranicza liczbę nieprzeczytanych przyjętych wiadomości do 50 na sesję, więc pętla wiadomości między dwiema sesjami z założenia sama wygasa.¹ Warto budować wymiany typu żądanie–odpowiedź, nie rozmowy.

Pułapki

Zmienne prywatności wyłączają funkcję po cichu. Komunikacja między sesjami zależy od ewaluacji flag funkcji, a każda ze zmiennych CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK czy DISABLE_GROWTHBOOK potrafi tę ewaluację wyłączyć, pociągając za sobą — bez słowa ostrzeżenia — całą komunikację.³ Narzędziem diagnostycznym jest /list-agents: jeśli polecenie nie jest w ogóle rozpoznawane, sesja nie ma tej funkcji wcale; jeśli działa, ale wysyłka nigdy nie dociera, w grę wchodzi coś węższego — reguła deny, ustawienia ruchu przychodzącego po stronie odbiorcy albo odbiorca na innej maszynie, który przyjmuje wyłącznie odpowiedzi.¹

Luki w platformach i dostawcach. Brak natywnej obsługi Windows (działa Linux wewnątrz WSL 2). Funkcja niedostępna na Amazon Bedrock, Claude Platform na AWS, Agent Platform w Google Cloud oraz w Microsoft Foundry.¹

Jednokierunkowa odpowiedź. Odpowiedź do sesji na innej maszynie, wysłana wtedy, gdy sesja odpowiadająca nie jest połączona z Remote Control, i tak dociera, ale bez adresu zwrotnego — więc odbiorca nie może odpisać. Claude dostaje o tym informację w momencie wysyłki, a poprawki z v2.1.225 uszczelniły adresowanie tak, by potwierdzony odbiorca na innej maszynie nigdy nie został po cichu podmieniony na lokalną sesję o tej samej nazwie.⁵

Wstrzymania w trybie headless. Wykonawca -p, który w tajemniczy sposób ignoruje wiadomości, to niemal zawsze problem wstrzymanej wiadomości: brak okna, brak dostarczenia. Wykonawcom, którzy mają nasłuchiwać, trzeba ustawić crossSessionInbound: "accept".⁸

Najważniejsze wnioski

Dla codziennych użytkowników Claude Code: - Warto raz uruchomić /list-agents, żeby zobaczyć, do czego sesje już teraz sięgają; ważnym sesjom najlepiej nadać nazwy poleceniem /rename, żeby adresowanie wiadomości było czytelne. - Wiadomości można zamawiać zwykłym językiem („powiedz sesji pracującej nad płatnościami, co zmieniliśmy”) i pozwolić, by Claude sam napisał treść.¹

Dla twórców automatyzacji: - Warto wysyłać wiadomości do sesji z punktów zaczepienia i skryptów przez CLAUDE_CODE_MESSAGING_SOCKET; wiadomości od procesów potomnych docierają na Linuksie bez tarcia związanego z zatwierdzaniem.¹⁶ - Wykonawcom -p działającym bez nadzoru należy nadać crossSessionInbound: "accept" w ich własnym --settings, a nie globalnie.⁸

Dla zespołów i audytorów bezpieczeństwa: - Funkcja ma właściwe wartości domyślne: wiadomości nie niosą żadnej władzy, sesje pomijające uprawnienia są domyślnie poddawane kwarantannie, a isolatePeerMachines oraz reguły deny w ustawieniach zarządzanych dają wyłączniki na poziomie maszyny i całej organizacji.¹ - Zanim uzna się komunikację za zepsutą, trzeba sprawdzić cztery zmienne środowiskowe prywatności — a także pamiętać, że sesja odrzucająca wiadomości nie wygląda dla swoich partnerów inaczej niż każda inna.¹

Źródła