Viele glauben, dass parallele Arbeit mit mehreren Claude-Code-Sitzungen immer manuelles Hin- und Herkopieren von Kontext bedeutet. Die neueste Funktion der Dokumentation zeigt einen anderen Weg: Claude kann selbstständig Nachrichten zwischen deinen unabhängigen Sitzungen übermitteln, ohne dass du einen einzigen Befehl tippst.
Diese Funktion nennt sich Cross-Session Messaging. Sie macht aus deinen getrennten Arbeitsumgebungen ein lose gekoppeltes Team, das sich gegenseitig auf dem Laufenden hält. Wir schauen uns an, wie das funktioniert, wann es sinnvoll ist und wo die Grenzen liegen – und warum du die Werkzeuge dafür vielleicht nie selbst in die Hand nehmen musst.
Wie die Sitzungen miteinander sprechen: ListAgents und SendMessage
Die Grundlage bilden zwei interne Werkzeuge, die Claude innerhalb einer Sitzung zur Verfügung stehen. Mit ListAgents erkennt Claude, welche anderen Sitzungen er gerade erreichen kann. Mit SendMessage schickt er einer dieser Sitzungen eine Textnachricht. Du selbst rufst diese Tools nie direkt auf – Claude entscheidet selbst, wann es nötig ist.
Die Nachricht selbst ist reiner Text. Sie enthält weder den Chatverlauf noch Dateien aus der sendenden Sitzung. Wenn du einen ganzen Kontext übertragen willst, musst du stattdessen die Sitzung per resume weiterführen – die Messaging-Funktion ist für kleine, präzise Informationen gedacht, nicht für den Umzug eines ganzen Workspace.
Wenn du mehrere Sitzungen parallel laufen lässt, etwa in verschiedenen Worktrees desselben Repositories, wird es interessant. Ein Kollege – die eine Sitzung – macht eine Änderung, die eine andere betrifft. Statt dass du nach dem Kaffee zurückkommst und vor einem kaputten Build stehst, kann Claude die andere Sitzung proaktiv warnen. Genau dafür ist die Funktion gemacht.
Wann lohnt sich der Austausch? Typische Szenarien im Alltag
Die Dokumentation nennt vier klare Fälle, in denen die Nachrichtenübermittlung den Arbeitsfluss verbessert. Erstens die Übergabe eines Befunds: Entdeckt eine Sitzung eine breaking change oder trifft eine Entscheidung, fasst Claude das für die betroffene Sitzung zusammen. Du musst es nicht doppelt erklären.
Zweitens die Koordination paralleler Worktrees. Arbeiten mehrere Sitzungen am selben Repository, kann Claude den anderen mitteilen, was gerade „gelandet“ ist. Das vermeidet Konflikte und hält alle auf demselben Stand.
Drittens der Status lang laufender Prozesse. Eine Migration oder ein Testlauf läuft im Hintergrund, und du sitzt in einer anderen Sitzung und wartest. Claude kann dir den Status direkt übermitteln – ohne dass du die Logs selbst verfolgst. Und viertens die Kommunikation über Maschinen hinweg: Antworten auf Nachrichten, die von einer Sitzung auf einem anderen Rechner oder im Web kamen, können hier beantwortet werden – aber nur Antworten, keinen neuen Austausch starten.
Diese Beispiele zeigen, dass es nicht um endlose Konversationen zwischen Agenten geht, sondern um gezielte, informative Stupser. Wie wenn zwei Kollegen im Großraumbüro sich über eine Notiz auf dem Tisch informieren – nicht wie eine Telefonkonferenz
Zustellung und Timing: Wie eine Nachricht ankommt
Die Zustellung erfolgt nach einem klaren Prinzip: Die empfangende Sitzung liest die Nachricht zwischen zwei Werkzeugaufrufen während eines aktiven Turns. Das bedeutet, ein laufendes Tool wird nie unterbrochen. Ist die Sitzung gerade idle, startet Claude Code einen neuen Turn, um die Nachricht zu verarbeiten.
Zwischen zwei gewöhnlichen interaktiven Sitzungen funktioniert das in der Standardkonfiguration zuverlässig. Aber es gibt keine Garantie. Die empfangende Sitzung prüft jede ankommende Nachricht gegen ihre eigenen Eingangsregeln – und das führt zu drei möglichen Ergebnissen: Delivered, Held oder Refused. Bei Held wird die Nachricht beiseitegelegt und erst zugestellt, wenn du sie genehmigst oder eine spätere Einstellungsänderung es erlaubt. Refused bedeutet, dass sie verworfen wird.
Eine zugestellte Nachricht zählt wie ein normaler Prompt, den du selbst getippt hast – sie verbraucht also Kontext und Token. Und die empfangende Claude kann auf demselben Weg zurückschreiben, außer in dem einseitigen Fall der maschinenübergreifenden Antwort.
Du kannst die Liste der erreichbaren Sitzungen auch selbst sehen. Der Befehl /list-agents zeigt dir alle Subagenten, deine lokalen Sitzungen und – bei aktiver Remote Control – auch Sitzungen auf anderen Geräten. Damit kannst du nachvollziehen, wen Claude erreichen kann, bevor du eine Nachricht anstößt.
Sicherheitsgrenzen: Was eine Nachricht nicht kann
Damit das System nicht ausufert, gibt es bewusste Einschränkungen, die in der Dokumentation klar benannt werden. Eine Nachricht von einer anderen Sitzung zählt niemals als deine Zustimmung. Das heißt, sie kann keinen offenen Permission-Prompt beantworten. Außerdem darf sie keine Konfigurationsänderungen vornehmen – weder die CLAUDE.md noch andere Einstellungen lassen sich durch eine fremde Nachricht verändern.
Selbst Befehle wie /compact werden nicht ausgeführt, wenn sie im Text einer Nachricht stehen – sie bleiben reiner Text. Und wenn die Aktion, die in der Nachricht angefragt wird, eine Berechtigung benötigt, die die empfangende Sitzung nicht hat, erscheint derselbe Permission-Prompt wie bei jeder anderen Aktion auch.
Diese Regeln schaffen Vertrauen. Du kannst sicher sein, dass keine Sitzung heimlich etwas tut, was du nicht explizit erlaubt hast. Die Kommunikation zwischen Agenten ist niemals eine Hintertür – sie ist ein ergänzender Kanal, der deine eigenen Rechte nicht umgeht.
Besonders wichtig ist der Punkt, dass eine Sitzung nie versuchen darf, eine Handlung zu veranlassen, die in ihrer eigenen Umgebung blockiert wäre. Claude wird instruiert, solche Arbeiten an dich zurückzugeben – nicht an eine andere Sitzung zu delegieren.
Eingangskontrolle selbst bestimmen: Die Option crossSessionInbound
Du entscheidest, wie deine Sitzungen mit eingehenden Nachrichten umgehen. Die Einstellung crossSessionInbound bietet dir drei Werte: accept stellt alle Nachrichten zu, hold zeigt dir zunächst eine Notiz und legt die Nachricht beiseite, bis du sie freigibst, und refuse verwirft sie sofort.
Ohne dass du eine explizite Einstellung setzt, greift eine Standardlogik, die sich nach den Permission-Modi der beiden beteiligten Sitzungen richtet. Sitzungen, die normalerweise Berechtigungen nachfragen, erhalten Nachrichten automatisch. Sitzungen, die in einem Modus laufen, der Prompt-Bestätigungen überspringt (wie acceptEdits oder dontAsk), werden als „bypassing“ eingestuft – und Nachrichten an sie wirst du vorgelegt, es sei denn, beide umgehen die Berechtigungen.
In der Praxis bedeutet das: Hast du eine Sitzung im „Auto-Pilot“-Modus, hält Claude Code Nachrichten zurück, bis du sie genehmigst. Das gibt dir Kontrolle, ohne die Automatisierung zu kappen. Und falls eine Nachricht einmal abgelehnt wird, erscheint auf der Senderseite eine Benachrichtigung über das Ergebnis – so bleibt der Austausch transparent.
Wichtig ist auch, dass es ein Limit von 100 gehaltenen Nachrichten gibt. Wenn das Limit erreicht wird, verfallen die ältesten. Das System ist also robust, aber nicht unendlich
Maschinenübergreifend: Eine Reise durch die Server
Die Kommunikation zwischen Sitzungen auf demselben Rechner läuft über einen lokalen Socket – kein Datenverkehr verlässt deine Maschine. Das ist schnell und privat. Sobald du jedoch Sitzungen auf verschiedenen Maschinen vernetzen willst, geht der Weg über die Server von Anthropic. Das funktioniert nur, wenn die entfernte Sitzung über Remote Control erreichbar ist.
Interessant ist die Einschränkung: Von einer anderen Maschine kannst du nur auf Nachrichten antworten, die von dort zuerst kamen. Du kannst keine neue Konversation von hier nach dort initiieren. Das verhindert, dass eine Zombie-Sitzung auf deinem lokalen Rechner plötzlich aktiv wird und eine Remote-Sitzung anstößt.
Für Container gibt es eine eigene Besonderheit: Da ein Container ein eigenes Dateisystem hat, sieht er Sitzungen auf dem Host nicht – und umgekehrt. Aber zwei Sitzungen im selben Container können problemlos kommunizieren. Das ist wichtig für alle, die Claude Code in Docker-Umgebungen nutzen.
Cross-Session Messaging ist kein Ersatz für die bestehenden Werkzeuge wie Agent-Teams oder Remote Control, sondern eine Ergänzung für den speziellen Fall, dass du mehrere unabhängige Sitzungen unter deiner Obhut hast. Es reduziert manuelle Übertragungsarbeit, schafft aber keine neue Hierarchie. Die Sitzungen bleiben eigenständig, du bleibst der Boss.
Quelle: code.claude.com
