Komunikacja między sesjami Claude Code: jak to działa

Co oznacza komunikacja między sesjami Claude Code

Dwie sesje Claude Code mogą przesyłać sobie wiadomości, gdy działają na tej samej maszynie, w ramach tego samego użytkownika systemu operacyjnego. Wiadomość to pojedynczy fragment zwykłego tekstu, który jeden proces Claude zapisuje dla drugiego. Nie zawiera on historii konwersacji ani plików. Claude odnajduje drugą sesję za pomocą narzędzia ListAgents i dostarcza tekst przy użyciu SendMessage, więc nigdy nie wywołujesz żadnego z tych narzędzi ręcznie. Wystarczy określić, co druga sesja powinna wiedzieć, a Claude samodzielnie sformułuje wiadomość.

Funkcja ta nazywa się komunikacją między sesjami (cross-session messaging). Według stanu na sierpień 2026 r. wymaga ona Claude Code w wersji v2.1.224 lub nowszej i działa w systemach macOS oraz Linux, w tym w środowisku Linux wewnątrz WSL 2. Brak jest natywnej obsługi systemu Windows; funkcja nie jest również dostępna w Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform ani Microsoft Foundry. Gdy sesja spełnia te wymagania, komunikacja jest domyślnie włączona i nie wymaga dodatkowej konfiguracji. Opisane poniżej zachowanie wynika z dokumentacji Anthropic dotyczącej komunikacji między sesjami.

Ma to znaczenie w przypadku VPS, ponieważ to tam sesje działają wystarczająco długo, aby warto było je adresować. Na laptopie zamykasz pokrywę. Na serwerze z uruchomionym tmux, sesja rozpoczęta w poniedziałek nadal działa w czwartek, utrzymując kontekst danego repozytorium. Gdy masz dwie takie sesje, sposób ich komunikacji przestaje być kwestią teoretyczną. Jeśli jeszcze tego nie skonfigurowałeś, zacznij od uruchamiania Claude Code na VPS wewnątrz tmux, co obejmuje kwestie infrastruktury sesji, na których opiera się ten przewodnik.

Kiedy druga sesja jest warta zużytych tokenów

Zacznij od kosztów. Każda sesja to osobna instancja Claude z własnym oknem kontekstowym, więc dwie sesje kosztują w przybliżeniu dwa razy więcej niż jedna w tym samym czasie. Dostarczona wiadomość wlicza się do zużycia dokładnie tak samo, jak wpisany prompt. Koordynacja nie jest darmowa, a praca, która w rzeczywistości stanowi jeden ciąg kroków, staje się wolniejsza i droższa przy podziale na wiele sesji.

Przypadki, w których druga sesja zwraca się, mają wspólną cechę. Dwa zadania są wykonywane jednocześnie bez wzajemnego oczekiwania, a jedno z nich uzyskuje informacje niezbędne dla drugiego w trakcie pracy.

• Jedna sesja wykrywa zmianę powodującą błędy (breaking change), podczas gdy druga pracuje nad kodem, który został przez nią naruszony. Claude podsumowuje zmianę i przesyła ją, zamiast ręcznego przepisywania jej w drugim terminalu.
• Dwie sesje pracują nad tym samym repozytorium w oddzielnych git worktrees, a jedna z nich musi wiedzieć, co zostało wdrożone.
• Długa migracja lub test zgłasza wynik do sesji, którą aktualnie obserwujesz.
• Sesja budująca i sesja recenzująca, w której recenzent czyta to, co wyprodukował budujący, i odsyła swoje uwagi.

Jeśli praca jest sekwencyjna lub gdy obie sesje miałyby edytować te same pliki, użyj jednej sesji. Jeśli potrzebujesz skoordynowanej grupy, którą Claude tworzy i nadzoruje w ramach jednego zadania, skorzystaj z agent teams – jest to osobna i wciąż eksperymentalna funkcja. Jeśli chcesz jedynie kontynuować tę samą rozmowę w innym terminalu, wznów sesję. Przesyłanie wiadomości między sesjami służy niezależnym sesjom, które uruchamiasz i którymi sterujesz samodzielnie.

Sprawdź dostępność funkcji przed planowaniem jej wykorzystania

Najpierw sprawdź wersję:

claude --version

Porównaj numer z 2.1.224. Następnie, wewnątrz sesji, wpisz /list-agents, na co odpowiada również /peers. Polecenie to wyświetla każdego agenta, z którym sesja może się połączyć, wraz z nazwą, pod którą każdy z nich występuje. Jeśli polecenie nie jest w ogóle rozpoznawane, oznacza to, że sesja nie obsługuje komunikacji między sesjami i żaden plik ustawień tego nie zmieni. Wpisz /status i poszukaj wiersza Peer address: zawiera on adres skrzynki odbiorczej bieżącej sesji, poprzedzony prefiksem uds:.

Jedna pułapka dotyczy szczególnie użytkowników VPS. Komunikacja między sesjami zależy od oceny flagi funkcji, a kilka zmiennych prywatności wyłącza tę ocenę, co pozostawia funkcję w domyślnym stanie wyłączonym. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC oraz DISABLE_GROWTHBOOK powodują taki efekt. Użytkownicy zabezpieczają świeży serwer, wklejając te zmienne do ~/.bashrc, a następnie zastanawiają się, dlaczego /list-agents nie istnieje. Te same wartości mogą pochodzić z mapy env w pliku ustawień lub z ustawień zarządzanych, dlatego najpierw sprawdź powłokę.

env | grep -E 'DO_NOT_TRACK|DISABLE_TELEMETRY|DISABLE_GROWTHBOOK|NONESSENTIAL'

Usuń ustawienie tej zmiennej, która zwraca wartość. W przypadku DISABLE_TELEMETRY oraz CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC każda niepusta wartość włącza to zachowanie, w tym ciąg znaków 0, więc DISABLE_TELEMETRY=0 nie działa zgodnie z oczekiwaniami. Funkcję wyłącza się poprzez usunięcie zmiennej lub ustawienie jej na pusty ciąg znaków.

Nadawanie nazw sesjom jest niezbędne do poprawnej komunikacji z Claude

Claude adresuje wiadomość do sesji za pomocą jej nazwy. Nazwę należy ustawić w momencie rozpoczynania sesji:

claude --name builder-api

Można ją również ustawić za pomocą /rename w trakcie trwania sesji. Jeśli nazwa nie zostanie zdefiniowana, Claude Code wywiedzie ją z nazwy katalogu roboczego, na przykład myapp-3f. Jest to akceptowalne w przypadku jednej sesji, lecz wprowadza zamieszanie przy czterech, a dwie sesje mogą otrzymać tę samą nazwę. Dane wyjściowe /list-agents wskazują katalog roboczy każdej lokalnej sesji, co pozwala odróżnić sesje o tych samych nazwach, a lista generowana przez Claude dodaje krótki identyfikator do adresu w przypadku kolizji nazw. Samodzielne nazywanie sesji jest bardziej efektywne niż analizowanie identyfikatorów.

Układ tmux z dwiema sesjami, który można odtworzyć

Jest to sesja budowania oraz sesja recenzowania w ramach jednego repozytorium. Recenzent pracuje w oddzielnym drzewie roboczym git, dzięki czemu obie sesje nigdy nie zapisują tego samego pliku. git worktree add wraz z HEAD tworzy odłączony checkout, co jest pożądane w przypadku sesji służącej do odczytu, a nie do zatwierdzania zmian. Ponieważ obie sesje wykonują inne zadania, warto nadać recenzentowi własny styl wyjściowy, który zmienia systemowy prompt tej sesji i utrzymuje się przez całą konwersację, zamiast zanikać jak instrukcja wpisana jednorazowo.

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, a następnie w wyświetla listę okien według nazw, co pozwala na wybór jednego z nich. W oknie budowania uruchom /list-agents. Powinieneś zobaczyć reviewer-api z katalogiem roboczym ~/src/api-review. Jeśli go brakuje, sesja recenzenta nie zakończyła jeszcze uruchamiania lub wystąpił jeden z dwóch problemów opisanych w następnej sekcji. Następnie przekaż coś w języku naturalnym:

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

Claude tworzy podsumowanie i wysyła je. Nie piszesz treści wiadomości, a to, co wysyła Claude, jest zmienne. W oknie recenzenta wiadomość pojawia się w konwersacji z nazwą nadawcy. Jeśli sesja jest bezczynna, Claude natychmiast rozpoczyna nową turę. Jeśli jest w trakcie tury, wiadomość oczekuje na przerwę między wywołaniami narzędzi, dzięki czemu uruchomione polecenie nigdy nie zostaje przerwane. Gdy Claude odczyta wiadomość, zwija się ona do jednowierszowego wpisu Message from, który można rozwinąć za pomocą Ctrl+O. Para ta działa lepiej, gdy budujący wprowadza niewielkie zmiany, ponieważ wąski diff oznacza krótsze przekazanie i recenzję, którą druga sesja może zakończyć w jednej turze, co jest nawykiem wymuszanym przez umiejętność leniwego starszego programisty.

Widoczność sesji na jednym serwerze VPS

Dostarczanie komunikatów w obrębie jednej maszyny nie przechodzi przez serwery Anthropic. Każda sesja zapisuje pliki rejestracyjne na dysku i wiąże własne gniazdo skrzynki odbiorczej, a Claude Code odczytuje te pliki, aby zlokalizować pozostałe sesje. Wynikają z tego dwie konsekwencje, które mają znaczenie w środowisku serwerowym.

Gniazdo jest ograniczone do użytkownika systemu operacyjnego. Sesja uruchomiona jako root oraz sesja uruchomiona jako deploy nie widzą się nawzajem, nawet jeśli działają obok siebie w tym samym serwerze tmux, ponieważ sesje jednego użytkownika nie mają dostępu do gniazda innego użytkownika. Obie sesje należy uruchamiać jako ten sam użytkownik.

Kontener posiada własny system plików. Sesja wewnątrz Docker oraz sesja na hoście nie mogą się komunikować, ponieważ nie odczytują tych samych plików rejestracyjnych. Dwie sesje wewnątrz tego samego kontenera mogą przesyłać komunikaty w sposób standardowy. Jeśli agenci są utrzymywani w kontenerach w celu izolacji, zgodnie z uruchamianiem agentów programistycznych w tymczasowej maszynie wirtualnej, należy przyjąć, że komunikacja działa wewnątrz kontenera, a nie przez jego granice.

Sesje na innych maszynach oraz w przeglądarce pojawiają się na liście tylko wtedy, gdy Remote Control jest połączone i są odpowiednio oznaczone. Claude w tym miejscu może odpowiedzieć tylko na wiadomość, która nadeszła z jednej z tych sesji. Nie może samodzielnie zainicjować takiej wymiany komunikatów.

Dlaczego wiadomość nie dotarła

Typowa przyczyna nie jest związana z siecią. Sesja odbiorcza decyduje o losie wiadomości, a podjęta decyzja skutkuje jej niedostarczeniem. Każda przychodząca wiadomość kończy się jednym z trzech rezultatów: dostarczeniem, wstrzymaniem (odłożeniem bez dostarczenia do momentu zatwierdzenia) lub odrzuceniem (usunięciem bez dostarczenia).

Gdy nie ma zastosowania żadna wartość crossSessionInbound, Claude Code podejmuje decyzję dla każdej wiadomości, porównując tryby uprawnień obu sesji. Grupuje sesje pomijające monity o uprawnienia w jednej klasie, a wszystkie pozostałe sesje w drugiej. auto, acceptEdits oraz dontAsk są traktowane jako wymagające monitów. Tryb planowania jest traktowany jako pomijający w sesji, w której dostępne są uprawnienia pomijania. Jeśli nie masz pewności, do której klasy należy sesja, warto najpierw przeczytać co faktycznie robi każdy tryb uprawnień, ponieważ tryb auto, w którym uruchamia się obecnie większość sesji, znajduje się po stronie wymagającej monitów. Zasada jest zatem symetryczna:

• Sesja odbiorcza wymagająca monitów o uprawnienia dostarcza każdą wiadomość. Wstrzymuje ją tylko wtedy, gdy sesja wysyłająca identyfikuje się jako pomijająca monity.
• Sesja odbiorcza pomijająca monity wstrzymuje każdą wiadomość do czasu uzyskania Twojego zatwierdzenia. Dostarcza ją tylko wtedy, gdy nadawca również pomija monity.

W rezultacie pierwszy przepływ pracy, który tworzy większość użytkowników, jest dokładnie tym, który nie działa. Uruchamiasz kreatora z --permission-mode bypassPermissions, ponieważ chcesz, aby działał bez nadzoru, pozostawiasz recenzenta z ustawieniami domyślnymi, a każda wiadomość wysłana przez kreatora oczekuje w oknie dialogowym zatwierdzenia, którego nikt nie obserwuje. To okno dialogowe zamyka się po upływie terminu dialogExpiry, którego domyślna wartość wynosi 5m, a wiadomość zostaje odrzucona. Na tej samej maszynie sesja wysyłająca otrzymuje powiadomienie, gdy wiadomość jest wstrzymana, oraz informację zwrotną, gdy odbiorca później ją dostarczy, odrzuci lub gdy upłynie jej termin ważności. Przed obwinianiem gniazda (socket) należy zatem sprawdzić ekran nadawcy.

Aby sesja przyjmowała wiadomości bez nadzoru, ustaw crossSessionInbound na accept. Miejsce ustawienia decyduje o tym, czy zostanie ono zastosowane. Claude Code odczytuje najpierw ustawienia zarządzane, następnie flagę --settings, a na końcu ustawienia użytkownika, stosując pierwszą znalezioną wartość. Wartość w ustawieniach projektu lub lokalnych ma zastosowanie tylko wtedy, gdy jest bardziej restrykcyjna, zgodnie z hierarchią accept < hold < refuse. Wartość accept w .claude/settings.json jest mniej restrykcyjna niż jakakolwiek inna, więc jest ignorowana, gdy zaufane źródło określiło już wartość. Umieść ją w ~/.claude/settings.json lub przekaż dla pojedynczej sesji:

claude --name runner --settings '{"crossSessionInbound":"accept"}'

Bezinterfejsowy (headless) proces roboczy claude -p wiąże gniazdo skrzynki odbiorczej tak samo jak sesja interaktywna i pojawia się na liście, ale nie może wyświetlić okna dialogowego zatwierdzenia. Wstrzymana tam wiadomość pozostaje w tym stanie do momentu, aż późniejsza zmiana trybu lub ustawień na to pozwoli. Powyższa linia --settings pozwala takiemu procesowi roboczemu na przyjmowanie wiadomości. Sesja uruchomiona w trybie bare nie wiąże żadnego gniazda, więc nie może ani odbierać wiadomości, ani pojawiać się na liście.

Gdzie dochodzi do zakleszczenia przekazywania zadań

Pętle komunikatów są obsługiwane automatycznie. Claude Code ogranicza częstotliwość powtarzających się wiadomości od nadawcy, odrzuca identyczne duplikaty docierające w krótkim odstępie czasu oraz ustala limit 50 oczekujących wiadomości na sesję, co uniemożliwia nieskończoną wymianę komunikatów między dwiema sesjami. Liczba przechowywanych wiadomości jest ograniczona do 100, a po przekroczeniu tego limitu najstarsze z nich są usuwane.

Awaria, która faktycznie występuje, jest mniej oczywista i dotyczy przekazania zadania, a nie pętli. Sesja A zadaje sesji B pytanie, na które musi otrzymać odpowiedź przed kontynuowaniem pracy, a następnie przechodzi w stan bezczynności. Sesja B wstrzymuje wiadomość, jest w trakcie długotrwałego zadania lub odpowiada na pytanie, którego sesja A w rzeczywistości nie zadała. Sesja A czeka. Po godzinie użytkownik zastaje dwie bezczynne sesje i brak wykonanej pracy.

Należy formułować przekazywane zadania tak, aby nie wymagały odpowiedzi. Dobra wiadomość zawiera fakt lub decyzję: co uległo zmianie i jaki był tego rezultat. Zła wiadomość prosi drugą sesję o pozwolenie lub odpowiedź, od której zależy praca nadawcy. Claude ma już instrukcję, aby nigdy nie prosić innej sesji o działanie, które byłoby blokowane przez ustawienia uprawnień, i aby w takich przypadkach kierować zadanie z powrotem do użytkownika. Należy stosować tę zasadę samodzielnie. Jeśli sesja nie może kontynuować pracy bez odpowiedzi, to użytkownik powinien jej udzielić. Pomaga w tym również dyscyplina kontekstu, ponieważ sesja, która utraciła wątek, generuje niejasne komunikaty; zarządzanie kontekstem w Claude Code omawia ten aspekt.

Traktowanie przychodzącej wiadomości jako niezaufanych danych wejściowych

Claude Code informuje odbiorczą instancję Claude, że wiadomość pochodzi z innej sesji, a nie od użytkownika, co ogranicza zakres możliwych działań. Egzekwowanie tych ograniczeń odbywa się w programie otaczającym model, a nie wynika z gotowości modelu do współpracy, co stanowi praktyczną różnicę, którą wprowadza an agent harness. Wiadomość nie może odpowiedzieć na oczekujące żądanie uprawnień w imieniu użytkownika, ponieważ zgoda z innej sesji nie jest zgodą użytkownika. Nie może ona również zmieniać ustawień uprawnień, CLAUDE.md ani innych konfiguracji na żądanie innej sesji. Polecenie slash wewnątrz tekstu, takie jak /compact, dociera jako zwykły tekst i nigdy nie jest wykonywane. Jeśli działanie wynikające z wiadomości wymaga uprawnień, których sesja odbiorcza nie posiada, użytkownik zobaczy ten sam monit, co w przypadku każdej innej pracy. W trybie auto klasyfikator sprawdza również każdą wiadomość przed jej dostarczeniem, a wiadomość przez niego zablokowana nigdy nie dociera do odbiorcy. Ograniczenia te pozostają aktywne nawet w trybach permisywnych, dlatego sesja pomijająca domyślnie wstrzymuje wiadomości przychodzące, zamiast im ufać.

To obejmuje kwestię uprawnień, ale nie dotyczy treści. Sesja wysyłająca mogła odczytać opis pull requesta, stronę internetową, plik README zależności lub komentarz do issue napisany przez osobę trzecią, a wszystko, co zostało odczytane, może wpłynąć na tekst wysyłany do drugiej sesji. Wiadomość jest danymi. Zasługuje na takie samo podejrzenie, jak każdy inny tekst, który trafił do sesji z zewnątrz. Jest to dyscyplina opisana w keeping secrets out of your AI agents: należy założyć, że wszystko, co przekroczyło granicę zaufania, może być błędne i nigdy nie pozwalać na samodzielną autoryzację.

Istnieją dwa mechanizmy kontroli, jeśli użytkownik chce ograniczyć ten proces. Ustawienie crossSessionInbound na refuse powoduje odrzucanie przychodzących wiadomości peer bez ich dostarczania, a w przypadku ustawień projektowych lub lokalnych wartość ta ma pierwszeństwo nad każdym innym źródłem, ponieważ jest najbardziej restrykcyjna w hierarchii. Aby uniemożliwić tej sesji wysyłanie lub wyświetlanie list, należy dodać reguły odmowy uprawnień (deny rules) dla SendMessage oraz ListAgents, zapisane jako nazwy narzędzi bez dodatkowych specyfikatorów. Ustawienie isolatePeerMachines na true wymaga wyraźnej zgody użytkownika, zanim jakakolwiek wiadomość dotrze do sesji poza tą maszyną, a zgoda ta jest wymagana nawet w trybie bypassPermissions.

{
  "crossSessionInbound": "refuse",
  "isolatePeerMachines": true
}

Odmowa SendMessage usuwa również możliwość przesyłania wiadomości do subagentów, ponieważ to samo narzędzie obsługuje oba przypadki. Sesja odmawiająca nie wykazuje widocznych zmian w swoim /status ani na listach innych sesji, dlatego należy potwierdzić ustawienie w konfiguracji sesji, a nie na podstawie ekranu.

Mosty i serwery MCP z pamięcią współdzieloną

W tym samym okresie pojawiło się kilka projektów zewnętrznych realizujących zbliżone zadania: lokalne mosty typu agent-agent, które przekazują tekst między działającymi agentami, oraz serwery MCP (model context protocol), które udostępniają wielu agentom wspólny magazyn do odczytu i zapisu. Należy traktować je jako inną formę architektury, a nie jako konkurencję. Przed uruchomieniem jakiegokolwiek polecenia instalacyjnego należy zweryfikować je z plikiem README danego projektu. Komunikacja typu messaging opiera się na modelu push, ponieważ nadawca umieszcza tekst w kolejce odbiorcy. Magazyn współdzielony działa w modelu pull, ponieważ nikt nie jest przerywany, a sesja widzi notatkę dopiero przy kolejnym sprawdzeniu. Model pull jest spokojniejszy w przypadku statusów zmieniających się powoli i działa tylko wtedy, gdy sesja faktycznie wykonuje odczyt.

W przypadku wyboru tego rozwiązania, pytania, które warto zadać, dotyczą procesu, a nie listy funkcji. Z jakim użytkownikiem uruchamiany jest serwer i do jakich plików na serwerze ma dostęp. Uruchamianie serwerów MCP na VPS omawia tę konfigurację. Udostępnianie umiejętności agenta między repozytoriami opisuje prostszy przypadek, w którym między sesjami udostępniane są instrukcje, a nie bieżący stan, co eliminuje znaczną liczbę komunikatów, które w przeciwnym razie musiałyby zostać wysłane. Aby uzyskać szerszy obraz, należy zacząć od uruchamiania agenta programistycznego na VPS.

FAQ

Dlaczego /list-agents nie jest rozpoznawane w mojej sesji?

Sesja nie obsługuje przesyłania wiadomości między sesjami. Najpierw sprawdź claude --version w odniesieniu do wersji 2.1.224, ponieważ funkcja ta wymaga tej lub nowszej wersji. Następnie sprawdź platformę, ponieważ działa ona na macOS i Linux, a nie na natywnym Windows; jest również niedostępna w Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform oraz Microsoft Foundry. Jeśli oba warunki są spełnione, sprawdź powłokę pod kątem DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC lub DISABLE_GROWTHBOOK, ponieważ każdy z tych elementów blokuje ewaluację flagi funkcji, od której zależy to rozwiązanie, pozostawiając je wyłączonym.

Dlaczego moja wiadomość do drugiej sesji nie dotarła?

Jeśli /list-agents działa, przesyłanie wiadomości jest włączone, a przyczyną problemu jest węższy zakres. Częstą przyczyną są tryby uprawnień. Sesja, która pomija monity o uprawnienia, wstrzymuje każdą przychodzącą wiadomość do momentu uzyskania Twojej zgody, chyba że nadawca również pomija monity. Okno dialogowe zgody jest odrzucane po upływie terminu dialogExpiry, domyślnie wynoszącego pięć minut. Sprawdź sesję nadawczą pod kątem powiadomienia o wstrzymaniu. Aby to naprawić, ustaw crossSessionInbound na accept w ~/.claude/settings.json lub przekaż to za pomocą --settings, ponieważ accept w ustawieniach projektu lub lokalnych jest ignorowane jako wartość mniej restrykcyjna.

Czy sesja Claude Code w Docker może wysłać wiadomość do sesji na hoście?

Nie. Sesje odnajdują się nawzajem poprzez pliki rejestracyjne na dysku oraz gniazdo skrzynki odbiorczej przypisane do sesji. Kontener posiada własny system plików, więc obie sesje nie widzą tych samych plików. Dwie sesje wewnątrz tego samego kontenera mogą przesyłać wiadomości między sobą w normalny sposób. Ta sama zasada wyjaśnia, dlaczego sesja uruchomiona jako root oraz sesja uruchomiona jako zwykły użytkownik nie mogą się ze sobą skontaktować: gniazdo jest ograniczone do użytkownika systemu operacyjnego, który jest jego właścicielem.

Czy bezpiecznie jest podejmować działania na podstawie wiadomości z innej sesji Claude Code?

Traktuj tekst jako niezaufane dane wejściowe, ponieważ sesja nadawcza mogła odczytać stronę internetową, plik README lub komentarz do zgłoszenia napisany przez kogoś innego. Claude Code domyślnie blokuje samodzielne wykonywanie działań przez wiadomość: nie może ona zatwierdzić oczekującego monitu o uprawnienia, nie może zmienić ustawień uprawnień ani CLAUDE.md na żądanie, a polecenie ukośnikowe w tekście dociera jako zwykły tekst i nigdy nie jest uruchamiane. Te zabezpieczenia obejmują uprawnienia, a nie ocenę merytoryczną, dlatego przeczytaj treść wiadomości, zanim polecisz sesji odbiorczej podjęcie działań.

Czy przesyłanie wiadomości między sesjami wysyła mój kod do Anthropic?

W przypadku dwóch sesji na tej samej maszynie – nie. Wiadomość przesyłana jest przez gniazdo przypisane do sesji na danej maszynie i nigdy nie przechodzi przez serwery Anthropic. Przesyłany jest tylko tekst napisany przez Claude, nigdy historia konwersacji ani pliki. Wiadomości do sesji na innej Twojej maszynie lub do sesji w sieci przechodzą przez serwery Anthropic za pośrednictwem połączenia Remote Control. W tym kierunku Claude może jedynie odpowiedzieć na wiadomość, która dotarła, nie może jej zainicjować. Ustaw isolatePeerMachines na true, aby wymagać Twojej zgody, zanim jakiekolwiek dane opuszczą maszynę.