Claude Code: komunikacja między sesjami na VPS

Znaczenie komunikacji między sesjami Claude Code

Dwie sesje Claude Code mogą komunikować się ze sobą, gdy działają na tym samym komputerze i w ramach tego samego użytkownika systemu operacyjnego. Wiadomość to jeden fragment zwykłego tekstu, który jedna instancja Claude zapisuje dla drugiej. Nie zawiera historii rozmowy ani plików. Claude wyszukuje drugą sesję za pomocą narzędzia ListAgents i dostarcza tekst za pomocą SendMessage, dlatego nie wywołuje się żadnego z tych narzędzi ręcznie. Wystarczy określić, co druga sesja powinna wiedzieć. Claude sam tworzy wiadomość.

Ta funkcja nosi nazwę komunikacji między sesjami. Od August 2026 wymaga Claude Code v2.1.224 lub nowszej wersji. Działa w systemach macOS i Linux, w tym w systemie Linux uruchomionym w WSL 2. Nie ma natywnej obsługi systemu Windows. Funkcja nie jest dostępna w Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform ani Microsoft Foundry. Jeśli sesja spełnia te wymagania, komunikacja jest już włączona i nie trzeba niczego konfigurować. Opisane niżej działanie pochodzi z dokumentacji Anthropic dotyczącej komunikacji między sesjami.

VPS ma tu znaczenie, ponieważ sesje działają na nim wystarczająco długo, aby komunikacja między nimi była przydatna. Na laptopie można zamknąć pokrywę. Na serwerze z tmux sesja uruchomiona w poniedziałek może nadal działać w czwartek, zachowując kontekst jednego repozytorium. Gdy działają już dwie takie sesje, sposób ich komunikacji przestaje być kwestią teoretyczną. Jeśli nie skonfigurowano jeszcze takiego środowiska, należy rozpocząć od uruchamiania Claude Code na VPS z użyciem tmux, gdzie opisano konfigurację sesji wymaganą w tym przewodniku.

Kiedy druga sesja jest warta dodatkowych tokenów

Zacznij od kosztu. Każda sesja jest osobną instancją Claude z własnym oknem kontekstu, dlatego dwie sesje kosztują w przybliżeniu dwa razy więcej niż jedna w tym samym czasie. Dostarczona wiadomość jest wliczana do limitu użycia tak samo jak prompt wpisany ręcznie. Koordynacja nie jest bezpłatna, a praca, która w rzeczywistości jest jednym ciągiem kroków, staje się wolniejsza i droższa po podzieleniu jej między sesje.

Przypadki, w których druga sesja się opłaca, mają wspólną cechę. Dwa zadania są wykonywane jednocześnie, bez wzajemnego oczekiwania, a jedno z nich w trakcie pracy uzyskuje informację potrzebną drugiemu.

• Jedna sesja wykrywa zmianę powodującą niezgodność, podczas gdy druga buduje rozwiązanie na kodzie, którego ta zmiana dotyczy. Claude podsumowuje zmianę i przekazuje ją, zamiast wymagać ponownego wpisania jej przez użytkownika w drugim terminalu.
• Dwie sesje pracują z tym samym repozytorium w osobnych git worktrees, a jedna musi wiedzieć, jakie zmiany zostały wprowadzone.
• Długa migracja lub przebieg testów przekazuje wynik do obserwowanej sesji.
• Sesja implementacyjna i sesja przeglądu, w której sesja przeglądu analizuje wynik pracy sesji implementacyjnej i przekazuje ustalenia.

Gdy praca jest sekwencyjna lub gdy obie sesje modyfikowałyby te same pliki, należy użyć jednej sesji. Jeśli potrzebna jest skoordynowana grupa tworzona i nadzorowana przez Claude w ramach jednego zadania, chodzi o agent teams — osobną i nadal eksperymentalną funkcję. Jeśli potrzebna jest tylko ta sama rozmowa w innym terminalu, należy wznowić sesję. Przesyłanie wiadomości między sesjami służy do komunikacji między niezależnymi sesjami uruchamianymi i sterowanymi samodzielnie.

Sprawdź dostępność funkcji, zanim oprzesz na niej konfigurację

Najpierw sprawdź wersję:

claude --version

Porównaj numer z 2.1.224. Następnie w sesji wpisz /list-agents, które działa również jako /peers. Polecenie wyświetla wszystkie agenty, z którymi ta sesja może się komunikować, wraz z nazwą, na którą każdy z nich odpowiada. Jeśli polecenie w ogóle nie zostanie rozpoznane, ta sesja nie obsługuje komunikacji między sesjami. Żaden plik ustawień tego nie zmieni. Wpisz /status i odszukaj wiersz Peer address. Zawiera on adres skrzynki odbiorczej tej sesji, poprzedzony przez uds:.

Użytkownicy VPS muszą zwrócić uwagę na szczególną pułapkę. Komunikacja między sesjami zależy od ewaluacji flag funkcji. Kilka zmiennych prywatności wyłącza tę ewaluację, przez co funkcja pozostaje domyślnie wyłączona. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC i DISABLE_GROWTHBOOK powodują takie zachowanie. Podczas zabezpieczania nowego serwera administratorzy wklejają 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ń albo z ustawień zarządzanych, dlatego najpierw sprawdź środowisko powłoki.

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

Usuń ustawienie tej zmiennej, która zwraca wynik. W przypadku DISABLE_TELEMETRY i CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC dowolna niepusta wartość włącza to zachowanie, w tym ciąg 0. Dlatego DISABLE_TELEMETRY=0 nie wyłącza funkcji, mimo że tak wygląda. Aby ją wyłączyć, usuń zmienną albo ustaw ją na pusty ciąg.

Nadaj nazwę sesjom, inaczej Claude nie będzie mógł się do nich odwoływać

Claude kieruje wiadomość do sesji na podstawie jej nazwy. Ustaw nazwę podczas uruchamiania sesji:

claude --name builder-api

Nazwę można także ustawić za pomocą /rename w działającej sesji. Jeśli nazwa nie zostanie ustawiona, Claude Code wyznaczy ją na podstawie nazwy katalogu roboczego, na przykład myapp-3f. W przypadku jednej sesji jest to wystarczające, ale przy czterech sesjach powoduje problemy. Dwie sesje mogą otrzymać tę samą nazwę. Dane wyjściowe polecenia /list-agents pokazują katalog roboczy każdej sesji lokalnej, dzięki czemu można rozróżnić sesje o tych samych nazwach. Własny wykaz Claude dodaje do adresu krótki identyfikator, gdy nazwy się powtarzają. Nadanie nazw sesjom jest prostsze niż odczytywanie identyfikatorów.

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

Jest to sesja programisty i sesja recenzenta pracujące na jednym repozytorium. Recenzent działa w osobnym git worktree, dlatego obie sesje nigdy nie zapisują danych w tym samym pliku. git worktree add razem z HEAD tworzy odłączony checkout, co jest właściwym rozwiązaniem dla sesji, która odczytuje dane, ale nie wykonuje commitów.

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 okna według nazw, aby można było wybrać jedno z nich. W oknie programisty uruchom /list-agents. Powinien pojawić się reviewer-api z katalogiem roboczym ~/src/api-review. Jeśli go nie ma, sesja recenzenta nie zakończyła jeszcze uruchamiania albo występuje jeden z dwóch problemów opisanych w następnej sekcji. Następnie przekaż informację prostym językiem:

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

Claude zapisuje podsumowanie i wysyła je. Nie należy samodzielnie wpisywać treści wiadomości, a treść wysyłana przez Claude może się różnić. W oknie recenzenta wiadomość pojawia się w rozmowie wraz z nazwą nadawcy. Jeśli ta sesja jest bezczynna, Claude od razu rozpoczyna w niej nową turę. Jeśli trwa w niej wykonywanie tury, wiadomość czeka do chwili między wywołaniami narzędzi, więc uruchomione polecenie nigdy nie zostaje przerwane. Po odczytaniu wiadomości przez Claude zostaje ona zwinięta do jednoliniowego wiersza Message from, który Ctrl+O rozwija. Sesje współpracują lepiej, gdy programista ogranicza zakres zmian, ponieważ wąski diff oznacza krótsze przekazanie oraz przegląd, który druga sesja może zakończyć w jednej turze. Taki sposób pracy wymusza nawyk umiejętność leniwego doświadczonego programisty.

Kto może widzieć inne sesje na jednym VPS

Dostarczanie na tej samej maszynie nigdy nie odbywa się 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 znaleźć inne sesje. Wynikają z tego dwa skutki. Oba mają znaczenie na serwerze.

Dostęp do gniazda jest ograniczony do użytkownika systemu operacyjnego, który je utworzył. Sesja uruchomiona jako root i sesja uruchomiona jako deploy nie mogą się wzajemnie wykrywać, nawet jeśli działają obok siebie w tym samym serwerze tmux, ponieważ sesje jednego użytkownika nie mogą uzyskać dostępu do gniazda innego użytkownika. Obie sesje należy uruchomić jako ten sam użytkownik.

Kontener ma własny system plików. Sesja działająca w Docker i sesja działająca na hoście nie mogą się wzajemnie wykrywać, ponieważ nie odczytują tych samych plików rejestracyjnych. Dwie sesje działające w tym samym kontenerze mogą normalnie wymieniać wiadomości. Jeśli agenty są uruchamiane w kontenerach w celu izolacji, tak jak opisano w uruchamianiu agentów kodujących w jednorazowej maszynie wirtualnej, należy oczekiwać, że wymiana wiadomości będzie działać wewnątrz kontenera, ale nie między kontenerem a hostem.

Sesje działające na innych maszynach oraz w sieci Web są widoczne na liście tylko wtedy, gdy Remote Control jest połączony. Są odpowiednio oznaczone. Claude działający tutaj może odpowiedzieć wyłącznie na wiadomość otrzymaną z jednej z tych sesji. Nie może samodzielnie rozpocząć takiej wymiany.

Dlaczego wiadomość nigdy nie dotarła

Zwykle przyczyna nie ma nic wspólnego z siecią. Sesja odbierająca zdecydowała, co zrobić z wiadomością, i nie wybrała jej dostarczenia. Każda przychodząca wiadomość kończy się jednym z trzech wyników: dostarczona, wstrzymana (odłożona bez dostarczenia do czasu zatwierdzenia) albo odrzucona (usunięta bez dostarczenia).

Gdy nie obowiązuje żadna wartość crossSessionInbound, Claude Code podejmuje decyzję dla każdej wiadomości, porównując tryby uprawnień obu sesji. Sesje, które pomijają monity o uprawnienia, grupuje w jednej klasie, a wszystkie pozostałe sesje w drugiej. auto, acceptEdits i dontAsk są traktowane jako monity. Tryb planowania jest traktowany jako pomijanie monitów w sesji, w której dostępne są uprawnienia umożliwiające ich pomijanie. Reguła jest wtedy symetryczna:

• Sesja odbierająca, która wyświetla monity o uprawnienia, otrzymuje każdą wiadomość. Wstrzymuje ją tylko wtedy, gdy sesja wysyłająca identyfikuje się jako pomijająca monity.
• Sesja odbierająca, która pomija monity, wstrzymuje każdą wiadomość do zatwierdzenia. Dostarcza ją tylko wtedy, gdy nadawca również pomija monity.

Dlatego pierwszy przepływ pracy, który większość osób tworzy, jest dokładnie tym, który nie działa. Uruchamiasz builder z --permission-mode bypassPermissions, ponieważ ma działać bez nadzoru, pozostawiasz reviewera z ustawieniami domyślnymi, a każda wiadomość wysłana przez buildera czeka w oknie zatwierdzenia, którego nikt nie obserwuje. To okno zamyka się po upływie terminu dialogExpiry, którego domyślną wartością jest 5m, a wiadomość zostaje usunięta. Na tym samym komputerze sesja wysyłająca otrzymuje powiadomienie, gdy jej wiadomość zostanie wstrzymana, oraz kolejne powiadomienie, gdy odbiorca później ją dostarczy, odrzuci lub gdy wiadomość wygaśnie. Dlatego przed obwinieniem gniazda sprawdź ekran sesji wysyłającej.

Aby sesja przyjmowała wiadomości bez nadzoru, ustaw crossSessionInbound na accept. Miejsce ustawienia decyduje o zakresie obowiązywania tej wartości. Claude Code najpierw odczytuje ustawienia zarządzane, następnie flagę --settings, a potem ustawienia użytkownika i stosuje pierwszą znalezioną wartość. Wartość w ustawieniach projektu lub lokalnych ma zastosowanie tylko wtedy, gdy jest bardziej restrykcyjna, zgodnie z kolejnością accept < hold < refuse. Wartość accept w .claude/settings.json jest mniej restrykcyjna niż dowolna inna, dlatego jest ignorowana, gdy zaufane źródło ustawiło już wartość. Umieść ją w ~/.claude/settings.json albo przekaż dla jednej sesji:

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

Pracownik bez interfejsu claude -p wiąże gniazdo skrzynki odbiorczej tak jak sesja interaktywna i pojawia się na liście, ale nie może wyświetlić okna zatwierdzenia. Wstrzymana wiadomość pozostaje tam wstrzymana do czasu, gdy późniejsza zmiana trybu lub ustawień umożliwi jej przyjęcie. Wiersz --settings powyżej służy do zezwolenia takiemu pracownikowi na przyjmowanie wiadomości. Sesja uruchomiona w trybie bare nie wiąże żadnego gniazda, dlatego nie może odbierać wiadomości ani pojawiać się na liście.

Gdy przekazanie pracy blokuje postęp

Pętle wiadomości są obsługiwane automatycznie. Claude Code ogranicza częstotliwość powtarzanych wiadomości od jednego nadawcy, odrzuca identyczne powtórzenia odebrane w krótkim odstępie oraz ogranicza do 50 liczbę zaakceptowanych wiadomości oczekujących na odczyt w jednej sesji, dzięki czemu dwie sesje nie mogą bez końca wymieniać między sobą wiadomości. Liczba wstrzymanych wiadomości jest ograniczona do 100. Po przekroczeniu tego limitu usuwane są najstarsze wiadomości.

Rzeczywista awaria przebiega ciszej i dotyczy przekazania pracy, a nie pętli. Sesja A zadaje sesji B pytanie, na które musi uzyskać odpowiedź przed kontynuowaniem pracy, a następnie przechodzi w stan bezczynności. Sesja B przetrzymuje wiadomość, wykonuje długotrwałą operację albo odpowiada na pytanie, którego sesja A faktycznie nie zadała. Sesja A czeka. Po godzinie wraca się do dwóch bezczynnych sesji, a praca nie została wykonana.

Przekazania pracy należy formułować tak, aby nie wymagały odpowiedzi. Dobra wiadomość zawiera fakt lub decyzję: informuje, co się zmieniło i jaki był wynik. Zła wiadomość prosi drugą sesję o zgodę albo o odpowiedź, od której nadawca uzależnia dalszą pracę. Claude ma już instrukcję, aby nigdy nie prosić innej sesji o wykonanie działania, które byłoby zablokowane przez własne ustawienia uprawnień, lecz przekazywać takie zadanie użytkownikowi. Tę zasadę należy rozszerzyć samodzielnie. Jeżeli sesja nie może kontynuować pracy bez odpowiedzi, odpowiedzi powinien udzielić użytkownik. Pomaga również właściwe zarządzanie kontekstem, ponieważ sesja, która utraciła kontekst zadania, formułuje nieprecyzyjne wiadomości; zarządzanie kontekstem w Claude Code opisuje tę kwestię.

Traktuj wiadomość przychodzącą jako niezaufane dane wejściowe

Claude Code informuje odbierającą sesję Claude, że wiadomość pochodzi z innej sesji, a nie od użytkownika, i ogranicza zakres działań, jakie może ona wywołać. Wiadomość nie może w imieniu użytkownika odpowiedzieć na oczekujące żądanie o zgodę, ponieważ zgoda udzielona w innej sesji nie jest zgodą użytkownika. Nie może też zmieniać ustawień uprawnień, CLAUDE.md ani innych elementów konfiguracji tylko dlatego, że zażądała tego inna sesja. Polecenie slash umieszczone w tekście, takie jak /compact, dociera jako zwykły tekst i nigdy nie jest wykonywane. Jeżeli wykonanie działania na podstawie wiadomości wymaga uprawnienia, którego odbierająca sesja nie ma, wyświetlany jest taki sam monit jak przy każdej innej operacji. W trybie automatycznym klasyfikator dodatkowo sprawdza każdą wiadomość przed dostarczeniem, a wiadomość zablokowana przez klasyfikator nigdy nie trafia do odbiorcy. Ograniczenia te obowiązują również w trybach zezwalających na więcej operacji. Dlatego sesja umożliwiająca obchodzenie zabezpieczeń domyślnie wstrzymuje wiadomości przychodzące, zamiast im ufać.

To wyjaśnia kwestie uprawnień. Nie obejmuje jednak treści. Sesja wysyłająca mogła odczytać opis pull requesta, stronę internetową, README zależności albo komentarz do zgłoszenia napisany przez nieznaną osobę. Wszystko, co odczytała, może wpłynąć na treść wysyłaną do drugiej sesji użytkownika. Wiadomość jest danymi. Należy traktować ją z taką samą ostrożnością jak każdy inny tekst, który trafił do sesji z zewnątrz. Tę zasadę opisano w niewprowadzaniu sekretów do agentów AI: należy zakładać, że wszystko, co przekroczyło granicę zaufania, może być nieprawidłowe, i nigdy nie pozwalać, aby samo sobie nadawało uprawnienia.

Jeśli konieczne jest ograniczenie tego mechanizmu, dostępne są dwa ustawienia. Ustawienie crossSessionInbound na refuse odrzuca wiadomości od równorzędnych sesji bez ich dostarczania. W ustawieniach projektu lub lokalnych ta wartość ma pierwszeństwo przed każdym innym źródłem, ponieważ jest najbardziej restrykcyjna w całej hierarchii. Aby uniemożliwić tej sesji wysyłanie lub wyświetlanie listy, należy dodać reguły odmowy uprawnień zawierające SendMessage i ListAgents. Obie wartości należy zapisać jako same nazwy narzędzi, bez specyfikatora. Ustawienie isolatePeerMachines na true wymaga jawnego zatwierdzenia użytkownika przed dostarczeniem dowolnej wiadomości do sesji znajdującej się poza tym komputerem. Zatwierdzenie jest wymagane również w trybie bypassPermissions.

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

Odmowa uprawnienia SendMessage uniemożliwia również komunikację z podagentami, ponieważ oba zastosowania korzystają z tego samego narzędzia. W sesji odmawiającej uprawnienia nie widać żadnej zmiany w jej własnym /status ani na listach innych sesji. Dlatego ustawienie należy potwierdzić w konfiguracji sesji, a nie na ekranie.

Mosty i serwery MCP korzystające ze współdzielonej pamięci

W tym samym okresie pojawiło się kilka projektów zewnętrznych realizujących pokrewne zadania: lokalne mosty agent-agent przekazujące tekst między działającymi agentami oraz serwery MCP (model context protocol), które udostępniają kilku agentom wspólny magazyn danych do odczytu i zapisu. Należy traktować je jako inne rozwiązania, a nie jako konkurencję, oraz zweryfikować każdą komendę instalacyjną w README projektu przed jej uruchomieniem. Komunikacja wykorzystująca wiadomości działa w trybie push, ponieważ nadawca wstawia tekst do tury odbiorcy. Wspólny magazyn działa w trybie pull, ponieważ żadna sesja nie jest przerywana, a sesja widzi notatkę dopiero przy następnym odczycie. Tryb pull jest spokojniejszy w przypadku stanu zmieniającego się powoli i działa tylko wtedy, gdy sesja rzeczywiście wykonuje odczyt.

Jeśli zostanie wybrane takie rozwiązanie, warto skupić się na pytaniach dotyczących procesu, a nie listy funkcji. Jako jaki użytkownik działa serwer i do czego może uzyskać dostęp na hoście. Sekcja Uruchamianie serwerów MCP na VPS opisuje tę konfigurację. Sekcja Współdzielenie umiejętności agentów między repozytoriami dotyczy prostszego przypadku, w którym między sesjami mają być współdzielone instrukcje, a nie bieżący stan. Ogranicza to liczbę wiadomości, które w przeciwnym razie trzeba byłoby wysyłać. Szerszy kontekst przedstawiono w sekcji uruchamianie agenta programistycznego na VPS, od której warto rozpocząć.

FAQ

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

Sesja nie obsługuje komunikacji między sesjami. Najpierw sprawdź claude --version względem wersji 2.1.224, ponieważ ta funkcja wymaga tej wersji lub nowszej. Następnie sprawdź platformę, ponieważ funkcja działa w systemach macOS i Linux, ale nie w natywnym Windows, oraz jest niedostępna w Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform i Microsoft Foundry. Jeśli oba warunki są spełnione, sprawdź, czy w powłoce nie ustawiono DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC lub DISABLE_GROWTHBOOK, ponieważ każdy z tych parametrów blokuje sprawdzanie flagi funkcji, od którego zależy jej działanie, i pozostawia ją wyłączoną.

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

Jeśli /list-agents działa, komunikacja jest włączona i przyczyna dotyczy wyłącznie tej wiadomości. Najczęstszą przyczyną są tryby uprawnień. Sesja, która pomija monity o uprawnienia, wstrzymuje każdą przychodzącą wiadomość do czasu zatwierdzenia jej przez użytkownika, chyba że nadawca również pomija monity. To okno zatwierdzenia jest usuwane po upływie terminu dialogExpiry, który domyślnie wynosi pięć minut. Sprawdź w sesji wysyłającej komunikat o wstrzymanej wiadomości. Aby to naprawić, ustaw crossSessionInbound na accept w ~/.claude/settings.json albo przekaż tę wartość za pomocą --settings, ponieważ wartość accept w ustawieniach projektu lub lokalnych jest ignorowana jako mniej restrykcyjna.

Czy sesja Claude Code w Docker może wysyłać wiadomości do sesji działającej na hoście?

Nie. Sesje odnajdują się za pomocą plików rejestracyjnych na dysku oraz gniazda skrzynki odbiorczej przypisanego do sesji, a kontener ma własny system plików, więc obie sesje nie mogą uzyskać dostępu do tych samych plików. Dwie sesje w tym samym kontenerze mogą normalnie komunikować się ze sobą. Ta sama zasada wyjaśnia, dlaczego sesja działająca jako root i sesja działająca jako zwykły użytkownik nie mogą się ze sobą komunikować: gniazdo jest ograniczone do użytkownika systemu operacyjnego, który jest jego właścicielem.

Czy można bezpiecznie wykonywać działania na podstawie wiadomości z innej sesji Claude Code?

Traktuj tekst jako niezaufane dane wejściowe, ponieważ sesja wysyłająca mogła odczytać stronę internetową, plik README albo komentarz do zgłoszenia napisany przez inną osobę. Claude Code już uniemożliwia wiadomości samodzielne wykonanie działań: wiadomość nie może zatwierdzić oczekującego monitu o uprawnienia, zmienić ustawień uprawnień ani CLAUDE.md na żądanie, a polecenie slash zawarte w tekście jest odbierane jako zwykły tekst i nigdy nie jest wykonywane. Zabezpieczenia te dotyczą uprawnień, a nie oceny sytuacji, dlatego przed poleceniem sesji odbierającej wykonania działania należy przeczytać otrzymaną treść.

Czy komunikacja między sesjami wysyła mój kod do Anthropic?

Nie, jeśli obie sesje działają na tym samym komputerze. Wiadomość jest przesyłana przez gniazdo przypisane do sesji na tym komputerze i nigdy nie przechodzi przez serwery Anthropic. Wysyłany jest wyłącznie tekst wygenerowany przez Claude, a nie historia konwersacji ani pliki. Wiadomości do sesji na innym komputerze użytkownika lub do sesji w sieci są przesyłane przez serwery Anthropic za pośrednictwem połączenia Remote Control. W tym kierunku Claude może odpowiadać wyłącznie na otrzymaną wiadomość, a nie inicjować komunikację. Ustaw isolatePeerMachines na true, aby wymagać zatwierdzenia użytkownika przed wysłaniem jakichkolwiek danych poza komputer.