Claude Code: Sitzungen Nachrichten senden lassen

Was es bedeutet, wenn Claude-Code-Sitzungen Nachrichten austauschen

Zwei Claude-Code-Sitzungen können Nachrichten austauschen, wenn sie auf demselben Rechner und unter demselben Betriebssystembenutzer ausgeführt werden. Eine Nachricht ist ein einzelner Klartextabschnitt, den eine Claude-Sitzung für eine andere schreibt. Sie enthält weder den bisherigen Gesprächsverlauf noch Dateien. Claude findet die andere Sitzung mit dem ListAgents-Tool und übermittelt den Text mit SendMessage. Sie rufen keines der beiden Tools manuell auf. Sie geben an, was die andere Sitzung wissen muss, und Claude schreibt die Nachricht selbst.

Die Funktion heißt Cross-Session-Messaging. Seit August 2026 benötigt sie Claude Code v2.1.224 oder höher. Sie läuft unter macOS und Linux, einschließlich Linux innerhalb von WSL 2. Es gibt keine native Unterstützung für Windows. Außerdem ist die Funktion auf Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform und Microsoft Foundry nicht verfügbar. Wenn eine Sitzung diese Voraussetzungen erfüllt, ist Messaging bereits aktiviert. Es muss nichts konfiguriert werden. Das nachfolgend beschriebene Verhalten basiert auf der Anthropic-Dokumentation zu Cross-Session-Messaging.

Auf einem VPS ist diese Funktion besonders relevant, weil Sitzungen dort lange genug laufen, um gezielt angesprochen zu werden. Auf einem Laptop schließen Sie den Deckel. Auf einem Server unter tmux läuft eine Sitzung, die Sie am Montag gestartet haben, am Donnerstag möglicherweise noch und enthält weiterhin den Kontext eines Repositorys. Sobald zwei solcher Sitzungen vorhanden sind, ist ihre Kommunikation keine theoretische Frage mehr. Wenn Sie das noch nicht eingerichtet haben, beginnen Sie mit Claude Code auf einem VPS unter tmux ausführen. Dort wird die Sitzungsverwaltung beschrieben, von der dieser Leitfaden ausgeht.

Wann sich eine zweite Sitzung lohnt

Beginnen Sie mit den Kosten. Jede Sitzung ist eine eigene Claude-Instanz mit einem eigenen Kontextfenster. Zwei Sitzungen kosten daher über denselben Zeitraum ungefähr doppelt so viel wie eine Sitzung. Eine zugestellte Nachricht zählt für die Nutzung genauso wie ein von Ihnen eingegebener Prompt. Die Koordination ist nicht kostenlos. Arbeit, die eigentlich aus einer Abfolge von Schritten besteht, wird langsamer und teurer, wenn Sie sie auf mehrere Sitzungen aufteilen.

In den Fällen, in denen sich eine zweite Sitzung amortisiert, ist das Muster gleich. Zwei Arbeitsabschnitte laufen gleichzeitig, ohne aufeinander zu warten. Einer davon gewinnt während der Bearbeitung Informationen, die der andere benötigt.

• Eine Sitzung erkennt eine inkompatible Änderung, während die andere auf dem dadurch beschädigten Code aufbaut. Claude fasst die Änderung zusammen und sendet sie, sodass Sie sie nicht im anderen Terminal erneut eingeben müssen.
• Zwei Sitzungen bearbeiten dasselbe Repository in separaten git worktrees. Eine Sitzung muss wissen, welche Änderungen übernommen wurden.
• Eine lange Migration oder ein Testlauf meldet das Ergebnis an die Sitzung zurück, die Sie beobachten.
• Eine Builder-Sitzung und eine Reviewer-Sitzung: Der Reviewer liest die Ergebnisse des Builders und sendet zurück, was er festgestellt hat.

Wenn die Arbeit sequenziell abläuft oder beide Sitzungen dieselben Dateien bearbeiten würden, verwenden Sie eine Sitzung. Wenn Sie eine koordinierte Gruppe wünschen, die Claude innerhalb einer einzelnen Aufgabe startet und überwacht, handelt es sich um agent teams, eine separate und weiterhin experimentelle Funktion. Wenn Sie nur dieselbe Unterhaltung in einem anderen Terminal benötigen, setzen Sie die Sitzung stattdessen fort. Die sitzungsübergreifende Nachrichtenübermittlung ist für unabhängige Sitzungen vorgesehen, die Sie selbst starten und steuern.

Prüfen Sie, ob die Funktion vorhanden ist, bevor Sie Ihre Planung darauf ausrichten

Prüfen Sie zuerst die Version:

claude --version

Vergleichen Sie die Nummer mit 2.1.224. Geben Sie anschließend innerhalb einer Sitzung /list-agents ein. Der Befehl ist auch unter /peers verfügbar. Er gibt alle Agents aus, die diese Sitzung erreichen kann, einschließlich des Namens, unter dem jeder Agent antwortet. Wird der Befehl überhaupt nicht erkannt, unterstützt diese Sitzung keine sitzungsübergreifende Nachrichtenübermittlung. Keine Einstellungsdatei kann das ändern. Geben Sie /status ein und suchen Sie nach einer Zeile mit Peer address. Sie enthält die Inbox-Adresse dieser Sitzung, mit dem Präfix uds:.

Eine Besonderheit betrifft speziell VPS-Benutzer. Die sitzungsübergreifende Nachrichtenübermittlung hängt von der Auswertung von Feature-Flags ab. Mehrere Datenschutzvariablen deaktivieren diese Auswertung. Dadurch bleibt die Funktion standardmäßig deaktiviert. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC und DISABLE_GROWTHBOOK bewirken dies. Viele härten einen neuen Server, indem sie diese Variablen in ~/.bashrc eintragen. Anschließend wundern sie sich, dass /list-agents nicht vorhanden ist. Dieselben Werte können auch aus der env-Map einer Einstellungsdatei oder aus verwalteten Einstellungen stammen. Prüfen Sie daher zuerst die Shell.

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

Heben Sie die gesetzte Variable auf, die einen Wert ausgibt. Bei DISABLE_TELEMETRY und CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC aktiviert jeder nicht leere Wert das Verhalten, einschließlich der Zeichenfolge 0. Daher bewirkt DISABLE_TELEMETRY=0 nicht das, wonach es aussieht. Deaktivieren Sie die Funktion, indem Sie die Variable aufheben oder auf eine leere Zeichenfolge setzen.

Geben Sie Ihren Sitzungen Namen, damit Claude sie adressieren kann

Claude adressiert eine Nachricht anhand des Sitzungsnamens. Legen Sie den Namen beim Start der Sitzung fest:

claude --name builder-api

Sie können den Namen auch mit /rename innerhalb einer laufenden Sitzung festlegen. Wenn Sie keinen Namen festlegen, leitet Claude Code ihn aus dem Namen des Arbeitsverzeichnisses ab, zum Beispiel myapp-3f. Für eine Sitzung ist das ausreichend, bei vier Sitzungen wird es unübersichtlich. Außerdem können zwei Sitzungen denselben Namen erhalten. Die Ausgabe von /list-agents zeigt das Arbeitsverzeichnis jeder lokalen Sitzung. Damit können Sie Sitzungen mit demselben Namen unterscheiden. Die eigene Auflistung von Claude ergänzt die Adresse bei Namenskonflikten um eine kurze Kennung. Eigene Namen zu vergeben ist einfacher, als Kennungen zu lesen.

Ein reproduzierbares tmux-Layout mit zwei Sitzungen

Dies ist eine Builder-Sitzung und eine Reviewer-Sitzung für ein Repository. Der Reviewer arbeitet in einem separaten Git-Worktree. Dadurch schreiben beide nie in dieselbe Datei. git worktree add zusammen mit HEAD erstellt einen getrennten Checkout. Das ist für eine Sitzung geeignet, die liest, statt Commits zu erstellen. Da die beiden Sitzungen unterschiedliche Aufgaben haben, lohnt es sich, dem Reviewer einen eigenen Ausgabestil zu geben. Dadurch ändert sich der System-Prompt dieser Sitzung. Die Vorgabe gilt dann für jeden Turn, statt wie eine einmal eingegebene Anweisung nach und nach an Wirkung zu verlieren.

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 und anschließend w listet die Fenster nach Namen auf. So können Sie eines auswählen. Führen Sie im Builder-Fenster /list-agents aus. Sie sollten reviewer-api mit dem Arbeitsverzeichnis ~/src/api-review sehen. Fehlt es, wurde die Reviewer-Sitzung noch nicht vollständig gestartet, oder eines der beiden Probleme aus dem nächsten Abschnitt liegt vor. Übergeben Sie dann etwas in Klartext:

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

Claude schreibt die Zusammenfassung und sendet sie. Sie schreiben den Nachrichtentext nicht selbst, und der von Claude gesendete Inhalt kann variieren. Im Reviewer-Fenster erscheint die Nachricht mit dem Namen des Absenders im Gespräch. Wenn diese Sitzung untätig ist, startet Claude dort sofort einen neuen Turn. Läuft gerade ein Turn, wartet die Nachricht bis zwischen zwei Tool-Aufrufen. Ein laufender Befehl wird daher nie unterbrochen. Sobald Claude die Nachricht gelesen hat, wird sie zu einer einzeiligen Message from-Zeile reduziert, die Ctrl+O wieder ausklappt. Das Zusammenspiel funktioniert besser, wenn der Builder seine Änderungen klein hält. Ein kleiner Diff führt zu einer kürzeren Übergabe und zu einer Prüfung, die die andere Sitzung in einem Turn abschließen kann. Genau diese Arbeitsweise soll die Fähigkeit eines erfahrenen Entwicklers zur Vermeidung unnötiger Arbeit fördern.

Wer wen auf einem VPS sehen kann

Die Zustellung auf demselben Rechner läuft nie über Anthropic-Server. Jede Sitzung schreibt Registrierungsdateien auf die Festplatte und bindet ihren eigenen Inbox-Socket. Claude Code liest diese Dateien, um Ihre anderen Sitzungen zu finden. Daraus ergeben sich zwei Folgen, die auf einem Server relevant sind.

Der Socket ist auf Ihren Betriebssystembenutzer beschränkt. Eine Sitzung, die Sie als root gestartet haben, und eine Sitzung, die Sie als deploy gestartet haben, können sich nicht gegenseitig sehen. Das gilt auch dann, wenn sie im selben tmux-Server nebeneinander laufen. Die Sitzungen eines Benutzers können nicht auf den Socket eines anderen Benutzers zugreifen. Starten Sie beide Sitzungen als derselbe Benutzer.

Ein Container hat ein eigenes Dateisystem. Eine Sitzung innerhalb von Docker und eine Sitzung auf dem Host können sich nicht erreichen, weil sie nicht dieselben Registrierungsdateien lesen. Zwei Sitzungen innerhalb desselben Containers können sich normal Nachrichten senden. Wenn Sie Agents wie unter Coding-Agents in einer temporären VM ausführen zur Isolation in Containern betreiben, funktioniert die Nachrichtenübermittlung innerhalb eines Containers, aber nicht über die Containergrenze hinweg.

Ihre Sitzungen auf anderen Rechnern und im Web erscheinen nur dann in der Liste, wenn Remote Control verbunden ist. Sie sind entsprechend gekennzeichnet. Claude kann hier nur auf eine Nachricht antworten, die von einer dieser Sitzungen eingegangen ist. Es kann diesen Austausch nicht selbst starten.

Warum Ihre Nachricht nie angekommen ist

Der übliche Grund hat nichts mit dem Netzwerk zu tun. Die empfangende Sitzung hat entschieden, was mit der Nachricht geschehen soll, und sich gegen eine Zustellung entschieden. Jede eingehende Nachricht endet mit einem von drei Ergebnissen: zugestellt, zurückgehalten (bis zu Ihrer Freigabe nicht zugestellt) oder abgelehnt (ohne Zustellung verworfen).

Wenn kein crossSessionInbound-Wert gilt, entscheidet Claude Code für jede Nachricht anhand eines Vergleichs der Berechtigungsmodi der beiden Sitzungen. Sitzungen, die Berechtigungsabfragen umgehen, werden einer Klasse zugeordnet. Alle anderen Sitzungen bilden die zweite Klasse. auto, acceptEdits und dontAsk gelten als Modi mit Abfragen. Der Plan-Modus gilt in einer Sitzung als Umgehen von Abfragen, wenn dort Berechtigungen zum Umgehen verfügbar sind. Wenn Sie nicht sicher sind, welcher Klasse eine Sitzung zugeordnet ist, sollten Sie zuerst nachlesen, was die einzelnen Berechtigungsmodi tatsächlich bewirken, weil die meisten Sitzungen inzwischen mit auto starten und dieser Modus auf der Seite mit Abfragen liegt. Die Regel ist symmetrisch:

• Eine empfangende Sitzung, die Berechtigungen abfragt, stellt jede Nachricht zu. Sie hält eine Nachricht nur zurück, wenn die sendende Sitzung sich als Sitzung ausweist, die Abfragen umgeht.
• Eine empfangende Sitzung, die Abfragen umgeht, hält jede Nachricht zu Ihrer Freigabe zurück. Sie stellt eine Nachricht nur zu, wenn auch der Absender Abfragen umgeht.

Daher funktioniert der erste Workflow, den die meisten Benutzer erstellen, genau nicht. Sie starten einen Builder mit --permission-mode bypassPermissions, damit er unbeaufsichtigt läuft, lassen den Reviewer mit den Standardwerten laufen, und jede Nachricht des Builders wartet in einem Freigabedialog, den niemand beobachtet. Dieser Dialog wird nach Ablauf der Frist dialogExpiry geschlossen. Standardmäßig ist diese auf 5m gesetzt, und die Nachricht wird verworfen. Auf demselben Rechner erhält die sendende Sitzung eine Meldung, wenn ihre Nachricht zurückgehalten wird, sowie eine weitere Meldung, wenn der Empfänger sie später zustellt, ablehnt oder die Frist abläuft. Prüfen Sie daher den Bildschirm des Absenders, bevor Sie den Socket verantwortlich machen.

Damit eine Sitzung Nachrichten unbeaufsichtigt annimmt, setzen Sie crossSessionInbound auf accept. Wo Sie diesen Wert setzen, bestimmt, für welchen Bereich er gilt. Claude Code liest zuerst verwaltete Einstellungen, danach das --settings-Flag und anschließend die Benutzereinstellungen. Es verwendet den ersten gefundenen Wert. Ein Wert in den Projekt- oder lokalen Einstellungen gilt nur, wenn er auf der Rangfolge accept < hold < refuse strenger ist. Ein accept in .claude/settings.json ist weniger restriktiv als jeder andere Wert und wird daher ignoriert, sobald eine vertrauenswürdige Quelle einen Wert gesetzt hat. Tragen Sie den Wert in ~/.claude/settings.json ein oder übergeben Sie ihn für eine einzelne Sitzung:

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

Ein zustandsloser claude -p-Worker bindet wie eine interaktive Sitzung einen Inbox-Socket und erscheint in der Auflistung. Er kann jedoch keinen Freigabedialog anzeigen. Eine dort zurückgehaltene Nachricht bleibt zurückgehalten, bis eine spätere Änderung des Modus oder der Einstellungen ihre Zustellung erlaubt. Mit der obigen Zeile --settings erlauben Sie einem solchen Worker, Nachrichten anzunehmen. Eine im Bare-Modus gestartete Sitzung bindet überhaupt keinen Socket. Sie kann daher weder Nachrichten empfangen noch in der Liste erscheinen.

Wenn Übergaben blockieren

Nachrichten-Schleifen werden für Sie behandelt. Claude Code begrenzt wiederholte Nachrichten pro Absender, verwirft identische Wiederholungen, die innerhalb eines kurzen Zeitraums eintreffen, und begrenzt die Zahl angenommener, noch nicht gelesener Nachrichten pro Sitzung auf 50. Dadurch können zwei Sitzungen nicht unbegrenzt Nachrichten hin und her senden. Es können höchstens 100 Nachrichten zurückgehalten werden. Weitere Nachrichten werden ab diesem Wert nach dem First-in-first-out-Prinzip verworfen.

Der tatsächlich auftretende Fehler ist unauffälliger. Es handelt sich um eine Übergabe und nicht um eine Schleife. Sitzung A stellt Sitzung B eine Frage, deren Antwort sie zum Fortfahren benötigt, und wartet anschließend. B hält die Nachricht zurück, arbeitet gerade lange an einer anderen Aufgabe oder beantwortet eine Frage, die A tatsächlich nicht gestellt hat. A wartet. Eine Stunde später finden Sie zwei untätige Sitzungen vor, ohne dass Arbeit erledigt wurde.

Formulieren Sie Übergaben so, dass keine Antwort erforderlich ist. Eine gute Nachricht enthält eine Tatsache oder eine Entscheidung: was geändert wurde und welches Ergebnis vorliegt. Eine schlechte Nachricht bittet die andere Sitzung um eine Genehmigung oder um eine Antwort, von der der Absender abhängt. Claude ist bereits angewiesen, eine andere Sitzung nie um eine Aktion zu bitten, die deren eigenen Berechtigungseinstellungen blockieren würden, sondern diese Arbeit stattdessen an Sie zurückzugeben. Erweitern Sie diese Regel selbst. Wenn eine Sitzung ohne eine Antwort nicht weiterarbeiten kann, sollten Sie die Antwort geben. Auch eine saubere Kontextverwaltung hilft, weil eine Sitzung, die den Zusammenhang verloren hat, unklare Nachrichten schreibt; Kontext in Claude Code verwalten behandelt diesen Aspekt.

Eingehende Nachrichten als nicht vertrauenswürdige Eingaben behandeln

Claude Code teilt der empfangenden Claude mit, dass die Nachricht aus einer anderen Sitzung stammt und nicht von Ihnen kommt. Außerdem beschränkt es, was diese Nachricht bewirken kann. Diese Durchsetzung erfolgt im Programm, das das Modell umschließt, und nicht durch die Bereitschaft des Modells, Anweisungen zu befolgen. Das ist der praktische Unterschied, den ein Agent-Harness ausmacht. Eine Nachricht kann keine ausstehende Berechtigungsabfrage in Ihrem Namen beantworten, weil die Zustimmung einer anderen Sitzung nicht Ihre Zustimmung ist. Sie kann keine Berechtigungseinstellungen, CLAUDE.md oder andere Konfigurationen ändern, nur weil eine andere Sitzung dies angefordert hat. Ein Slash-Befehl im Text, etwa /compact, kommt als einfacher Text an und wird niemals ausgeführt. Wenn die Verarbeitung der Nachricht eine Berechtigung erfordert, über die die empfangende Sitzung nicht verfügt, sehen Sie dieselbe Abfrage wie bei jeder anderen Aktion. Im Auto-Modus prüft außerdem ein Klassifikator jede Nachricht vor der Zustellung. Eine blockierte Nachricht erreicht den Empfänger nie. Diese Einschränkungen gelten auch in den freizügigen Modi. Deshalb hält eine Sitzung, die diese Einschränkungen umgeht, eingehende Nachrichten standardmäßig zurück, statt ihnen zu vertrauen.

Damit sind die Berechtigungen abgedeckt. Der Inhalt ist davon nicht betroffen. Die sendende Sitzung kann eine Pull-Request-Beschreibung, eine Webseite, eine README-Datei einer Abhängigkeit oder einen von einer fremden Person verfassten Issue-Kommentar gelesen haben. Alles, was sie gelesen hat, kann den Text beeinflussen, den sie an Ihre andere Sitzung schreibt. Die Nachricht ist eine Datenquelle. Sie verdient dasselbe Misstrauen wie jeder andere Text, der von außen in eine Sitzung gelangt ist. Das ist die in Halten Sie Geheimnisse aus Ihren KI-Agenten heraus beschriebene Vorgehensweise: Gehen Sie davon aus, dass alles, was eine Vertrauensgrenze überschritten hat, falsch sein kann, und lassen Sie es sich niemals selbst autorisieren.

Wenn Sie solche Nachrichten reduzieren möchten, stehen zwei Steuerungsmöglichkeiten zur Verfügung. Wenn Sie crossSessionInbound auf refuse setzen, werden eingehende Nachrichten von Peers verworfen, ohne sie zuzustellen. In Projekt- oder lokalen Einstellungen gilt dieser Wert vor allen anderen Quellen, weil er auf der Konfigurationsrangfolge die strengste Einstellung ist. Damit diese Sitzung keine Nachrichten sendet oder auflistet, fügen Sie Berechtigungsregeln zum Verweigern hinzu, die SendMessage und ListAgents nennen. Beide werden als reine Tool-Namen ohne Spezifizierer geschrieben. Wenn Sie isolatePeerMachines auf true setzen, ist Ihre ausdrückliche Zustimmung erforderlich, bevor eine Nachricht eine Sitzung außerhalb dieses Rechners erreicht. Diese Zustimmung ist auch im bypassPermissions-Modus erforderlich.

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

Das Verweigern von SendMessage deaktiviert auch die Nachrichtenübermittlung an Subagenten, weil dasselbe Tool für beide Funktionen verwendet wird. Eine Sitzung, die Nachrichten ablehnt, zeigt in ihrem eigenen /status oder in den Auflistungen anderer Sitzungen keine sichtbare Änderung. Prüfen Sie die Einstellung daher in der Konfiguration der Sitzung und nicht anhand der Bildschirmausgabe.

Bridges und MCP-Server mit gemeinsamem Speicher

Im selben Zeitraum wurden mehrere Projekte von Drittanbietern veröffentlicht, die einen ähnlichen Bereich abdecken: lokale Agent-zu-Agent-Bridges, die Text zwischen laufenden Agents weiterleiten, sowie MCP-Server (Model Context Protocol), die mehreren Agents einen gemeinsamen Speicher zum Lesen und Schreiben bereitstellen. Bewerten Sie diese Lösungen als eine andere Form und nicht als Konkurrenz. Prüfen Sie jeden Installationsbefehl anhand der README des jeweiligen Projekts, bevor Sie ihn ausführen. Messaging arbeitet nach dem Push-Prinzip, weil der Sender Text in den Turn des Empfängers schreibt. Ein gemeinsamer Speicher arbeitet nach dem Pull-Prinzip, weil niemand unterbrochen wird und eine Session den Hinweis erst sieht, wenn sie beim nächsten Mal danach sucht. Pull eignet sich besser für Statusinformationen, die sich langsam ändern. Es funktioniert jedoch nur, wenn eine Session tatsächlich danach sucht.

Wenn Sie diesen Ansatz wählen, sollten sich die Fragen eher auf den Prozess als auf die Funktionsliste beziehen. Unter welchem Benutzer läuft der Server, und auf welche Daten kann er auf dem System zugreifen. MCP-Server auf einem VPS ausführen beschreibt diese Einrichtung. Agent-Fähigkeiten über Repositories hinweg teilen behandelt den einfacheren Fall, in dem Sie zwischen Sessions Anweisungen statt Live-Zustand teilen möchten. Dadurch entfallen viele Nachrichten, die Sie andernfalls senden müssten. Für den größeren Zusammenhang ist einen Coding-Agent auf einem VPS ausführen der richtige Ausgangspunkt.

FAQ

Warum wird /list-agents in meiner Sitzung nicht erkannt?

Die Sitzung unterstützt keine sitzungsübergreifende Kommunikation. Prüfen Sie zuerst claude --version auf 2.1.224, da die Funktion diese Version oder eine neuere benötigt. Prüfen Sie anschließend die Plattform, da die Funktion unter macOS und Linux läuft, aber nicht unter nativem Windows. Außerdem ist sie unter Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform und Microsoft Foundry nicht verfügbar. Wenn beides passt, prüfen Sie Ihre Shell auf DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC oder DISABLE_GROWTHBOOK. Jeder dieser Einträge verhindert die Auswertung des Feature-Flags, von dem die Funktion abhängt, und lässt sie deaktiviert.

Warum ist meine Nachricht an die andere Sitzung nie angekommen?

Wenn /list-agents funktioniert, ist die Kommunikation aktiviert. Dann verhindert eine spezifischere Ursache die Zustellung dieser Nachricht. Die häufigste Ursache sind Berechtigungsmodi. Eine Sitzung, die Berechtigungsabfragen überspringt, hält jede eingehende Nachricht zur Genehmigung zurück, sofern der Absender die Abfragen nicht ebenfalls überspringt. Dieser Genehmigungsdialog wird nach Ablauf von dialogExpiry verworfen. Standardmäßig beträgt diese Frist fünf Minuten. Prüfen Sie in der sendenden Sitzung, ob der Hinweis auf die zurückgehaltene Nachricht angezeigt wird. Setzen Sie zur Behebung crossSessionInbound in ~/.claude/settings.json auf accept oder übergeben Sie den Wert mit --settings. Ein accept in den Projekt- oder lokalen Einstellungen wird ignoriert, weil dieser Wert weniger restriktiv ist.

Kann eine Claude Code-Sitzung in Docker einer Sitzung auf dem Host Nachrichten senden?

Nein. Sitzungen finden einander über Registrierungsdateien auf dem Datenträger und einen Inbox-Socket pro Sitzung. Ein Container verfügt über ein eigenes Dateisystem. Daher können die beiden Sitzungen nicht auf dieselben Dateien zugreifen. Zwei Sitzungen innerhalb desselben Containers können normal miteinander kommunizieren. Dieselbe Regel erklärt, warum eine Sitzung unter root und eine Sitzung unter Ihrem normalen Benutzer einander nicht erreichen können: Der Socket ist auf den Betriebssystembenutzer beschränkt, dem er gehört.

Ist es sicher, auf eine Nachricht von einer anderen Claude Code-Sitzung zu reagieren?

Behandeln Sie den Text als nicht vertrauenswürdige Eingabe. Die sendende Sitzung kann eine Webseite, eine README-Datei oder einen von einer anderen Person verfassten Issue-Kommentar gelesen haben. Claude Code verhindert bereits, dass die Nachricht selbstständig Aktionen ausführt: Sie kann keine ausstehende Berechtigungsabfrage genehmigen, sie kann auf Anforderung weder Berechtigungseinstellungen noch CLAUDE.md ändern, und ein Slash-Befehl im Text kommt als reiner Text an und wird niemals ausgeführt. Diese Schutzmaßnahmen decken Berechtigungen ab, nicht jedoch die Beurteilung des Inhalts. Lesen Sie die eingegangene Nachricht daher, bevor Sie die empfangende Sitzung zum Handeln auffordern.

Werden bei der sitzungsübergreifenden Kommunikation meine Code an Anthropic gesendet?

Nein, wenn sich beide Sitzungen auf demselben Rechner befinden. Die Nachricht wird über einen Socket pro Sitzung auf diesem Rechner übertragen und läuft niemals über Anthropic-Server. Gesendet wird nur der von Claude verfasste Text, niemals der Gesprächsverlauf oder Dateien. Nachrichten an eine Sitzung auf einem anderen Ihrer Rechner oder an eine Sitzung im Web laufen dagegen über die Anthropic-Server und die Remote Control-Verbindung. In diese Richtung kann Claude nur auf eine eingegangene Nachricht antworten, nicht selbst eine Nachricht beginnen. Setzen Sie isolatePeerMachines auf true, um vor jeder Übertragung aus dem Rechner Ihre Genehmigung zu verlangen.