OpenClaw-Multiplayer mit geteilten Agents: Zwei Geräte, ein Kontext

Zwei Geräte können sich sicher einen OpenClaw-Agenten teilen – vorausgesetzt, du behandelst die Warteschlange als Text und die dauerhafte Speicherung als separate Aufgabe. Die gemeinsame Session enthält den Kontext; Dateien wie active-tasks.md halten die eigentlichen Verpflichtungen fest.

Genau darin liegt der entscheidende Unterschied. OpenClaw 2.0 (Release v2026.8.1, angekündigt am 30. August 2026) hat gemeinsame Multiplayer-Sessions ergänzt. Darunter bleibt das Gateway eine einzige Vertrauensdomäne. So können zwei Smartphones, zwei Laptops oder zwei Personen denselben Lauf steuern, ohne jeweils einen privaten Ableger zu bekommen (docs.openclaw.ai). Die offizielle Dokumentation stellt ausdrücklich klar: Besitz, Anwesenheit und Rollen dienen der Koordination, sind aber keine Sicherheitsisolierung zwischen nicht vertrauenswürdigen Nutzern (docs.openclaw.ai). Was die Dokumentation beschreibt und worüber Nutzer in der Praxis stolpern, sind zwei verschiedene Dinge: Warteschlange, Lebensdauer der Session und Speicher.

Smartphone auf dem Sofa, Laptop am Schreibtisch: Was in der Praxis schiefgeht

Das typische Zwei-Geräte-Szenario bedeutet längst nicht immer, dass zwei Personen beteiligt sind. Oft nutzt eine Person das Smartphone als Fernbedienung, während ein Mac Mini oder VPS als Host läuft – häufig über Telegram. Ein Nutzer formulierte es sehr direkt: Er bat seinen „OpenClaw-Agenten Monica über Telegram, mem0 lokal auf seinem Mac Mini zu installieren“ (x.com).

Sobald ein zweites Gerät oder eine zweite Person denselben Agenten nutzt, tauchen laut Nutzerberichten vor allem vier Fehlerklassen auf:

1. Nachrichten verschwinden unbemerkt. Die wohl wichtigste Lehre aus der Community steckt in einer Checkliste: queue mode enabled so messages never silently drop, kombiniert mit active-tasks.md as persistent state for crash recovery und einer Boot.md, die die Datei beim Neustart erneut einliest (x.com). Ohne diese Kombination ist eine Nachricht, die während eines laufenden Agenten-Turns abgeschickt wird, lediglich Gesprächsinhalt – kein gesichert abgelegter Arbeitsauftrag.
2. Anweisungen lösen sich nach Komprimierung oder Neustart in Luft auf. Ein Reddit-Nutzer brachte das Problem auf den Punkt:

„Es gibt keine dauerhafte Aufgabenwarteschlange – wenn der Agent sagt: ‚Ich kümmere mich darum‘, ist das nur ein Versprechen im Gespräch.“ – u/Brave_Nobody_6909, r/openclaw

Im selben Thread berichten Nutzer, dass solche Zusagen nach einer Komprimierung oder einem Neustart verschwinden und der Agent gespeicherte Runbooks ignoriert. Eine Erklärung aus Maintainer-Nähe beschreibt das Grundproblem ähnlich: Ein Agent kann „20 Minuten lang perfekt arbeiten“ und dann „deine Anweisungen unbemerkt vergessen und aus dem Ruder laufen“, wenn der Umgang mit dem Speicher missverstanden wird (x.com).

1. Die Session wird unter dir zurückgesetzt. Für Telegram-Kanäle galt standardmäßig unter anderem thread: { mode: "idle", idleMinutes: 180 }. Nach einigen Stunden ohne Aktivität wird die Session damit zurückgesetzt. Ein Nutzer stellte den Wert nach Problemen in einem Smartphone-als-Zweitbildschirm-Setup auf 4 Tage (x.com). Kontextüberlauf verschärft die Lage: Zu viele Tool-Aufrufe können dazu führen, dass die letzte Nachricht erneut eingespeist wird. Der Agent „reagiert dann immer wieder auf dasselbe“ und „baut anschließend unbemerkt ab“ (x.com).
2. Das Pairing scheitert, bevor Multiplayer überhaupt beginnt. Nach einem Upgrade verloren gekoppelte Geräte die Scopes operator.read/operator.write und landeten in einer endlosen Pairing-Schleife mit unbrauchbaren Tools. Der Gründer kommentierte: „Ich war bei der Behebung eines potenziellen Sicherheitsproblems übereifrig“ (x.com). Chinesischsprachige Nutzer stießen auf dasselbe Problem in Form von 1008: pairing required; das lokale Gerät blieb in der Pending-Warteschlange hängen, bis openclaw devices list und anschließend devices approve <UUID> ausgeführt wurden (x.com).

Die Presence-Anzeige zeigt zwar, dass jemand tippt. Sie macht aus einer Nachricht aber noch lange keine gespeicherte Aufgabe.

Ein Gateway, eine Vertrauensdomäne: Gemeinsame Session, getrennte Agents und Zuständigkeiten

Die wichtigste Neuerung von OpenClaw 2.0 sind gemeinsame Sessions: Eine weitere Person kann in laufende Arbeit einsteigen, ohne den vorhandenen Kontext zu verlieren. Unabhängige Reviews werteten das als Schritt vom Einzelbetrieb zur kollaborativen Arbeit (eesel.ai). Für die konkrete Konfiguration sind darunter zwei Begriffe aus der offiziellen Dokumentation entscheidend.

Multi-User-Modus bedeutet, dass mehrere vertrauenswürdige Personen denselben Agenten bedienen. Jede gemeinsame Session speichert drei Ebenen: einen unveränderlichen Ersteller (createdActor, nur einmal beschreibbar), einen zuweisbaren Besitzer (ähnlich einem GitHub-Assignee, jederzeit änderbar) und eine Teilnehmerhistorie darüber, wer die Session tatsächlich angesteuert hat (docs.openclaw.ai). Die Presence zeigt Betrachter und Tippende. Entwürfe während des Tippens gelangen jedoch weder zum Modell noch ins Transkript. Auch die Zuordnung einzelner Turns ist ausdrücklich nur best effort, weil die Eingaben mehrerer Personen zu einem Turn zusammengeführt werden können (docs.openclaw.ai). Praktisch heißt das: Schickt jemand über einen zweiten Kanal eine Rückfrage, während der Agent gerade ein Tool ausführt, landet sie im Transkript. Der laufende Turn wird aber zuerst abgeschlossen. Die zweite Anweisung wirkt dann wie ein Steuerhinweis und nicht wie ein Interrupt (docs.openclaw.ai).

Multi-Agent-Modus bedeutet, dass ein Gateway-Prozess mehrere isolierte Gehirne hostet. Jeder Agent besitzt einen eigenen Workspace, ein eigenes agentDir (Authentifizierungsprofile, Modell-Registry) und einen eigenen SQLite-Session-Speicher unter <agentDir>/openclaw-agent.sqlite (github.com). Ein Binding leitet eingehende Kanalereignisse an einen Agenten weiter; dabei gewinnt die spezifischste Übereinstimmung. Verwende niemals dasselbe agentDir für mehrere Agents, sonst überschreiben sie gegenseitig ihre auth-profiles.json (stack-junkie.com). Ein minimales Beispiel: { agentId: "coding", match: { channel: "telegram", accountId: "coding-bot" } } leitet einen Bot an einen bestimmten Agenten weiter.

Der wichtigste Merksatz zur Vertrauensfrage lautet: „Ein Gateway ist eine Vertrauensdomäne“ (docs.openclaw.ai). Rollen, Besitzerfilter und Avatare schützen nicht vor nicht vertrauenswürdigen Nutzern. Für voneinander unabhängige Nutzer brauchst du getrennte Gateways, idealerweise zusätzlich getrennte Betriebssystemnutzer oder Hosts.

Für zwei Geräte derselben Person ist die linke Spalte die richtige Wahl. Wenn zwei Personen arbeiten, aber nicht regelmäßig die Historie der jeweils anderen sehen sollen, passt die rechte Spalte. Muss der Zugriff gegenüber nicht vertrauenswürdigen Nutzern technisch durchgesetzt werden, brauchst du zwei Gateways. Reddit-Empfehlungen für Paare, die sich einen Bot teilen, laufen auf Folgendes hinaus: „Erstellt zwei Agents mit demselben Auth-Profil, aber einen auf dich zugeschnitten … und den anderen auf deine Frau“ (u/mr-cto-apps, r/openclaw). In einem Thread über einen gemeinsam genutzten Telegram-Bot rät ein Nutzer: „Die meisten Menschen in deiner Situation betreiben einfach zwei Instanzen“ (u/dertobi, r/openclaw). Das gilt auch nach der Einführung gemeinsamer Sessions in 2.0 weiterhin für getrennte, private Arbeit.

Was mit deiner zweiten Nachricht passiert, während der Agent beschäftigt ist

Denke in drei Schubladen. Genau an deren Grenzen verwechseln Nutzer die Mechanismen und verlieren Arbeit.

Schublade 1: die Session-Warteschlange. Text, den du während der Arbeit des Agenten sendest, wird an die aktuelle Session angehängt. Der Warteschlangenmodus lässt ihn warten, statt ihn zu verwerfen. Die Presence zeigt, dass der Agent gerade mitten in einem Turn steckt. Deine Nachricht steuert dann den nächsten Turn, unterbricht aber nicht den aktuellen. Tippentwürfe sind flüchtig und gelangen nie in den Kontext (docs.openclaw.ai). Halte Nachrichten vom zweiten Gerät kurz und eindeutig, etwa: „Wenn das fertig ist, erledige X; Y nicht neu starten.“ Die Dokumentation beschreibt die Turn-Zuordnung ausdrücklich als best effort, wenn Eingaben mehrerer Nutzer zu einer Steuerung verschmelzen (docs.openclaw.ai).

Schublade 2: dauerhaft gespeicherte Aufgaben. Eine Nachricht in der Warteschlange ist noch keine dauerhafte Aufgabe. Startet das Gateway neu, wird die Session komprimiert oder verwendest du /new, können Gesprächszusagen verschwinden. Die Community-Lösung, die Neustarts überlebt, ist eine Datei statt einer Nachricht: active-tasks.md als Zustand für die Crash-Wiederherstellung plus eine Boot.md, die der Agent bei Session- und Gateway-Neustarts einliest (x.com). Memory-Tools können Kontext erneut einspeisen. Eine häufig geteilte Erklärung warnt allerdings, dass auch der geladene Speicher wieder zusammengefasst werden kann: „Der Speicher liegt auf der Festplatte. Der Agent hat lediglich die Fähigkeit verloren, ihn durchzugehen“ (x.com).

Schublade 3: geplante Arbeit. Cron und Automatisierungen laufen, solange das Gateway läuft. Schläft der Host, pausieren die Zeitpläne (eesel.ai). Ein Nutzer berichtete, dass Cron-Läufe den Agenten währenddessen „praktisch unbenutzbar“ machten, weil der Sitzungsverlauf den Kontext überflutete. Als Lösung empfahl er getrennte Kontexte pro Telegram-Thema (x.com). Verwende geplante Jobs für wiederkehrende Aufgaben, aber niemals als Ersatz für eine Folgeanweisung in der Warteschlange.

Die Anzeige der Warteschlange kann der Realität hinterherhinken: In einem Thread wurden sichtbare Warteschlangeneinträge gemeldet, während /subagents und /tasks nichts anzeigten (reddit.com). Behandle deshalb die Datei aus Schublade 2 als Neustart-Sicherheitsnetz – unabhängig davon, was die Oberfläche der Warteschlange anzeigt.

Das Zwei-Geräte-Setup, bei dem keine Anweisungen verloren gehen

Diese Konfiguration eignet sich für eine Person mit Laptop und Smartphone oder für zwei vertrauenswürdige Teammitglieder in einer gemeinsamen Session. Sie folgt den offiziellen Quick-Setup- und Production-Runbooks (docs.openclaw.ai) und ergänzt die Maßnahmen gegen Datenverlust, auf die sich die Community geeinigt hat.

1. Platziere das Gateway auf einem ständig erreichbaren Host und greife über deine Identität darauf zu. Ein kleiner VPS, ein Büro-Mac oder ein Mac Mini reicht aus. Binde das Gateway an Loopback und stelle Tailscale Serve oder Cloudflare Access davor, statt einen öffentlichen Port oder ein gemeinsames Token zu verwenden. Identitätsbasierter Zugriff ermöglicht die Zuordnung von Personen in Sessions und die Zuordnung von Commits; ein gemeinsames Token behandelt alle als dasselbe Besitzerprofil (docs.openclaw.ai).
2. Verbinde beide Geräte mit derselben Session, nicht mit zwei Sessions. Öffne auf beiden Geräten die Control UI oder den Chat-Kanal, weise den Besitzer der Session ausdrücklich zu (Control UI: Assign to me / Assign to oder im sessions-Tool assign_owner) und nutze @Mentions für Übergaben. Direktnachrichten und Gruppenräume benötigen getrennte Allowlists (docs.openclaw.ai). Eine Änderung des Besitzers ändert die Verantwortung, nicht die an den Ersteller gebundene Freigabe oder Archivberechtigung. Halte den Ersteller daher stabil.
3. Aktiviere die Warteschlange und mache die Arbeit neustartfest. Schalte die gemeinsame Session in den Warteschlangenmodus, damit eine Nachricht während eines laufenden Turns wartet, statt mit ihm zu konkurrieren. Ohne diesen Modus berichten Nutzer von stillschweigend verlorenen Nachrichten. Führe im Workspace eine active-tasks.md mit einer Zeile pro Verpflichtung (erledigt / in Arbeit / als Nächstes) und ergänze eine Boot.md, die den Agenten anweist, die Datei beim Start zu lesen (x.com). Prüfe, ob das Modell tatsächlich antwortet, bevor du dich auf das zweite Gerät verlässt. Gespeicherte Zugangsdaten allein bestätigen keinen erfolgreichen Ablauf (docs.openclaw.ai).
4. Verlängere die Session-Lebensdauer auf Kanälen, die du am Smartphone nutzt. Wenn Telegram als Zweitbildschirm dient und dein Thread den gemeldeten Reset thread: { mode: "idle", idleMinutes: 180 } verwendet, erhöhe den Wert für lange Aufgaben. Ein Nutzer ging auf 4 Tage. Trenne außerdem die Themen, damit Cron-Ausgaben den gemeinsamen Kontext nicht überfluten.
5. Gib jeder Person ein eigenes Modellkonto. Gateway-Profile können persönliche Zugangsdaten enthalten. Neue Sessions bevorzugen dann den persönlichen Standard, ohne den Gateway-Standard zu verändern. Andere Nutzer sehen lediglich eine Bezeichnung auf Personenebene, nicht E-Mail-Adresse oder Account-ID (docs.openclaw.ai). Zugangsdaten gehören ausschließlich in geschützte Oberflächen oder versteckte Terminal-Eingaben – niemals in den Chat, wo sie im gemeinsamen Transkript landen würden.
6. Prüfe den gesamten Ablauf. Sende vom zweiten Gerät während eines laufenden Turns eine Nachricht und kontrolliere, dass sie erhalten bleibt und nach Abschluss des aktiven Turns verarbeitet wird. Starte danach das Gateway neu und prüfe, ob active-tasks.md die Verpflichtung wiederherstellt. Auch die offizielle Produktions-Checkliste endet genau dort: Erst den vollständigen Ablauf testen, dann ihn als erledigt betrachten (docs.openclaw.ai).

Regeln gegen verrottenden gemeinsamen Kontext

Drei Regeln decken den größten Teil der Probleme ab, die Nutzer beim gemeinsamen Kontext beschreiben.

Jeden Speichereintrag signieren. Besonders heimtückisch ist, wenn sich nicht zuordenbare Regeln ansammeln und niemand sie mehr löschen möchte: „Nach sechs Monaten ist der gemeinsame Kontext voller Regeln, die niemand einer Person zuordnen kann – also fühlt sich niemand berechtigt, sie zu löschen.“ Als Lösung wurde vorgeschlagen: „Autor bei jedem Speichereintrag“ (x.com). Das eigentliche Muster lautet: gemeinsame Schreibzugriffe ohne Urheberschaft. Beginne dauerhafte Notizen mit dem Namen der anfragenden Person und dem Datum und räume sie monatlich auf.

Den weniger vertrauenswürdigen Sitz isolieren. Rollen können den Zugriff auf Sessions, erlaubte Agents und Operator-Scopes beschränken. Gastsessions lassen sich mit workspaceAccess: "none" in eine Sandbox zwingen, sodass Datei- und Shell-Tools in einem privaten Workspace statt im gemeinsamen Agent-Workspace arbeiten (docs.openclaw.ai). Private Entwürfe gehören in Draft-Sessions. Sie bleiben zwar aus den Seitenleisten anderer Nutzer heraus, sind für Administratoren aber niemals verborgen (docs.openclaw.ai).

Erkenne, wann Schluss mit dem Teilen ist. Ein Betreiber mehrerer Agents bezeichnete das Überlaufen von Kontext als „größte praktische Herausforderung“: Agents würden „in das Gebiet des jeweils anderen abdriften“ (u/BP041, r/openclaw). Chinesischsprachige Entwickler kommen zu einer noch klareren Regel: Einen Agenten optimieren und anschließend pro Gerät klonen – „ihn auf ein neues Gerät klonen“, sodass aus dem abgestimmten Setup „einer pro Person“ wird (x.com). Dabei werden nur Speicher und Dotfiles synchronisiert, nicht Zugangsdaten und laufende Sessions (x.com). Das entspricht auch dem Ausweg in der Dokumentation: agentenspezifische Memory-Wiki-Tresore (vault.scope = "agent"), ausdrücklich freigegebene gemeinsame Markdown-Verzeichnisse statt agentenübergreifender Transkriptsuche und getrennte Gateways, wenn echte Isolation erforderlich ist (github.com).

FAQ

Können zwei Geräte gleichzeitig dieselbe OpenClaw-Agent-Session nutzen?

Ja. Beide Geräte treten derselben Session bei; der Kontext hängt an der Session und nicht am Gerät. Weise einen Besitzer zu und aktiviere den Warteschlangenmodus, damit die Nachricht des zweiten Geräts wartet (docs.openclaw.ai).

Warum verschwinden Anweisungen nach Komprimierung, /new oder einem Neustart?

Weil eine Chatnachricht keine gespeicherte Aufgabe ist. Die Komprimierung fasst den Kontext zusammen, /new startet eine frische Session und bei einem Neustart geht der Zustand aus dem Arbeitsspeicher verloren. Lege Verpflichtungen in active-tasks.md ab und lasse sie über eine Boot.md erneut einlesen (x.com).

Sollten zwei Personen einen Agenten teilen oder jeweils einen eigenen betreiben?

Teile einen Agenten, wenn beide denselben Thread, Speicher und dieselbe Warteschlange benötigen. Nutzt jeweils einen eigenen Agenten oder ein eigenes Gateway, wenn Historien, Zugangsdaten oder Berechtigungen nicht vermischt werden dürfen. Multi-User-Funktionen bieten keine Sicherheitsisolierung (docs.openclaw.ai). Gemeinsame Steuerung kann Co-authored-by-Commit-Trailer erzeugen, wenn die GitHub-Zuordnung eingerichtet ist (docs.openclaw.ai).

Teilen oder klonen? Die Entscheidung in 30 Sekunden

Der Warteschlangenmodus verhindert, dass zwei Tippende gleichzeitig dazwischenfunken. Widersprüchliche Anweisungen löst er jedoch nicht – zusammengeführte Eingaben können sich weiterhin vermischen. Die Datei sorgt dafür, dass ihre Anweisungen auch nach einem Neustart erhalten bleiben.