Eine Sitzung sendet nichts an die andere, oder beide Agenten bearbeiten dieselbe Datei: Starten Sie nicht sofort mit mehreren Maschinen, sondern testen Sie die Kommunikation zuerst auf macOS oder Linux in getrennten Git-worktrees.

Die schnellste belastbare Lösung lautet: Version prüfen, zwei Sitzungen eindeutig benennen, mit einer kurzen Statusnachricht über SendMessage testen und erst nach erfolgreicher Kontrolle auf Remote- oder Cross-Machine-Szenarien erweitern. Die Nachrichten übertragen Status, technische Entscheidungen und Blocker – nicht das vollständige Gedächtnis, Dateien oder zusätzliche Berechtigungen.

Letzte Aktualisierung: 12.08.2026. Versions- und Funktionsangaben wurden anhand der offiziellen Claude-Code-Dokumentation und des offiziellen Release-Verlaufs geprüft.

Zielgruppe und Entscheidungspunkt

Diese Anleitung richtet sich an Sie, wenn Sie mehrere Claude-Code-Terminals parallel geöffnet haben und den Fortschritt nicht länger manuell zwischen ihnen kopieren möchten. Sie ist außerdem für Teams gedacht, in denen Frontend-, Backend- und Test-Agenten getrennt arbeiten sollen, sowie für Plattformingenieure, die Sitzungen auf einem Remote Mac oder in einer dauerhaft laufenden Entwicklungsumgebung betreiben.

Nicht jeder parallele Prozess braucht sitzungsübergreifende Kommunikation. Wenn eine Aufgabe streng linear verläuft, ständig dieselbe Datei verändert oder nur ein Ergebnis zurückmelden muss, ist ein einzelner Agent mit Sub-Agenten oft einfacher. Agent Teams sind für unabhängige Arbeit mit direktem Austausch gedacht, verursachen aber zusätzlichen Koordinationsaufwand und höheren Tokenverbrauch. Die offizielle Gegenüberstellung von Agent Teams und Sub-Agenten beschreibt diese Unterschiede ausführlich.

Einsatzgrenzen vor dem ersten Start

Der wichtigste Denkfehler ist die Gleichsetzung von Nachrichtenaustausch und gemeinsamem Kontext. Eine Nachricht wie „Das Backend verwendet jetzt account_id statt user_id“ informiert die andere Sitzung über eine Entscheidung. Sie überträgt jedoch nicht automatisch alle bisherigen Überlegungen, geänderten Dateien oder offenen Annahmen.

Für Ihre Planung ergeben sich mindestens vier Grenzen:

  • Kein gemeinsames Gedächtnis: Jede unabhängige Sitzung besitzt ihr eigenes Kontextfenster. Die Historie des ersten Terminals wird nicht automatisch in das zweite übertragen.
  • Keine Dateisynchronisation: Änderungen gelangen über Git, einen Patch, einen Pull Request oder andere Versionskontrollabläufe in den Arbeitsstand. SendMessage ersetzt weder Commit noch Review.
  • Keine Berechtigungsvergabe: Eine eingehende Nachricht darf nicht als Genehmigung für Shell-Befehle, Dateiänderungen, Konfigurationsänderungen oder Deployments behandelt werden.
  • Topologieabhängigkeit: Zwei Sitzungen auf derselben Maschine können einen anderen Kommunikationsweg verwenden als eine Sitzung auf einem lokalen Rechner und eine zweite auf einem entfernten System.
  • Zusätzliche Fehlerquelle: Eine Sitzung kann beendet, pausiert, umbenannt oder nicht erreichbar sein. Eine Nachricht mit dem falschen Sitzungsnamen ist dann nicht automatisch erfolgreich zugestellt.

Die offizielle Sicherheitsdokumentation stellt klar, dass Claude Code nur die Berechtigungen besitzt, die Sie gewähren. Insbesondere Dateischreibzugriffe und Shell-Befehle bleiben von der Nachrichtenschicht getrennte Entscheidungen. Prüfen Sie deshalb vor dem Parallelbetrieb die Sicherheitsgrundlagen von Claude Code.

Voraussetzungen und Versionsprüfung

Der von Ihnen vorgegebene Release-Verlauf ordnet die Einführung der Funktion drei Ständen zu: Claude Code v2.1.224 führte SendMessage und ListAgents für sitzungsübergreifende Kommunikation ein, v2.1.225 ergänzte die Cross-Machine-Kommunikation und Korrekturen für unbeaufsichtigte Nachrichtenverarbeitung; v2.1.227 ist am 11.08.2026 der aktuelle geprüfte Release-Stand. Prüfen Sie die konkrete Buildnummer dennoch lokal mit:

claude --version

Die offizielle Release-Übersicht ist für die Versionskontrolle maßgeblich. Ein automatisches Update ist kein Beweis dafür, dass alle Terminalprozesse bereits auf derselben Version laufen: Bereits gestartete Sitzungen müssen Sie nach einem Update in der Regel neu öffnen.

Für den beschriebenen Kommunikationspfad sollten Sie diese Bedingungen abarbeiten:

  1. Verwenden Sie macOS oder Linux als primäre Testplattform.
  2. Aktualisieren Sie beide Sitzungen auf eine kompatible Version.
  3. Melden Sie beide Sitzungen über denselben vorgesehenen Bereitstellungskanal an.
  4. Prüfen Sie, ob die experimentellen oder organisationsweiten Einschränkungen die Funktion ausblenden.
  5. Verwenden Sie zunächst keine vertraulichen Projektdaten in der Testnachricht.
  6. Dokumentieren Sie Sitzungsname, Arbeitsverzeichnis, Host und Startzeit.

Claude Code selbst unterstützt weitere Installationswege und Windows-Szenarien, darunter WSL und Git for Windows. Für den hier behandelten Cross-Session-Pfad sollten Sie native Windows-Umgebungen jedoch nicht als gleichwertige Ausgangsbasis behandeln, solange die Funktionsdokumentation macOS und Linux als unterstützte Plattformen ausweist. Die offizielle Einrichtungsdokumentation nennt die allgemeinen Systemvoraussetzungen und die verfügbaren Installationsvarianten.

Erste 15 Minuten: Zwei Sitzungen sichtbar machen

Starten Sie zunächst zwei interaktive Sitzungen auf derselben macOS- oder Linux-Maschine. Öffnen Sie dafür zwei Terminalfenster oder zwei klar getrennte Multiplexer-Panes. Vermeiden Sie Namen wie „Claude 1“ und „Claude 2“. Verwenden Sie stattdessen Rollen und Arbeitsbereiche, zum Beispiel:

  • frontend-api-contract
  • backend-schema-review
  • test-regression-runner

Die Namen müssen für Menschen eindeutig sein und im Projektkontext eine Funktion erkennen lassen. Starten Sie beide Prozesse im vorgesehenen Repository und prüfen Sie anschließend mit:

/list-agents

Die konkrete Ausgabe kann je nach Release und Sitzungszustand variieren. Entscheidend ist nicht, dass jede denkbare Sitzung sichtbar wird, sondern dass Sie den Namen der Zielinstanz zweifelsfrei erkennen können.

Führen Sie danach eine reine Lesefrage aus. Die erste Sitzung soll beispielsweise den Status der zweiten Sitzung erfragen, ohne eine Datei zu ändern:

Bitte ermittle den Status der Sitzung „backend-schema-review“.
Frage nur nach Branch, letztem Commit und aktuellem Arbeitsschritt.
Nimm keine Änderungen am Repository vor.

Die Nachricht sollte klein bleiben. Senden Sie keine langen Protokolle und kopieren Sie nicht den kompletten Gesprächsverlauf. Notieren Sie, ob die Nachricht zugestellt, zwischengespeichert, abgelehnt oder wegen eines unbekannten Ziels nicht verarbeitet wurde.

Claude Code: Zwei Terminals verbinden

Für zwei Terminals benötigen Sie keine gemeinsame Shell-Historie. Sie benötigen:

  1. zwei laufende Claude-Code-Sitzungen,
  2. eindeutige Namen,
  3. eine funktionierende Agent-Erkennung über ListAgents,
  4. eine kompatible Version,
  5. eine kurze Nachricht mit klarer Zieladresse,
  6. eine Antwort, die auf die Testfrage eingeht.

Verwechseln Sie diesen Ablauf nicht mit einer wiederaufgenommenen Sitzung. Die Sitzungswiederaufnahme setzt den Verlauf einer bestimmten Sitzung fort; die sitzungsübergreifende Kommunikation sendet eine neue Information an eine andere laufende Instanz. Ebenso ist Remote Control nicht dasselbe wie eine Peer-Nachricht: Remote Control stellt eine lokale Sitzung über Browser oder Mobilgerät bereit, während die lokale Sitzung weiterhin auf ihrem Rechner läuft. Die Dokumentation zu Remote Control beschreibt diese Architektur und ihre Verbindungswege.

Stunde eins: Git-worktree-Isolation einrichten

Sobald die Nachrichtenzustellung funktioniert, trennen Sie die Arbeitsbereiche. Zwei Agenten sollten nicht gleichzeitig im selben Checkout an Frontend, Backend oder Tests schreiben. Das Risiko betrifft nicht nur offensichtliche Konflikte in einer Datei:

  • generierte Dateien können sich gegenseitig überschreiben;
  • ein Test-Agent kann Ergebnisse aus einem unfertigen Zwischenstand melden;
  • ein Build-Prozess kann Artefakte löschen, die der andere Agent gerade benötigt;
  • ein Agent kann eine Konfigurationsänderung sehen, die noch nicht dokumentiert oder geprüft wurde.

Erstellen Sie deshalb pro Aufgabe einen eigenen Git worktree. Ein mögliches Muster ist:

git worktree add ../projekt-frontend -b ai/frontend-api
git worktree add ../projekt-backend -b ai/backend-schema
git worktree add ../projekt-tests -b ai/regression-tests

Die Befehle sind allgemeine Git-Arbeitsabläufe, nicht spezielle Claude-Code-Kommandos. Prüfen Sie vor der Verwendung, ob Branch-Namen, Repository-Zustand und lokale Buildvoraussetzungen zu Ihrem Projekt passen. Ein sauberer Ausgangscommit ist wichtiger als ein besonders ausgefeiltes Agent-Setup.

Legen Sie anschließend eine Nachrichtenkonvention fest. Eine gute Nachricht enthält höchstens diese Informationen:

  • betroffene Schnittstelle oder Datei,
  • konkrete Änderung,
  • Commit oder Branch,
  • Testergebnis,
  • offene Blockade,
  • erwartete nächste Aktion.

Beispiel:

API-Änderung: POST /users liefert jetzt account_id.
Branch: ai/backend-schema
Commit: 8f31abc
Tests: Backend-Suite erfolgreich.
Bitte passe den Frontend-Adapter an und melde den Regressionstest zurück.

Der Backend-Agent darf nicht voraussetzen, dass der Frontend-Agent den neuen Code bereits in seinem worktree besitzt. Der Frontend-Agent muss den Branch, Commit oder Patch selbst holen und anschließend prüfen. So reduziert die Nachricht Koordinationskosten, ersetzt aber weder Versionskontrolle noch Code Review.

Schnittstellenänderung als kontrollierter Test

Verwenden Sie für den ersten Praxistest eine kleine, nachvollziehbare Änderung:

  1. Der Backend-Agent ändert ein klar benanntes API-Feld.
  2. Er führt die relevanten Backend-Tests aus.
  3. Er sendet Feldname, Branch, Commit und Testergebnis.
  4. Der Frontend-Agent übernimmt den Commit oder aktualisiert seinen Branch.
  5. Der Frontend-Agent passt den Adapter in seinem worktree an.
  6. Der Test-Agent führt Regressionstests gegen den neuen Stand aus.
  7. Ein Mensch prüft Diff, Testausgabe und Berechtigungsprotokoll.

Die Vorteile sind messbar im Ablauf: weniger manuelles Kopieren und weniger unklare Übergaben. Die Nachteile bleiben bestehen: mehr laufende Prozesse, mehr Kontextkosten und mehr Zustände, die Sie überwachen müssen. Bei stark voneinander abhängigen Änderungen ist ein einzelner Agent mit klarer Aufgabenliste oft die bessere Beschaffungslösung.

Zweite Phase: Cross-Machine-Kommunikation

Erweitern Sie den Betrieb erst, wenn der lokale Test erfolgreich war. Unterscheiden Sie drei Pfade:

  • Gleiche Maschine: Die Sitzungen teilen sich Betriebssystem, Benutzerumgebung und lokale Zustandsverzeichnisse. Der Kommunikationsweg ist nicht gleichbedeutend mit einer öffentlichen Netzwerkverbindung.
  • Lokale Sitzung zu einer entfernten Sitzung: Die Nachrichten müssen die Verbindung zwischen den Maschinen und die unterstützte Claude-Code-Bereitstellung passieren.
  • Remote Control: Sie steuern eine lokale Sitzung von einem Browser oder Mobilgerät. Das ist Fernsteuerung einer bestehenden Sitzung, nicht automatisch eine neue Peer-Sitzung.

Bei Cross-Machine-Betrieb sollten Sie davon ausgehen, dass Nachrichten über einen Dienstpfad zwischen den beteiligten Sitzungen vermittelt werden. Die offizielle Remote-Control-Dokumentation beschreibt für diesen verwandten Fernzugriff ausdrücklich ausgehende HTTPS-Verbindungen, TLS und eine Vermittlung über die API. Übertragen Sie diese Aussage nicht unbesehen auf jeden internen Peer-Kommunikationspfad; prüfen Sie die Release- und Funktionsdokumentation Ihrer konkreten Version.

Testen Sie zuerst mit einer Nachricht ohne Quellcode, Zugangsdaten oder personenbezogene Daten:

Verbindungstest von host-a.
Bitte antworte nur mit Sitzungsname, Arbeitsverzeichnis und „bereit“.
Keine Befehle ausführen.

Prüfen Sie danach:

  • Ist der Zielname eindeutig?
  • Kommt die Antwort an die erwartete Sitzung zurück?
  • Was passiert beim kurzzeitigen Trennen der Verbindung?
  • Wird eine Nachricht nach dem Wiederverbinden zugestellt oder bleibt sie ausstehend?
  • Können Container und Host sich gegenseitig erkennen?

Container sind ein häufiger Stolperstein. Ein Prozess innerhalb eines Containers kann andere lokale Zustandsdateien, Sockets oder Benutzerverzeichnisse sehen als ein Prozess auf dem Host. Selbst wenn beide auf dasselbe Repository zugreifen, bedeutet das nicht, dass sie dieselbe Sitzungsregistrierung verwenden. Behandeln Sie Containergrenzen daher als separate Deployment-Topologie und testen Sie sie unabhängig.

Fehlerbild: SendMessage kommt nicht an

Wenn SendMessage keine sichtbare Antwort erzeugt, prüfen Sie nicht zuerst den Textinhalt. Arbeiten Sie die Fehlerquelle von unten nach oben ab:

  1. Version: Führen Sie in beiden Terminals claude --version aus und vergleichen Sie die Ausgaben.
  2. Plattform: Prüfen Sie, ob beide Prozesse auf dem vorgesehenen macOS- oder Linux-Pfad laufen.
  3. Sichtbarkeit: Starten Sie /list-agents erneut und kopieren Sie den Zielnamen exakt.
  4. Sitzungszustand: Stellen Sie fest, ob die Zielinstanz aktiv, wartend, beendet oder bereits wiederaufgenommen wurde.
  5. Arbeitsumgebung: Vergleichen Sie Host, Benutzer, Containerstatus und relevante Claude-Code-Zustandsverzeichnisse.
  6. Nachrichteninhalt: Senden Sie eine kurze, nicht vertrauliche Testnachricht ohne verschachtelte Anweisungen.
  7. Berechtigungen: Prüfen Sie, ob Organisationsrichtlinien, Tool-Blockaden oder ein eingeschränkter Modus die Kommunikation begrenzen.
  8. Protokollierung: Aktivieren Sie nur für die Diagnose ausführlichere Logs und speichern Sie Zeitpunkt sowie Fehlermeldung.

Vermeiden Sie erfundene Community-Kommandos. Wenn ein Befehl nicht in der offiziellen CLI-Dokumentation oder Ihrer installierten Version nachweisbar ist, gehört er nicht in den Produktionsablauf. Die offizielle CLI-Referenz ist die bessere Grundlage für reproduzierbare Prüfungen.

Berechtigungen für den Produktivbetrieb

Die Eingangsnachricht muss in Ihr Berechtigungsmodell passen. Teilen Sie Sitzungen in drei Klassen ein:

  • Interaktive Entwicklung: Status- und Entscheidungsnachrichten dürfen automatisch angenommen werden; Dateiänderungen und Shell-Befehle bleiben genehmigungspflichtig.
  • Unbeaufsichtigte Testaufgabe: Nachrichten können angenommen werden, aber Schreibpfade, Netzwerkzugriffe und Deployments sollten in einer isolierten Umgebung liegen.
  • Hochsensibles Projekt: Eingehende Peer-Nachrichten zunächst zurückhalten oder ablehnen; ListAgents und SendMessage bei Bedarf vollständig sperren.

Die offizielle Berechtigungsdokumentation unterscheidet zwischen allow, ask und deny. Regeln werden in der Reihenfolge „deny“, „ask“, „allow“ ausgewertet; eine explizite Sperre hat daher Vorrang. Prüfen Sie die aktiven Regeln mit:

/permissions

Eine beispielhafte Projektkonfiguration könnte sensible Dateien und riskante Netzwerkbefehle sperren:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

Passen Sie die Regeln an Ihr Repository an und übernehmen Sie keine Vorlage ungeprüft. Die Dokumentation zu Berechtigungen und Einstellungen erklärt außerdem die Unterschiede zwischen Projekt-, Benutzer- und verwalteten Einstellungen.

Wichtig ist die Abgrenzung: Eine Nachricht wie „Bitte führe den Test aus“ autorisiert nicht automatisch den Testlauf. Die Empfängersitzung bewertet den Befehl anhand ihrer eigenen Regeln. Diese Trennung schützt vor einer gefährlichen Form der Berechtigungsweitergabe, bei der ein Agent versucht, eine Genehmigung über einen anderen Agenten zu „vererben“.

Checkliste für die Abnahme

Verwenden Sie diese Liste, bevor Sie die Kommunikation auf weitere Entwickler oder Maschinen ausrollen:

  • [ ] Beide Sitzungen melden eine kompatible Claude-Code-Version.
  • [ ] Die Plattformen entsprechen dem dokumentierten Funktionsumfang.
  • [ ] Jede Sitzung besitzt einen eindeutigen Namen mit Rolle und Arbeitsbereich.
  • [ ] /list-agents zeigt die erwartete Zielinstanz.
  • [ ] Eine kurze, nicht vertrauliche Testnachricht wird beantwortet.
  • [ ] Frontend, Backend und Tests arbeiten in getrennten Git-worktrees.
  • [ ] Nachrichten enthalten Branch, Commit, Änderung und Testergebnis.
  • [ ] Ein Nachrichteneingang wird nicht als Tool- oder Shell-Genehmigung behandelt.
  • [ ] Cross-Machine-Nachrichten wurden mit einem isolierten Testprojekt geprüft.
  • [ ] Container- und Host-Sitzungen wurden getrennt bewertet.
  • [ ] allow, ask und deny sind dokumentiert und für das Team nachvollziehbar.
  • [ ] Ein Mensch prüft mindestens einen vollständigen Diff vor dem Merge.
  • [ ] Zustellfehler, Wiederverbindung und Sitzungsabbruch wurden dokumentiert.
  • [ ] Nach einer Woche liegen Messwerte zu Freigaben, Konflikten und Leerlaufzeiten vor.

Erste Woche: Betrieb messen

Nach dem erfolgreichen Funktionstest sollten Sie nicht sofort die Zahl der Agenten erhöhen. Führen Sie zunächst ein einfaches Betriebsprotokoll. Erfassen Sie pro Aufgabe:

  • Anzahl gesendeter und beantworteter Nachrichten,
  • manuelle Berechtigungsabfragen,
  • doppelte oder widersprüchliche Statusmeldungen,
  • Änderungen am gleichen Zielbereich,
  • Wartezeit zwischen Übergabe und Reaktion,
  • Sitzungsabbrüche und Wiederaufnahmen,
  • Zeit, die ein Agent ohne verwertbaren Fortschritt wartet.

Bewerten Sie nach der ersten Woche die tatsächliche Koordinationsleistung. Wenn Nachrichten häufiger wiederholt werden müssen, Agenten denselben Codebereich anfassen oder jeder Schritt auf eine Antwort warten muss, ist das System wahrscheinlich zu stark parallelisiert. Gehen Sie dann auf einen Einzelprozess, Sub-Agenten oder eine strengere Aufgabenzerlegung zurück.

Für länger laufende Projekte kann ein Remote Mac sinnvoll sein, wenn mehrere Sitzungen dauerhaft erreichbar sein müssen, Entwickler in verschiedenen Zeitzonen arbeiten oder Ihr lokaler Rechner nicht kontinuierlich laufen soll. Ihr aktueller Rechner bleibt jedoch oft die bessere Wahl, wenn Sie physische Geräte, lokale USB-Schnittstellen, private Netzwerke oder konstante Hochlast benötigen. Ein Remote Mac ist kein Ersatz für ein sauberes Berechtigungsmodell und keine Garantie gegen Sitzungsabbrüche.

Aktuelle Arbeitsumgebung oder Remote Mac

Die lokale Lösung hat drei klare Vorteile: Sie kennen die Hardware, kontrollieren das Netzwerk und greifen ohne zusätzliche Übergabeschicht auf Ihre Entwicklungsumgebung zu. Ihre Nachteile liegen in der Verfügbarkeit, dem Schlafmodus des Rechners und der Tatsache, dass mehrere Claude-Code-Sitzungen Ihre persönliche Arbeitsmaschine dauerhaft belegen können.

Ein Remote-Setup löst dagegen die Erreichbarkeit und die Trennung der Arbeitsbereiche besser, bringt aber neue Punkte mit: laufende Mietkosten, Abhängigkeit von Netzwerk und Anbieter, zusätzliche Datenschutzprüfung nach DSGVO sowie Aufwand für Wiederherstellung, Updates und Zugangsschutz. Für kurzfristige Tests ist der eigene Mac meist wirtschaftlicher; für planbare Mehr-Agenten-Arbeit über viele Stunden oder Zeitzonen hinweg kann eine gemietete Umgebung organisatorisch sauberer sein.

Wenn Sie diese Entscheidung vorbereiten, vergleichen Sie zunächst die Remote-Mac-Bereitstellung, die Mietkosten und Laufzeitoptionen sowie die Informationen zur Datenschutzpraxis. Entscheidend sind nicht möglichst viele Sitzungen, sondern getrennte worktrees, stabile Erreichbarkeit und ein nachvollziehbarer Wiederanlauf.

Für Sie als Entwickler bedeutet das: Beginnen Sie mit zwei Sitzungen auf einer Maschine, beweisen Sie die Nachrichtenkette mit einer kleinen API-Änderung und skalieren Sie erst dann. Wenn mehrere Claude-Code-Sitzungen dauerhaft laufen, über Zeitzonen hinweg übergeben werden oder Ihren persönlichen Rechner blockieren, ist ein Remote Mac von kvmsync eine sinnvolle nächste Stufe – vorausgesetzt, Arbeitsbaum, Berechtigungen und Wiederherstellungsprozess sind bereits sauber definiert.

Weiterlesen

kvmsync M4 Remote-Knoten

Ihre Remote-Mac-Umgebung für Claude Code

Mieten Sie mit kvmsync einen exklusiven Mac mini M4 mit nativem macOS, Root-Zugriff und fester öffentlicher IPv4-Adresse für dauerhaft verfügbare Agenten-Sitzungen.

Mac mini M4 jetzt mieten M4-Pakete vergleichen