OpenClaw 2.0 im Enterprise-Check: Funktionen, Migration und Risiken

Table of Contents

Zuletzt aktualisiert: 31. August 2026 · Version: 2.2

Redaktionshinweis: Dieser Artikel wurde mit KI-Unterstützung recherchiert und überarbeitet sowie menschlich redaktionell geprüft. Produkt-, Funktions- und Migrationsangaben stammen überwiegend aus dem OpenClaw-Blog, den offiziellen Release Notes, dem GitHub-Repository und der Security-Dokumentation mit Quellenstand 31. August 2026. OpenClaw 2.0 ist erst seit Kurzem verfügbar; unabhängige Langzeiterfahrungen aus Unternehmensumgebungen liegen noch nicht vor. Funktionen können je nach Plattform, Modellanbieter, Plugin, Konfiguration und Freigaben des Unternehmens abweichen. Die rechtliche Einordnung dient der Orientierung und ersetzt keine Einzelfallprüfung.

⚡ In 30 Sekunden

OpenClaw 2.0 ist die stabile Version v2026.8.1, veröffentlicht am 31. August 2026. Die OpenClaw Foundation spricht von mehr als 16.000 Pull Requests und 933 Mitwirkenden.
Die wichtigste Veränderung ist nicht ein neues KI-Modell, sondern ein reiferer Agenten-Stack mit vereinfachtem Onboarding, neuer Browser-Oberfläche und zusätzlichen Betriebsfunktionen.
Für Unternehmen kommen relevante Kontrollfunktionen hinzu: Rollen, Sitzungsrechte, geschützte Credential-Abfragen, ein gemeinsamer Secret Store, nachvollziehbare Konfigurationsänderungen und präzisere Freigaben für Automationen.
Die Sicherheitsgrenze bleibt eng: OpenClaw ist für eine einzelne vertrauenswürdige Person oder ein Team mit gegenseitigem Vertrauen ausgelegt. Rollen in einem gemeinsamen Gateway sind keine Mandantentrennung; Sandboxing muss bewusst konfiguriert werden.
Die Empfehlung lautet nicht „sofort überall aktualisieren“: Bestehende Installationen sollten zuerst vollständig gesichert, in einer Staging-Umgebung migriert und mit realen Werkzeug-, Plugin-, Rechte- und Rollback-Tests geprüft werden.

Was ist in OpenClaw 2.0 neu?

OpenClaw 2.0 ist kein neues Modell-Release, sondern ein umfassendes Betriebs- und Plattform-Update. Neu sind vor allem:

Einfacheres Onboarding: Bestehende Modellzugänge, API-Schlüssel und lokale Laufzeiten können bei der Einrichtung erkannt werden.
Neue Control UI: Gespräche, Sessions, Rückfragen, Dashboards, Widgets und dauerhafte Fortschrittsanzeigen werden in einer Browser-Oberfläche gebündelt.
Durchsuchbare und übertragbare Sessions: Gespräche lassen sich durchsuchen; Arbeit kann zwischen gekoppelten Geräten und Cloud-Workern wechseln.
Besserer Umgang mit Secrets: Maskierte Credential-Abfragen, ein gemeinsamer Secret Store und optional begrenzte Secret-Nutzung über einen Proxy sollen Zugangsdaten kontrollierbarer machen.
Mehr Zusammenarbeit und Steuerung: Rollen, explizite Sitzungsrechte, Shared Sessions und nachvollziehbare Konfigurationsänderungen werden ausgebaut.
Mehr Betriebsreife: SQLite-Snapshots, wiederherstellbare Backups, Diagnoseübergaben und Reparaturpfade verbessern Update- und Recovery-Prozesse.

Wichtig: Diese Neuerungen verbessern Bedienung, Zusammenarbeit und Betrieb. Sie ersetzen jedoch weder eine technische Mandantentrennung noch Sandbox- und Berechtigungskonzepte.

Details: OpenClaw Release Notes v2026.8.1

✅ Was Unternehmen jetzt tun sollten

Neue Evaluation: Mit einem abgegrenzten Lese- und Analyseprozess starten, ohne produktive Schreibrechte und ohne frei erreichbare Secrets.

Bestehende Installation: Vollständiges Backup erstellen, Migration in Staging testen, Plugin- und Modellrouten prüfen und erst nach dokumentiertem Rollback produktiv aktualisieren.

Mehrere Nutzer oder Organisationen: Vertrauensgrenzen technisch trennen. Unterschiedliche Mandanten, Kunden oder nicht gegenseitig vertrauende Teams benötigen eigene Gateways, Credentials und idealerweise eigene Betriebssystemkonten oder Hosts.

OpenClaw 2.0 macht aus dem populären persönlichen KI-Assistenten noch kein schlüsselfertiges Enterprise-Produkt. Je leichter ein Agent installiert, mit Konten verbunden und zur selbstständigen Arbeit befähigt werden kann, desto wichtiger werden Identitäten, Datenflüsse, technische Grenzen und ein belastbarer Rückweg. Für Unternehmen ist die neue Version daher vor allem ein interessanter Pilotkandidat – nicht automatisch eine Freigabe für den flächendeckenden Produktivbetrieb.

OpenClaw 2.0: Versionsstand und Einordnung

OpenClaw verbindet Sprachmodelle, Werkzeuge, Messaging-Kanäle und optionale Geräte-Apps über ein Gateway. Das Sprachmodell ist dabei nur ein Baustein. Der eigentliche Nutzen entsteht durch Sitzungen, Dateizugriff, Browsersteuerung, Automationen, Skills, Plugins, Speicher und die Möglichkeit, Arbeit an Unteragenten oder andere Maschinen zu delegieren.

Die Version 2.0 trägt technisch die Nummer v2026.8.1. Laut offiziellem Veröffentlichungsbeitrag war zunächst vor allem eine einfachere Installation und eine bessere Browser-Erfahrung geplant. Daraus wurde eine Überarbeitung praktisch aller zentralen Bereiche. Die Foundation nennt 933 Mitwirkende, darunter 569 erstmals Beteiligte, sowie mehr als 16.000 Pull Requests. Diese Größenordnung zeigt Entwicklungsdynamik, ist aber kein Nachweis für Stabilität oder Enterprise-Reife.

Das Projekt bleibt unter der MIT-Lizenz offen verfügbar und wird von der OpenClaw Foundation entwickelt. Am 31. August 2026 zeigte das öffentliche GitHub-Repository rund 388.000 Sterne. Auch diese Zahl misst Aufmerksamkeit – nicht Verfügbarkeit, Supportqualität, regulatorische Eignung oder die Sicherheit einer konkreten Konfiguration.

Die wichtigsten Neuerungen in OpenClaw 2.0 – und was sie im Betrieb ändern

1. Onboarding beginnt mit der vorhandenen Umgebung

Neue Installationen sollen bestehende Modellzugänge, API-Schlüssel und lokale Modelle erkennen. Dazu gehören laut OpenClaw unter anderem vorhandene ChatGPT- oder Claude-Zugänge sowie lokale Laufzeiten. Das senkt die Einstiegshürde und beschleunigt den Weg zur ersten funktionierenden Sitzung.

Für Unternehmen ist das zweischneidig. Schnellere Einrichtung reduziert Projektaufwand, kann aber auch unklare Eigentümerschaft fördern: Wurde ein persönliches Abo, ein Teamkonto oder ein zentral verwalteter API-Zugang erkannt? Vor der ersten produktiven Verbindung muss deshalb geklärt sein, welche Identität verwendet wird, wem Kosten zugerechnet werden und welche Daten der jeweilige Modellanbieter erhält.

2. Die Browser-Oberfläche wird zur Betriebsoberfläche

Die neue Control UI bündelt Gespräche, Sessions, Fortschritt, strukturierte Rückfragen, Widgets und Dashboards. Vergangene Gespräche lassen sich nach exakten Wörtern oder Phrasen durchsuchen. Dauerhafte Fortschrittskarten bleiben über Neuladen und verschiedene Clients hinweg sichtbar. Für den Betrieb ist das mehr als Komfort: Laufende Agentenarbeit wird beobachtbarer, Rückfragen werden eindeutiger und Ergebnisse können näher an der Sitzung dokumentiert werden.

Beobachtbarkeit ist jedoch noch keine Kontrolle. Ein sichtbarer Fortschrittsbalken verhindert keine falsche Aktion. Unternehmen brauchen weiterhin technische Limits, explizite Berechtigungen, fachliche Abnahmekriterien und eine verantwortliche Person, die einen Lauf stoppen kann.

3. Sessions können Geräte und Cloud-Worker wechseln

Arbeit kann auf gekoppelte Geräte oder Cloud-Worker verlagert werden. Warme Maschinen und vorbereitete Projektumgebungen lassen sich für spätere Sitzungen wiederverwenden. Shared Sessions erlauben mehreren Personen, eine Sitzung zu sehen oder daran mitzuwirken.

Damit wächst OpenClaw vom persönlichen Assistenten in Richtung einer Agenten-Laufzeit für Teams. Gleichzeitig erweitert sich der Datenfluss: Gateway, Modellanbieter, Messaging-Kanal, gekoppelte Geräte, Cloud-Worker, Plugins und Zielsysteme müssen gemeinsam betrachtet werden. „Local-first“ bedeutet nicht automatisch, dass jede Verarbeitung lokal bleibt.

4. Credentials und wiederkehrende Freigaben werden kontrollierbarer

Agenten können Zugangsdaten über maskierte Abfragen anfordern, ohne den Wert im Chat oder Modellkontext abzulegen. Ein optionaler Proxy kann die Verwendung geschützter Secrets auf genehmigte Ziele begrenzen. Für Teams kommt ein gemeinsamer Credential Store hinzu; Secrets sollen nur schreibbar, aber nicht wieder auslesbar sein. Wiederkehrende Automationen können für eine exakt beschriebene Operation freigegeben werden und benötigen eine neue Zustimmung, wenn sich Auftrag oder Operation ändert.

Das ist ein sinnvoller Schritt weg von API-Schlüsseln in Prompts und Dateien. Trotzdem bleibt die entscheidende Frage: Welche Aktion kann ein Agent mit dem Secret auslösen? Ein geschützter Schlüssel mit zu weitreichenden Rechten erzeugt weiterhin einen großen Schadensradius.

5. Rollen, Sitzungsrechte und Konfigurationshistorie werden ausgebaut

Verifizierte Nutzer können Rollen erhalten, die den Zugriff auf Agenten, Sitzungen anderer Personen und Operator-Funktionen einschränken. Sitzungen bekommen explizite Berechtigungsmodi. Konfigurationsänderungen werden mit Urheberangabe und redigierten sensiblen Werten protokolliert.

Diese Funktionen helfen einem vertrauten Team bei Zusammenarbeit und Nachvollziehbarkeit. Sie lösen aber keine feindliche Mandantentrennung. Die OpenClaw-Dokumentation sagt ausdrücklich, dass Rollen und Session-Eigentum Kollaborationskontrollen sind, keine Sicherheitsgrenze zwischen gegenseitig nicht vertrauenden Nutzern.

6. Backup, Wiederherstellung und Diagnose werden ernster genommen

OpenClaw 2.0 erweitert SQLite-Snapshots, wiederherstellbare Backups, Diagnoseübergaben und Reparaturpfade. Das ist für produktive Agenten entscheidend, weil Zustand nicht nur aus Konfiguration besteht: Gespräche, Speicher, Automationen, Credentials, Workspace und Plugin-Zustand können voneinander abhängen.

Die offizielle Update-Dokumentation warnt, dass automatische Konfigurationskopien kein vollständiges State-Backup ersetzen. Vor einem größeren Update soll ein verifiziertes Backup erstellt werden. Bei älteren Installationen oder umfangreicher Historie muss außerdem genügend Platz für Ausgangsdaten, temporäre Migration und SQLite-Datenbank vorhanden sein.

Der wichtigste Reality Check: Ein Gateway ist eine Vertrauensgrenze

⚠️ Nicht mit Mandantentrennung verwechseln

OpenClaw unterstützt persönliche Installationen und Teams, deren Mitglieder einander vertrauen. Es ist laut eigener Security-Dokumentation keine Sicherheitsgrenze für gegnerische oder gegenseitig nicht vertrauende Nutzer in einem gemeinsamen Gateway. Wer mehrere Kunden, Tochtergesellschaften oder unterschiedlich vertrauenswürdige Gruppen betreibt, sollte separate Gateways, Credentials und möglichst separate Betriebssystemkonten oder Hosts einsetzen.

Die Abgrenzung ist zentral, weil ein werkzeugfähiger Agent reale Autorität besitzt. Er kann – abhängig von der Konfiguration – Dateien lesen oder verändern, Befehle ausführen, Netzwerkdienste ansprechen, Browser steuern und Nachrichten versenden. Wer einen solchen Agenten bedienen darf, kann grundsätzlich versuchen, diese delegierten Rechte zu nutzen.

Auch Sandboxing ist kein automatischer Grundzustand für alle Werkzeuge. Die Dokumentation weist darauf hin, dass Werkzeuge in der Hauptsitzung auf dem Host laufen können, wenn keine Sandbox konfiguriert ist. Für sensible Prozesse sollten Unternehmen daher Arbeitsverzeichnisse, Dateirechte, Netzwerkziele, Tools und Ausführungsumgebungen deterministisch begrenzen. Ein menschlicher Freigabeschritt ergänzt diese Grenzen, ersetzt sie aber nicht.

Prompt Injection bleibt ebenfalls relevant. Nicht nur fremde Chatteilnehmer sind eine Quelle: Webseiten, E-Mails, Dokumente, Anhänge und kopierte Logs können versteckte Anweisungen enthalten. Das BSI und die OWASP Agentic Security Initiative behandeln genau diese Verbindung aus externem Inhalt, Werkzeugzugriff und autonomen Aktionen als eigene Risikoklasse. Praktisch bedeutet das: Unvertrauenswürdige Inhalte zunächst mit einem leseorientierten, stark eingeschränkten Agenten verarbeiten und Schreib- oder Ausführungsrechte davon trennen.

Breaking Changes: Warum ein direktes Flotten-Upgrade riskant ist

Die offiziellen Release Notes nennen mehrere Änderungen, die bestehende Umgebungen aktiv prüfen müssen:

OpenProse: Das gebündelte Plugin und der Befehl /prose wurden entfernt. Vorhandene Konfigurationen müssen bereinigt und Workflows auf den vorgesehenen Skill-Pfad migriert werden.
OpenAI-Routen: Referenzen wie codex/* und openai-codex/* werden zu openai/* migriert. Gespeicherte Sessions, Provider-Konfiguration und Automationsrouten können betroffen sein.
Plugin SDK: Externe Plugins müssen auf neue, fokussierte SDK-Importpfade umgestellt werden. Die Release Notes nennen dafür bereits Entfernungsschwellen ab 1. September 2026.
Provider-Pakete: Mehrere Provider, Such-, Embedding- und Messaging-Integrationen werden als separat installierbare offizielle Plugins geführt. Fehlende Pakete müssen bewusst geprüft und wiederhergestellt werden.

Diese Änderungen sind beherrschbar, wenn Inventar, Tests und Rollback existieren. Gefährlich wird das Update dort, wo Automationen historisch gewachsen sind, persönliche Credentials verwenden oder Plugins ohne Eigentümer und Versionsstrategie eingebunden wurden.

Entscheidungsmatrix: Für wen OpenClaw 2.0 jetzt passt

Ausgangslage	Empfehlung	Begründung
Neue persönliche Testumgebung	Geeignet für einen begrenzten Pilot	Das Onboarding ist einfacher. Trotzdem nur mit Testdaten, minimalen Werkzeugrechten und eigener Kostenkontrolle starten.
Vertrauenswürdiges internes Plattformteam	Staging-Evaluation sinnvoll	Rollen, Sessions, Secrets und Cloud-Worker bieten Mehrwert. Betrieb, Identitäten und Berechtigungen müssen zentral verantwortet werden.
Bestehende produktive 1.x-/2026.7-Installation	Nicht ungeprüft aktualisieren	OpenAI-Routen, OpenProse, Plugins und persistenter Zustand benötigen Migrationstests und einen verifizierten Rückweg.
Mehrere nicht gegenseitig vertrauende Teams oder Kunden	Nur mit technischer Trennung	Ein gemeinsames Gateway ist keine feindliche Mandantentrennung. Eigene Gateways und Credentials pro Vertrauensbereich verwenden.
Irreversible, finanzielle oder personenbezogene Aktionen	Zunächst keine autonome Freigabe	Least Privilege, feste Limits, Sandbox, aussagekräftige Freigaben, Logging und Rollback müssen vor produktiven Schreibrechten nachgewiesen sein.

Praxisbeispiel: Ein kontrollierter 30-Tage-Pilot

Hypothetisches, aber realistisches Szenario: Ein mittelständischer Maschinenbauer möchte Service-E-Mails vorsortieren, relevante Handbücher finden und Antwortentwürfe vorbereiten. OpenClaw darf Nachrichten lesen und Dokumente in einem freigegebenen Wissensbereich durchsuchen. Es darf weder Antworten versenden noch ERP-Daten ändern.

Der Pilot erhält eine eigene Gateway-Instanz, eine technische Identität mit Leserechten, einen eingeschränkten Modellzugang und eine Sandbox ohne Zugriff auf persönliche Benutzerverzeichnisse. Externe Anhänge werden zunächst von einem separaten Reader-Agenten ohne Schreib- und Shell-Rechte zusammengefasst. Ein Service-Mitarbeiter prüft Klassifikation, Quellen und Entwurf vor jeder weiteren Nutzung.

Nach 30 Tagen wird nicht gefragt, ob der Agent „beeindruckend“ wirkte. Entscheidend sind messbare Abnahmekriterien:

Anteil korrekt klassifizierter Vorgänge und korrekt belegter Antworten
durchschnittliche Bearbeitungszeit gegenüber der dokumentierten Ausgangslage
Kosten pro abgeschlossenem Vorgang einschließlich Modell, Infrastruktur und menschlicher Prüfung
Anzahl unzulässiger Werkzeugversuche oder nicht nachvollziehbarer Quellen – Zielwert bei Rechteverletzungen: null
Zeit bis zum Stoppen, Wiederherstellen und Nachvollziehen eines fehlerhaften Laufs

Erst wenn diese Werte stabil sind, folgt die nächste Autonomiestufe, etwa das Anlegen eines Entwurfs im Ticketsystem. Automatischer Versand oder Änderungen an Kunden- und Auftragsdaten bleiben eine separate Freigabeentscheidung.

DACH-Governance: Was zusätzlich geprüft werden muss

Datenschutz und Datenflüsse

Ein lokales Gateway macht einen Workflow nicht automatisch DSGVO-konform. Zu dokumentieren sind mindestens Messaging-Kanal, Modellprovider, Plugins, Browserzugriffe, verbundene Systeme, Cloud-Worker, Logs, Speicher und Backups. Werden personenbezogene Daten durch externe Anbieter verarbeitet, sind Rollen, Verträge, Speicherorte, Löschkonzept und Drittlandtransfers zu prüfen. Eine Datenschutz-Folgenabschätzung ist erforderlich, wenn die geplante Verarbeitung voraussichtlich ein hohes Risiko für Rechte und Freiheiten natürlicher Personen mit sich bringt.

EU AI Act

Seit 2. August 2026 gelten und werden weitere zentrale Teile des EU AI Act durchgesetzt, darunter Transparenzpflichten für bestimmte interaktive KI-Systeme. Ob ein OpenClaw-Workflow als Hochrisiko-System einzuordnen ist, entscheidet nicht der Produktname, sondern der konkrete Einsatzzweck. Ein interner Rechercheassistent ist anders zu bewerten als ein System, das Bewerber vorsortiert, Kreditentscheidungen vorbereitet oder Beschäftigte bewertet.

Unabhängig von der Risikoklasse sollten Unternehmen die betroffenen Personen verständlich informieren, Zuständigkeiten festlegen und die erforderliche KI-Kompetenz der Beschäftigten fördern. Bei extern sichtbaren Agenten ist zu prüfen, wann nach Artikel 50 offenzulegen ist, dass eine Person mit einem KI-System interagiert.

Betriebsrat und Beschäftigtendaten

Protokolle, Sitzungsverläufe, Aktivitätsanzeigen und Arbeitskennzahlen können Rückschlüsse auf Verhalten oder Leistung von Beschäftigten zulassen. In Deutschland ist deshalb § 87 Abs. 1 Nr. 6 BetrVG früh zu prüfen, wenn technische Einrichtungen zur Überwachung bestimmt sind. Rollenmodell, Einsichtsrechte, Aufbewahrung und Auswertungszwecke gehören in die Einführung – nicht erst in die spätere Betriebsvereinbarung.

Governance-Merksatz

OpenClaw 2.0 verbessert die Steuerbarkeit des Agenten. Es übernimmt aber nicht die Verantwortung für Zweck, Identität, Daten, Rechte und Folgen einer Aktion.

Upgrade-Checkliste für bestehende Installationen

Inventar erstellen: Agenten, Modelle, Provider-Routen, Plugins, Skills, Automationen, Kanäle, Geräte, Cloud-Worker, Credentials und beschreibbare Zielsysteme erfassen.
Vollständiges Backup verifizieren: Nicht nur die Konfiguration kopieren. Die offizielle Dokumentation empfiehlt ein geprüftes State-Backup; Archive wie produktive Zugangsdaten behandeln.
Staging aus realistischem Zustand aufbauen: Eine Kopie der produktiven Konfiguration und repräsentative, bereinigte Sitzungsdaten verwenden. Keine Migration zuerst auf dem einzigen produktiven Gateway testen.
Migration und Plugins prüfen: openclaw doctor --fix kontrolliert ausführen, OpenAI-Routen vergleichen, OpenProse-Abhängigkeiten identifizieren und externe Plugins gegen die SDK-Migration testen.
Sicherheitsprüfung durchführen: Nach der Änderung openclaw security audit --deep ausführen. Zusätzlich reale Tests für Prompt Injection, Rechteausweitung, Secret-Zugriff, unerlaubte Netzwerkziele und Serienaktionen durchführen.
Abnahme und Rollback pro Workflow: Kritische Automationen mit bekannten Testfällen ausführen, Ergebnisse und Nebenwirkungen vergleichen, openclaw health prüfen und den Rückweg praktisch testen.

Für kleine, risikoarme Installationen kann diese Checkliste schlank umgesetzt werden. Bei sensiblen Daten, mehreren Integrationen oder hoher finanzieller Wirkung gehören unabhängige Sicherheitsprüfung, Incident Response und wiederholbare Regressionstests zum Mindestumfang.

Fazit: OpenClaw 2.0 ist ein Betriebs-Release, kein Freifahrtschein

OpenClaw 2.0 bringt den Agenten-Stack näher an das, was Unternehmen tatsächlich benötigen: bessere Sitzungen, sichtbare Arbeit, kontrolliertere Secrets, Rollen, Freigaben, Backups und Diagnose. Das ist strategisch wichtiger als ein weiterer Modell- oder Benchmark-Sprung.

Die wichtigste Grenze bleibt zugleich unverändert: Ein leistungsfähiger Agent erbt die Autorität seiner Werkzeuge und Identitäten. OpenClaw schützt nicht automatisch vor falsch zugeschnittenen Rechten, gemeinsam genutzten Vertrauenszonen oder schädlichen Anweisungen aus E-Mails und Webseiten.

Konkreter nächster Schritt: Wählen Sie einen reversiblen, leseorientierten Prozess. Dokumentieren Sie Datenfluss, Identität, erlaubte Werkzeuge, Stop-Kriterien und fünf Pilot-KPIs. Bestehende Installationen werden erst nach verifiziertem Backup, Staging-Migration und Rollback-Test auf 2.0 aktualisiert.

FAQ zu OpenClaw 2.0

Ist OpenClaw 2.0 eine neue Produktlinie?

Nein. OpenClaw 2.0 ist die Bezeichnung für die stabile Version v2026.8.1. Sie bündelt eine besonders umfangreiche Überarbeitung des bestehenden OpenClaw-Projekts.

Ist OpenClaw 2.0 für Unternehmen produktionsreif?

Das lässt sich nicht pauschal beantworten. Für abgegrenzte, reversible Piloten in einer vertrauenswürdigen Umgebung ist die Version interessant. Für kritische, mandantenfähige oder irreversible Prozesse muss das Unternehmen Isolation, Rechte, Betrieb, Support und Wiederherstellung selbst belastbar nachweisen.

Kann OpenClaw 2.0 vollständig lokal betrieben werden?

Gateway, Werkzeuge und lokale Modelle können auf eigener Infrastruktur laufen. Sobald Cloud-Modelle, Messaging-Dienste, externe Plugins, Webzugriffe oder Cloud-Worker beteiligt sind, entstehen externe Datenflüsse. „Lokal“ muss deshalb für jeden Verarbeitungsschritt nachgewiesen werden.

Ersetzt die neue Rollenverwaltung separate Gateways?

Nein. Rollen begrenzen Zusammenarbeit innerhalb einer Vertrauenszone. Für nicht gegenseitig vertrauende Nutzer, Teams, Kunden oder Mandanten empfiehlt die OpenClaw-Dokumentation getrennte Gateways und möglichst getrennte Hosts oder Betriebssystemkonten.

Sollten bestehende Installationen sofort aktualisieren?

Nicht ohne Vorbereitung. Die Version enthält Breaking Changes bei OpenProse, OpenAI-Routen und Plugin-Schnittstellen. Ein vollständiges Backup, Staging, Regressionstests und ein geprüfter Rollback sind vor einem produktiven Flotten-Upgrade sinnvoll.