Claude Code: Sitzungen per Nachricht verbinden

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 Textabschnitt, den eine Claude-Sitzung für eine andere schreibt. Sie enthält keinen Gesprächsverlauf und keine Dateien. Claude findet die andere Sitzung mit dem Tool ListAgents und übermittelt den Text mit SendMessage. Sie müssen keines der beiden Tools manuell aufrufen. Sie geben an, was die andere Sitzung wissen muss, und Claude verfasst die Nachricht selbst.

Diese Funktion heißt sitzungsübergreifende Nachrichtenübermittlung. Seit August 2026 wird dafür Claude Code v2.1.224 oder höher benötigt. Die Funktion 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 sie 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 die Nachrichtenübermittlung bereits aktiviert. Es gibt nichts weiter zu konfigurieren. Das unten beschriebene Verhalten stammt aus der Anthropic-Dokumentation zur sitzungsübergreifenden Nachrichtenübermittlung.

Auf einem VPS ist diese Funktion besonders relevant, weil Sitzungen dort lange genug laufen, damit Nachrichten an sie sinnvoll sind. 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 immer. Sie enthält weiterhin den Kontext eines Repositorys. Sobald zwei solche Sitzungen vorhanden sind, ist die Frage ihrer Kommunikation nicht mehr theoretisch. Wenn Sie das noch nicht eingerichtet haben, beginnen Sie mit Claude Code auf einem VPS unter tmux ausführen. Dort wird die Sitzungsverwaltung beschrieben, die dieser Leitfaden voraussetzt.

Wann sich eine zweite Sitzung lohnt

Beginnen Sie mit den Kosten. Jede Sitzung ist eine separate Claude-Instanz mit einem eigenen Kontextfenster. Zwei Sitzungen kosten über denselben Zeitraum ungefähr doppelt so viel wie eine Sitzung. Eine zugestellte Nachricht wird bei der Nutzung genauso gezählt wie eine von Ihnen eingegebene Eingabe. Die Koordination ist nicht kostenlos. Arbeit, die eigentlich aus einer Abfolge von Schritten besteht, wird langsamer und teurer, wenn Sie sie auf mehrere Sitzungen verteilen.

Die Fälle, in denen sich eine zweite Sitzung amortisiert, haben eine gemeinsame Struktur. Zwei Arbeitsabschnitte laufen gleichzeitig, ohne aufeinander zu warten. Einer davon ermittelt während der Ausführung Informationen, die der andere benötigt.

• Eine Sitzung findet eine inkompatible Änderung, während die andere auf dem dadurch beschädigten Code aufbaut. Claude fasst die Änderung zusammen und übermittelt sie, anstatt dass Sie sie im anderen Terminal erneut eingeben.
• 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 überwachen.
• Eine Builder-Sitzung und eine Reviewer-Sitzung: Die Reviewer-Sitzung liest die von der Builder-Sitzung erzeugten Ergebnisse und übermittelt ihre Feststellungen.

Bei sequenzieller Arbeit oder wenn beide Sitzungen dieselben Dateien bearbeiten würden, verwenden Sie eine Sitzung. Wenn Sie eine koordinierte Gruppe möchten, 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 verwenden möchten, 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 das Feature vorhanden ist, bevor Sie darauf aufbauen

Prüfen Sie zuerst die Version:

claude --version

Vergleichen Sie die Versionsnummer mit 2.1.224. Geben Sie dann innerhalb einer Sitzung /list-agents ein. Der Befehl kann auch mit /peers aufgerufen werden. 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. Das lässt sich durch keine Einstellungsdatei ändern. Geben Sie /status ein und suchen Sie nach einer Zeile mit Peer address. Sie enthält die Inbox-Adresse dieser Sitzung, der uds: vorangestellt ist.

Ein Problem betrifft insbesondere VPS-Benutzer. Die sitzungsübergreifende Nachrichtenübermittlung hängt von der Auswertung von Feature-Flags ab. Mehrere Datenschutzvariablen deaktivieren diese Auswertung. Dadurch bleibt das Feature 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, warum /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 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, was es scheinbar bewirkt. Deaktivieren Sie das Verhalten, indem Sie die Variable aufheben oder auf eine leere Zeichenfolge setzen.

Benennen Sie Ihre Sitzungen, damit Claude sie adressieren kann

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

claude --name builder-api

Sie können den Namen auch innerhalb einer laufenden Sitzung mit /rename festlegen. Wenn Sie keinen Namen festlegen, leitet Claude Code ihn aus dem Namen des Arbeitsverzeichnisses ab, beispielsweise myapp-3f. Das ist für eine Sitzung unproblematisch, wird bei vier Sitzungen jedoch unübersichtlich. Außerdem können zwei Sitzungen denselben Namen erhalten. Die Ausgabe von /list-agents zeigt das Arbeitsverzeichnis jeder lokalen Sitzung. Dadurch lassen sich Sitzungen mit demselben Namen unterscheiden. Die eigene Liste von Claude ergänzt die Adresse bei Namenskonflikten um einen kurzen Bezeichner. Die Sitzungen selbst zu benennen ist weniger aufwendig, als Bezeichner zu prüfen.

Ein reproduzierbares tmux-Layout mit zwei Sitzungen

Dies ist eine Builder-Sitzung und eine Reviewer-Sitzung für dasselbe Repository. Der Reviewer arbeitet in einem separaten git worktree, sodass die beiden Sitzungen niemals in dieselbe Datei schreiben. git worktree add zusammen mit HEAD erstellt einen detached Checkout. Das ist für eine Sitzung geeignet, die liest, aber keine Commits erstellt.

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, sodass Sie eines auswählen können. 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 entweder 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 variiert. Im Reviewer-Fenster erscheint die Nachricht mit dem Namen des Absenders in der Unterhaltung. Ist diese Sitzung inaktiv, startet Claude dort sofort einen neuen Turn. Läuft gerade ein Turn, wartet die Nachricht bis zwischen zwei Tool-Aufrufen. Ein laufender Befehl wird dadurch niemals unterbrochen. Sobald Claude die Nachricht gelesen hat, wird sie zu einer einzeiligen Message from-Zeile eingeklappt, die Ctrl+O erweitert. Das Zusammenspiel funktioniert besser, wenn der Builder seine Änderungen klein hält. Ein kleiner Diff führt zu einer kürzeren Übergabe und einer Review, die die andere Sitzung in einem Turn abschließen kann. Genau diese Gewohnheit soll die Fähigkeit eines erfahrenen Entwicklers zur Vermeidung unnötiger Arbeit fördern.

Wer kann wen auf einem VPS sehen?

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 Konsequenzen. Beide sind auf einem Server relevant.

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 einander nicht sehen. Das gilt auch dann, wenn sie nebeneinander im selben tmux-Server laufen. Die Sitzungen eines Benutzers können den Socket eines anderen Benutzers nicht erreichen. Starten Sie beide Sitzungen als derselbe Benutzer.

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

Ihre Sitzungen auf anderen Rechnern und im Web erscheinen nur in der Liste, solange Remote Control verbunden ist. Sie sind entsprechend gekennzeichnet. Claude kann hier nur auf eine Nachricht antworten, die von einer dieser Sitzungen eingegangen ist. Den Austausch selbst kann Claude nicht 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 die Zustellung entschieden. Jede eingehende Nachricht endet mit einem von drei Ergebnissen: zugestellt, zurückgehalten (bis zu Ihrer Freigabe nicht zugestellt) oder abgewiesen (ohne Zustellung verworfen).

Wenn kein crossSessionInbound-Wert gilt, entscheidet Claude Code für jede Nachricht anhand des Berechtigungsmodus der beiden Sitzungen. Sitzungen, die Berechtigungsabfragen umgehen, werden einer Klasse zugeordnet. Alle anderen Sitzungen gehören zur anderen Klasse. auto, acceptEdits und dontAsk zählen als Abfragemodi. Der Planmodus zählt in einer Sitzung als Umgehen, wenn für diese Sitzung Umgehungsberechtigungen verfügbar sind. 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 angibt, dass sie Berechtigungsabfragen umgeht.
• Eine empfangende Sitzung, die Berechtigungsabfragen umgeht, hält jede Nachricht zur Genehmigung zurück. Sie stellt eine Nachricht nur zu, wenn auch der Absender Berechtigungsabfragen umgeht.

Daher ist der erste Workflow, den die meisten Benutzer einrichten, genau der, der nicht funktioniert. Sie starten einen Builder mit --permission-mode bypassPermissions, weil er unbeaufsichtigt laufen soll, lassen den Reviewer mit den Standardeinstellungen laufen, und jede Nachricht des Builders wartet in einem Genehmigungsdialog, den niemand beobachtet. Dieser Dialog wird nach Ablauf der Frist dialogExpiry geschlossen. Der Standardwert ist 5m. Danach wird die Nachricht 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 verdächtigen.

Damit eine Sitzung Nachrichten unbeaufsichtigt annimmt, setzen Sie crossSessionInbound auf accept. Wo Sie diesen Wert setzen, bestimmt seinen Geltungsbereich. Claude Code liest zuerst verwaltete Einstellungen, danach das --settings-Flag und anschließend die Benutzereinstellungen. Dabei wird der erste gefundene Wert angewendet. Ein Wert in den Projekt- oder lokalen Einstellungen gilt nur, wenn er auf der Stufenfolge accept < hold < refuse strenger ist. Ein accept in .claude/settings.json ist weniger streng als jeder andere Wert. Deshalb wird er ignoriert, sobald eine vertrauenswürdige Quelle einen Wert festgelegt hat. Tragen Sie ihn 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 Genehmigungsdialog anzeigen. Eine dort zurückgehaltene Nachricht bleibt zurückgehalten, bis ein späterer Modus oder eine Einstellungsänderung ihre Annahme erlaubt. Die obige Zeile --settings ermöglicht es einem solchen Worker, Nachrichten anzunehmen. Eine Sitzung, die im Bare-Modus gestartet wurde, bindet überhaupt keinen Socket. Sie kann daher weder Nachrichten empfangen noch in der Liste erscheinen.

Wenn Übergaben blockieren

Nachrichtenschleifen werden für Sie behandelt. Claude Code begrenzt wiederholte Nachrichten pro Absender, verwirft identische Wiederholungen, die innerhalb eines kurzen Zeitfensters 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. Zurückgehaltene Nachrichten sind auf 100 begrenzt; darüber hinaus werden die ältesten 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 A benötigt, bevor A fortfahren kann, und wechselt dann in den Leerlauf. B hält die Nachricht zurück, befindet sich gerade in einer langen Verarbeitung oder beantwortet eine Frage, die A nicht wirklich gestellt hat. A wartet. Eine Stunde später finden Sie zwei Sitzungen im Leerlauf 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ängig ist. Claude ist bereits angewiesen, eine andere Sitzung niemals um eine Aktion zu bitten, die deren eigene Berechtigungseinstellungen blockieren würden, sondern diese Arbeit stattdessen an Sie zurückzugeben. Erweitern Sie diese Regel selbst. Wenn eine Sitzung ohne eine Antwort nicht fortfahren kann, sollten Sie die Antwort geben. Auch eine disziplinierte Kontextverwaltung hilft dabei, weil eine Sitzung, die den Zusammenhang verloren hat, unklare Nachrichten schreibt; Kontextverwaltung in Claude Code 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 wird eingeschränkt, was diese Nachricht bewirken kann. Eine Nachricht kann keine ausstehende Berechtigungsabfrage in Ihrem Namen beantworten, weil die Zustimmung aus 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, beispielsweise /compact, kommt als reiner Text an und wird niemals ausgeführt. Wenn für die Verarbeitung der Nachricht eine Berechtigung erforderlich ist, über die die empfangende Sitzung nicht verfügt, sehen Sie dieselbe Abfrage wie bei jeder anderen Arbeit. Im automatischen Modus prüft ein Klassifikator außerdem jede Nachricht vor der Zustellung. Eine Nachricht, die er blockiert, erreicht den Empfänger nicht. Diese Einschränkungen gelten auch in den freizügigen Modi. Deshalb hält eine Sitzung im Bypass-Modus 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 Datenübertragung. Sie verdient dasselbe Misstrauen wie jeder andere Text, der von außerhalb in eine Sitzung gelangt ist. Dies ist die in Geheimnisse aus Ihren KI-Agenten heraushalten beschriebene Vorgehensweise: Gehen Sie davon aus, dass alles, was eine Vertrauensgrenze überschritten hat, falsch sein kann. Lassen Sie es niemals sich selbst autorisieren.

Wenn Sie dies einschränken möchten, stehen zwei Steuerungsmöglichkeiten zur Verfügung. Wenn Sie crossSessionInbound auf refuse setzen, werden eingehende Peer-Nachrichten verworfen, ohne sie zuzustellen. In Projekt- oder lokalen Einstellungen gilt dieser Wert gegenüber jeder anderen Quelle, weil er auf der strengsten Stufe der Rangfolge steht. Um das Senden oder Auflisten durch diese Sitzung zu verhindern, 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 Computers erreicht. Diese Zustimmung ist auch im bypassPermissions-Modus erforderlich.

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

Wenn Sie SendMessage verweigern, wird auch die Nachrichtenübermittlung an Subagenten deaktiviert, da für beides dasselbe Tool verwendet wird. Eine Sitzung, die Nachrichten ablehnt, zeigt in ihrem eigenen /status und in den Auflistungen anderer Sitzungen keine sichtbare Änderung. Prüfen Sie die Einstellung daher in der Sitzungskonfiguration und nicht anhand der Bildschirmanzeige.

Bridges und MCP-Server mit gemeinsamem Speicher

Im selben Zeitraum wurden mehrere Drittanbieterprojekte veröffentlicht, die einen verwandten Anwendungsfall abdecken: lokale Agent-zu-Agent-Bridges, die Text zwischen laufenden Agents weiterleiten, sowie MCP-Server (Model Context Protocol), über die mehrere Agents einen gemeinsamen Speicher lesen und beschreiben können. Betrachten Sie diese Lösungen als eine andere Ausprägung und nicht als Konkurrenz. Prüfen Sie jeden Installationsbefehl anhand der README des jeweiligen Projekts, bevor Sie ihn ausführen. Messaging erfolgt per Push, weil der Sender Text in den Turn des Empfängers einfügt. Ein gemeinsamer Speicher arbeitet per Pull, weil niemand unterbrochen wird und eine Sitzung die Notiz erst sieht, wenn sie beim nächsten Zugriff danach sucht. Pull eignet sich besser für Statusinformationen, die sich langsam ändern. Es funktioniert jedoch nur, wenn eine Sitzung tatsächlich danach sucht.

Wenn Sie diesen Ansatz wählen, sollten sich die Fragen auf den Prozess und nicht auf die Funktionsliste konzentrieren. Unter welchem Benutzer läuft der Server, und auf welche Dateien kann er auf dem System zugreifen? MCP-Server auf einem VPS betreiben behandelt diese Einrichtung. Agent-Skills über Repositories hinweg gemeinsam nutzen behandelt den einfacheren Fall, in dem Sie zwischen Sitzungen Anweisungen statt eines Live-Status gemeinsam nutzen 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 betreiben der richtige Ausgangspunkt.

FAQ

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

Die Sitzung unterstützt keine sitzungsübergreifende Nachrichtenübermittlung. Prüfen Sie zuerst claude --version gegen 2.1.224, da die Funktion diese Version oder eine spätere benötigt. Prüfen Sie anschließend die Plattform, da die Funktion unter macOS und Linux, aber nicht unter nativem Windows läuft. 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 Faktoren 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 Nachrichtenübermittlung aktiviert, und etwas Spezifischeres hat diese Nachricht blockiert. Die häufigste Ursache sind Berechtigungsmodi. Eine Sitzung, die Berechtigungsabfragen umgeht, hält jede eingehende Nachricht zur Genehmigung zurück, sofern der Absender die Abfragen nicht ebenfalls umgeht. Dieser Genehmigungsdialog wird nach Ablauf von dialogExpiry verworfen, standardmäßig nach fünf Minuten. Prüfen Sie die sendende Sitzung auf den Hinweis zur zurückgehaltenen Nachricht. Setzen Sie zur Behebung crossSessionInbound in ~/.claude/settings.json auf accept oder übergeben Sie den Wert mit --settings, da ein accept in den Projekt- oder lokalen Einstellungen als weniger restriktiver Wert ignoriert wird.

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

Nein. Sitzungen finden einander über Registrierungsdateien auf dem Datenträger und einen Socket für den Posteingang der jeweiligen Sitzung. Ein Container hat jedoch ein eigenes Dateisystem, sodass die beiden Sitzungen nicht auf dieselben Dateien zugreifen können. Zwei Sitzungen innerhalb desselben Containers können sich normal Nachrichten senden. Dieselbe Regel erklärt, warum eine Sitzung unter root und eine Sitzung unter Ihrem normalen Benutzerkonto einander nicht erreichen können: Der Socket ist auf den Betriebssystembenutzer beschränkt, dem er gehört.

Ist eine Nachricht aus einer anderen Claude Code-Sitzung sicher ausführbar?

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

Sendet die sitzungsübergreifende Nachrichtenübermittlung meinen Code an Anthropic?

Zwischen zwei Sitzungen auf demselben Computer: nein. Die Nachricht wird über einen Sitzungssocket auf diesem Computer übertragen und läuft nie über Anthropic-Server. Außerdem wird nur der von Claude geschriebene Text gesendet, niemals der Gesprächsverlauf oder Dateien. Nachrichten an eine Sitzung auf einem anderen Ihrer Computer oder an eine Sitzung im Web laufen dagegen über die Anthropic-Server und die Remote Control-Verbindung. In dieser Richtung kann Claude nur auf eine eingegangene Nachricht antworten, aber keine Nachricht initiieren. Setzen Sie isolatePeerMachines auf true, damit Sie vor dem Verlassen des Computers jede Übertragung genehmigen müssen.