Wer getrennte Netze betreut, kennt den Rhythmus: RDP auf die Management-Maschine der einen Zone, nachsehen, Fenster zu, nächste Zone. Läuft dort jeweils eine Claude-Code-Session, war jede davon bisher eine Insel – was die eine herausfindet, muss man der nächsten selbst erzählen. Genau das ändert sich gerade: Seit Ende August können Claude-Code-Sessions einander Nachrichten schicken – auf derselben Maschine und, mit einer Zutat, sogar über Rechnergrenzen hinweg. Nach Plugins, Begriffsklärung und Praxistest schauen wir uns in dieser Serie also den nächsten Baustein an: Cross-Session Messaging.

Was es ist – und was nicht

Eine Nachricht ist hier genau das, wonach es klingt: ein Stück Text, das ein Claude einem anderen schreibt. Niemals wandert dabei die Konversationshistorie mit, niemals Dateien – nur der Text. Technisch stecken dahinter zwei Werkzeuge: ListAgents findet die erreichbaren Sessions, SendMessage stellt die Nachricht zu. Beides bedient Claude selbst; als Nutzer formuliert man schlicht eine Bitte wie „Sag der Session im anderen Terminal Bescheid, dass die Migration durch ist". Mit @ plus Sessionname lässt sich das Ziel auch direkt im Prompt benennen, und mit /rename bekommen Sessions sprechende Namen wie @sql-migration statt generierter Zufallsnamen.

Wichtig ist die Abgrenzung, denn im Multi-Agent-Umfeld gibt es inzwischen mehrere Mechanismen mit ähnlichem Klang:

Mechanismus Verhältnis Typischer Fall
Subagent Kind der eigenen Session, arbeitet zu Teure Teilaufgabe auslagern – wie unser Prüf-Subagent in der Schreibstube
Agent Team Von einer Session gespawnt und geführt Ein Vorhaben, viele koordinierte Arbeiter
Cross-Session Messaging Unabhängige Sessions, gleichberechtigt Zwei getrennt gestartete Arbeiten tauschen einen Befund aus

Cross-Session Messaging ist also kein Orchestrierungswerkzeug – es ist der kurze Dienstweg zwischen Arbeiten, die unabhängig voneinander laufen. Wer aus der .NET-Welt kommt, kennt das Muster im Kleinen: Der WeakReferenceMessenger aus dem CommunityToolkit.Mvvm lässt lose gekoppelte Komponenten Nachrichten austauschen, ohne dass eine die andere direkt referenziert. Cross-Session Messaging ist derselbe Gedanke eine Etage höher – nur laufen die Beteiligten nicht als ViewModels im selben Prozess, sondern als eigenständige Sessions, notfalls auf verschiedenen Maschinen. Wer die Grundbegriffe Agent und Skill noch sortieren möchte: Wann welche Architektur passt, haben wir bereits ausführlich beschrieben.

Zwei Transportwege – ein entscheidender Unterschied

Wie eine Nachricht reist, hängt davon ab, wo die Ziel-Session läuft – und dieser Unterschied ist für Unternehmen der wichtigste Absatz dieses Artikels:

flowchart LR
  A["Session A<br/><i>Terminal 1</i>"] -->|"Unix-Socket / Named Pipe<br/><i>verlässt die Maschine nie</i>"| B["Session B<br/><i>Terminal 2, gleiche Maschine</i>"]
  A -->|"Anthropic-Server<br/><i>Remote-Control-Verbindung</i>"| C["Session C<br/><i>andere Maschine</i>"]
  style C stroke:#cc171a,stroke-width:2.5px

Auf derselben Maschine läuft die Zustellung über einen lokalen Kanal – unter Linux und macOS ein Unix-Socket, unter Windows eine Named Pipe. Die Nachricht verlässt den Rechner nicht und berührt keine Anthropic-Server. Das funktioniert deshalb auch in Umgebungen ohne claude.ai-Anbindung, etwa mit Amazon Bedrock oder Azure/Foundry.

Über Maschinengrenzen hinweg braucht es dagegen zwei Dinge: Die Nachricht läuft über Anthropic-Server, und beide Seiten müssen per Remote Control verbunden sein – Claude Codes Mechanismus, mit dem man lokale Sessions vom Handy oder Browser aus weiterbedienen kann. Das setzt eine claude.ai-Anmeldung voraus; mit reinem API-Key oder über Bedrock gibt es den Maschinen-übergreifenden Weg nicht. Für die Governance-Bewertung heißt das: Lokaler Nachrichtenverkehr ist unkritisch, rechnerübergreifender ist eine bewusste Entscheidung – dazu gleich mehr.

Das Admin-Szenario: getrennte Netze, ein Überblick

Eines vorweg, weil es bei uns Grundsatz ist: Auf einem Produktivserver läuft kein Agent. Bei uns ist das nicht nur Richtlinie, sondern Netzarchitektur: Unsere Produktivserver haben grundsätzlich keinen Internetzugang – nach draußen sprechen nur die Systeme, deren Aufgabe genau das ist, etwa der Reverse Proxy und der zentrale Update-Server. Ein Agent, dessen Sprachmodell in der Cloud sitzt, könnte auf den übrigen Systemen schlicht nicht arbeiten – kein Netz nach draußen ist am Ende die beste Sandbox, die es gibt. KI-Agenten laufen deshalb auf Management-Maschinen, die den nötigen Zugang haben – und weil die Netze sauber getrennt sind, gibt es davon mehrere: pro Zone eine, mit genau den Zugriffen, die diese Zone braucht. Warum wir Agenten grundsätzlich einhegen, haben wir im Beitrag über Sandboxes für KI-Agenten begründet. Der Preis dieser Trennung war bisher das Fenster-Hopping: RDP zur Management-Maschine der einen Zone, nachsehen, Fenster zu, nächste Zone.

Mit Cross-Session Messaging werden aus den Insel-Sessions ein Verbund, ohne dass die Trennung fällt. Die Session auf der Datenbank-Management-Maschine begleitet die Migration ihrer Zone, die auf der Netz-Management-Maschine wertet Reverse-Proxy-Logs aus – und von der Workstation aus heißt es: „Frag @sql-migration, wie weit sie ist". Die Antwort kommt in das Fenster, in dem man ohnehin arbeitet. Entscheidend dabei: Nachrichten transportieren Text, keine Zugriffe. Die Session der einen Zone kann in der anderen nichts ausführen – sie kann der dortigen Session nur etwas mitteilen, und was daraus wird, entscheiden deren eigene Berechtigungen. Die Netztrennung bleibt, der Erkenntnisfluss kommt dazu.

Laufen mehrere Sessions auf derselben Maschine, gibt es noch ein Extra: Mit notify_when_idle kann eine Session eine andere bitten, sich einmalig zu melden, sobald sie fertig ist. „Sag mir Bescheid, wenn die Migrations-Session durch ist" – kein Polling, kein Nachschauen, die Meldung kommt, wenn es so weit ist. Für lange Wartungsfenster ist das exakt das fehlende Puzzleteil gewesen.

Und wenn eine Session etwas herausfindet, das eine andere betrifft – etwa dass ein Schema-Feld umbenannt wurde, auf das der Log-Parser der Nachbar-Session baut –, kann Claude die Warnung von sich aus hinüberschicken, bevor dort etwas schiefgeht. Genau dafür ist das Feature gedacht: Befunde weitergeben statt Arbeit fernsteuern.

Wie funktioniert das in der Praxis?

Die berechtigte Frage: Was muss ich einrichten? Das hängt wieder daran, ob die Sessions auf einer oder auf mehreren Maschinen laufen.

Auf derselben Maschine: gar nichts. Sobald zwei aktuelle Sessions auf demselben Rechner laufen, sehen sie sich automatisch – kein Befehl, kein Schalter. Der einzige sinnvolle Handgriff ist Kosmetik: Mit /rename gibt man einer Session einen sprechenden Namen, damit man sie als @sql-migration ansprechen kann statt über einen generierten Zufallsnamen. Danach genügt im Prompt eine Bitte im Klartext – „Frag @sql-migration, wie weit sie ist“.

Über Maschinengrenzen: einmal Remote Control einschalten. Damit eine Session eine andere auf einer anderen Maschine erreicht, muss auf beiden Seiten Remote Control aktiv sein. Genau hier kommt /rc ins Spiel: Es ist die Kurzform des Befehls /remote-control und schaltet die Funktion in einer schon laufenden Session ein. Wer lieber gleich damit startet, nimmt claude --rc beim Aufruf; für einen dauerhaft erreichbaren Server gibt es den Modus claude remote-control. Voraussetzung ist eine Anmeldung über claude.ai (Pro, Max, Team oder Enterprise) mit direkter Anbindung an api.anthropic.com – mit reinem API-Schlüssel oder über Bedrock funktioniert Remote Control nicht. Ist beides eingeschaltet, tauchen die Sessions der anderen Maschinen in der Liste auf, und Claude erreicht sie über denselben @name wie eine lokale.

Die ehrliche Kurzfassung fürs Zonen-Szenario: Lokal ist es geschenkt, über Netzgrenzen kostet es genau einen zusätzlichen Schritt pro Maschine – und die bewusste Entscheidung, den Nachrichtenweg über Anthropic-Server zuzulassen.

Windows-Feinheiten, die man kennen sollte

Gerade im Umfeld mit viel Windows lohnt ein Blick auf drei Details:

Sicherheit: Nachrichten sind keine Befehle

Die naheliegende Sorge: Kann eine Session eine andere kapern? Die Architektur ist hier erfreulich konservativ. Eine eingehende Nachricht wird dem empfangenden Claude ausdrücklich als Nachricht einer anderen Session präsentiert, nicht als Nutzereingabe – mit harten Konsequenzen:

Was dagegen ausdrücklich funktioniert, ist die Bitte im Klartext: „Ich kann 8.8.8.8 pingen – kannst du auch?“ Der empfangende Claude liest das als Anfrage, entscheidet nach den Regeln und Berechtigungen seiner eigenen Session, ob er den Ping ausführt, und schickt das Ergebnis zurück. Für getrennte Netze ist genau das der Reiz: verteilte Diagnose aus mehreren Zonen-Perspektiven, ohne dass eine Zone der anderen in die Werkzeuge greift. Der Unterschied ist fein, aber entscheidend – die Nachricht ist nie selbst der Befehl, sie ist eine Bitte, über die die Gegenseite souverän entscheidet. Und eine Grenze gilt auch für den Absender: Was in der eigenen Session verweigert oder blockiert wurde, darf Claude nicht einfach bei einer anderen Session bestellen – solche Arbeit geht zurück an den Menschen.

Dazu kommt Steuerung auf mehreren Ebenen: Pro Session regelt die Einstellung crossSessionInbound, ob eingehende Nachrichten zugestellt (accept), zur manuellen Freigabe zurückgehalten (hold) oder verworfen (refuse) werden. Mit isolatePeerMachines lässt sich erzwingen, dass jede Nachricht, die die Maschine verlassen würde, erst vom Nutzer freizugeben ist. Und Administratoren können das Feature per Managed Settings organisationsweit abschalten – Deny-Regeln für SendMessage und ListAgents plus refuse für eingehende Nachrichten. Wer rechnerübergreifende Nachrichten zulässt, sollte die Entscheidung bewusst treffen: Der Transport läuft über Anthropic-Server, und das gehört wie jede Cloud-Abhängigkeit in die Datenfluss-Dokumentation.

Grenzen: kurzer Dienstweg, kein Fernsteuerpult

Damit keine falschen Erwartungen entstehen: Nachrichten sind bewusst schmal gehalten. Nur Text, mit Größenlimit; schnelle Nachrichtensalven an dieselbe Session werden abgewiesen, Endlosschleifen zwischen zwei Sessions drosselt Claude Code von selbst. Wer eine ganze Konversation samt Kontext weitergeben will, nimmt Session-Resume; wer viele Arbeiter koordinieren will, nimmt Agent Teams; wer externe Ereignisse wie CI-Ergebnisse in eine Session drücken will, nimmt Channels. Cross-Session Messaging füllt die Lücke dazwischen – und genau diese Lücke war im Admin-Alltag bisher mit Copy-and-paste zwischen RDP-Fenstern gefüllt.

Fazit

Cross-Session Messaging ist eines dieser Features, die auf der Release-Notes-Zeile unscheinbar wirken und im Betrieb die Arbeitsweise verändern. Aus isolierten Claude-Code-Inseln wird ein Verbund, der Befunde austauscht, Wartezeiten meldet und Warnungen weiterreicht – lokal ohne Cloud-Berührung, rechnerübergreifend als bewusste Governance-Entscheidung. Besonders interessant ist die Kombination für alle, die mit getrennten Netzen arbeiten: Die Management-Sessions der Zonen behalten ihre Grenzen, tauschen aber endlich Erkenntnisse aus – und die Rückmeldungen kommen von allein.

Sie überlegen, wie KI-Agenten in Ihre Server- und Entwicklungslandschaft passen – mit sauberen Grenzen und nachvollziehbaren Datenflüssen? Auf unserer Seite KI-Agenten für Unternehmen zeigen wir, wie wir bei Konzeption und Umsetzung unterstützen.

Quellen: Anthropic – Cross-Session Messaging (Claude-Code-Doku) · Anthropic – Remote Control (Claude-Code-Doku)